Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Empfohlen
Empfohlen (20)
Refresh Boston Feb2009
- 1. Usability: Getting it Right the First Time Make It Perfect, For Now refresh boston. february 18, 2009. 1 Wednesday, February 18, 2009
- 2. What We Will Do Intro to Me (or Why You Should Listen) Starting Before Playing the “In Order To” Game Iteration (and other non-sequential daring-do) Can We Test This Mofo? Ending Before (remind me about the links) 2 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 3. Matthew Oliphant Whale Hunter Designer Coffee Roaster Father Husband Chef Usability-er Speaks 17 Languages Rodeo Clown Gemini 3 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 4. Caveats 4 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 5. Idealist POV My job is to become irrelevant. 5 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 6. Realist POV Give me heaping great wodges of ca$h to solve the 19 problems you think you have and the 1 big one you haven’t identified yet. 6 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 7. The Web Isn’t Broken Billions of dollars exchange hands every day. Ideas are shared. What exactly are we trying to fix? 7 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 8. Two Words Audience Participation 8 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 9. The Survey 9 Wednesday, February 18, 2009
- 10. 10 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 11. 35 Responses 0 5 10 15 20 Best Practices Up-front Work Tools Assessment 10 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 12. Anything on the Moderation tips and pragmatic side of techniques: How to put usability testing. participants at ease... Specifically, on a shoe- How to take notes and string budget. still keep interviews engaging... How should User Testing you give positive reinforcements for Best practices for keeping the flow going elicitation during a utest (i.e. quot;That's great to ensure good feedback. Good to information. know.quot;) Etc... Live data-driven testing Best practices for quot;Sellingquot; web usability in bringing usability test a corporate environment findings (or whatnot) into design or implementation phases of a project 11 Create Right Stuff Right - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 13. Starting Before 12 Wednesday, February 18, 2009
- 14. What is Usability Big U, little u what begins with you. 13 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 15. Great Designs Aren’t Born They’re Usabilitied. 14 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 16. How’d the new spy camera test go? Well, we probably shouldn’t have designed the interface to be exactly like the canon’s firing mechanism. 15 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 17. The Current State How well one perceives a gap usually influences how well one bridges it. 16 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 18. Who’s In Charge? Ideally, it’s Charles. (pause for laughter) Define who has a stake and to what level they can screw you over at the last minute. 17 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 19. Anything Can Be Designed Anything. Design is easy. The hard part is getting buy-in. 18 Create Right Stuff Right - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 20. Let’s Play: In Order To! 19 Wednesday, February 18, 2009
- 21. (aka: Stop effing telling me about drop-downs and tell me WHAT you want to accomplish!) 20 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 22. Some Use the 5 Whys I use the n Rly? Srsly?’s 21 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 23. Why Focus on What? “...80 percent of development costs are consumed by software developers identifying and correcting defects.”* Primarily due to poor requirements gathering. 22 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 24. Iteration 23 Wednesday, February 18, 2009
- 25. Reverse the Funnel Why not spend that 80% up front? 24 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 26. 25 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 27. Can We Test This Mofo? 26 Wednesday, February 18, 2009
- 28. Usability Testing Your site has 99 problems, but this glitch aint one. 27 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 29. Metrics You need them even though they are a complete waste of time. 28 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 30. Reporting Who cares? 29 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 31. Ending Before 30 Wednesday, February 18, 2009
- 32. You Have to Ship Eventually Don’t hold on to a design forever. This is the power of the web. Launch and Learn can actually work. 31 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 33. It’s Do-Over Time The number of “Oh shit...” moments will depend on how well you started. 32 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 34. It’s That Time of the Month Go find a newbie, an oldbie, and get them to tell you what you’ve been doing wrong. 33 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 35. If, Then 34 Wednesday, February 18, 2009
- 36. In Order To... ...stop driving people insane. 35 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
- 37. Fin 36 Wednesday, February 18, 2009
- 38. Hey Matthew.... Don’t forget the http://xhipi.com/share/ handouts tanalysis.pdf Rate my talk: http:// http:// rurl.org/1d0d www.slideshare.net/ matthewoliphant matthew@xhipi.com @matto on Twitter http://xhipi.com/share/ hchecklist.pdf 37 Usability: Getting it Right the FIrst Time - Refresh Boston February 2009 - Matthew Oliphant Wednesday, February 18, 2009
Hinweis der Redaktion
- One of these things is not like the other.
- This will be more fun, interesting, and informative if we all participate.
- Most people voted for more than one, so the focus of this talk is... everything.
- Big U: BTU. Business, Technology, Users. A constant balancing act. Little U: testing, plain and simple.
- Much like a book doesn’t come out finished with it’s first draft... Every step of the design process is “edited” beginning with the idea.
- Designing for context. Who are you designing for? Where will they use what you design? How can you stop them from accidently killing people? Why design the camera’s physical interface to be just like the interface for the canon?
- Comparative analysis, fit/gap, contextual enquiry, heuristics... there’s no way to get to where you are going unless you know where you are. Sit down with some users and talk with them about how they use your product. Or how what they use now doesn’t meet their needs. Heuristics Handout: There’s a solo and a group approach. Contextual Inquiry: Often users figure out better ways to use your stuff.
- It’s never just you. Well, almost never. Decide up front who can decide, who you just need input from, and who just needs to know.
- Design is just a process. And there’s a lot of tools that can be used to create something wonderful. But if no one asked for it, if no one pays for it, if there are some who want to destroy what you create... Why did you even start in the first place?
- This is part of Starting Before, but I wanted to call it out specifically.
- 5 Whys limits the number so you don’t end up in a requirements black hole. I find 5 usually works, but sometimes you have to delve further. Especially at the start.
- http://www.ibm.com/developerworks/rational/library/4995.html Like sailing, or kayaking, if you aren’t constantly checking where you are in relation to where you want to be, you might be sunk.
- Let’s assume you have a solid sense of WHAT. Now what? Describe/Draw the actual vs. ideal “funnel” of effort. Iteration doesn’t have to be on the whole set of requirements.
- Now here’s a better funnel.
- High-level, there are basically two types of testing: “What should we change,” and “Did what we change work?” Most people think of the latter. What you should be looking for are the big issues; show stoppers. And each iteration, the goal is to have fewer and fewer of those.
- “User must complete Task A in under 10 seconds with no errors and feel satisfied with their effort.” “Did it work as planned?”
- Let’s go way back to the beginning. Who cares about this effort? Client? Boss? Boss’ boss’ boss’ boss? ISO/IEC 25062:2006 or a bulleted list?
- Alpha, Beta, Gamma... it’s all good. This is where metrics can be useful. 17 minutes on a site can be a good thing if that’s the design. But if that 17 minutes is spent changing a password... yer fucked.
- Getting 5 users in to test your product is all well and good, but in the end you’ve only proven that those 5 people can use it. Plan for triage from the start. Know who to involve and make the call quick.
- Users and their needs change over time. How do you stay on top of it? You ask them. Every month or two sit down with some users and talk with them about how they use your product. Wait, that sounds familiar... (current state: where we started this mess.) Rinse and repeat until you are either the only player in the game or you’ve gone out of business.
- I just want to add something before I finish: Life is like a really long If, Then table. If <this>, then <that>.
- In the end, these are just tools. There are no hard and fast rules. The idea is to know what the tools are, when to use them, and when to say Fuck It and just work to make the world a better place. Even if they have to rip the mouse from your cold, dead hands.