Entrepreneurial User Experience: Improving your products on a shoestring
•Descargar como PPTX, PDF•
4 recomendaciones•2,169 vistas
The document provides tips and guidance for user experience (UX) design on a limited budget. It emphasizes starting with defining the audience through activities like determining goals, tasks, and current solutions. It also stresses understanding the user's context and validating designs with real people over following a specific process. The overall message is that good UX comes from being user-centered not tool- or feature-focused.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
Similar a Entrepreneurial User Experience: Improving your products on a shoestring
Similar a Entrepreneurial User Experience: Improving your products on a shoestring (20)
Más de Steven Hoober
Más de Steven Hoober (20)
Último
Último (20)
Entrepreneurial User Experience: Improving your products on a shoestring
- 1. Kauffman Labs Coding Workshop UX Design @shoobe01 1
- 2. Entrepreneurial User Experience Improving your products on a shoestring. @shoobe01 2
- 3. UX = User Experience 3
- 4. 4
- 5. Make good toaster ovens, not more features. 5
- 6. UX is not just UI. 6
- 8. First, find out: • What is your audience? • What are their goals? • What are they using now to solve this need? • What goals does your organization have? 8
- 9. Nothing. 9
- 10. Don’t design for yourself. 10
- 11. Defining your audience: • • • • It is never “everyone.” Be specific. Avoid demographics. Tasks, goals, behaviors. 11
- 14. KJ (Post-It®) Process: • • • • • • Determine focus questions Get in a room Answer questions Put up answers Group answers, label groups Vote on most important groups 14
- 15. Focus Questions: • • • • What is the product? What is it’s one main purpose? What one problem does it solve? Who will use the product? 15
- 16. Learn what you know. 16
- 17. KJ (Post-It®) Exercise: • • • • • “What one problem does it solve?” Put up answers Group answers (draw a circle) Label groups (write the label) Pick the top three groups 17
- 18. An app is not a mobile strategy. 18
- 19. “I'm as interested in "channels" as a thing when designing ecosystems as I am in pages when reading a book.” – Andrea Resmini @resmini 19
- 20. “Sadly, no decision about architecture is a decision, one that will determine your success or failure as a company.” – Michael Sharkey, Bislr @michaelsharkey 20
- 22. Don’t build a website (or app): • • • • Where are the users? How are they distracted? How else can they get the task done? Will users automatically come back, or do you have to re-engage them? 22
- 23. What channel are you missing? 23
- 25. Which channel? • • • • Where are the users? How are they distracted? How else can they get the task done? Will users automatically come back, or do you have to re-engage them? 25
- 27. Ask for help. 27
- 28. Homework… 28
- 29. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 045 @shoobe01 shoobe01 on: www.4ourth.com 29
- 30. Entrepreneurial User Experience Improving your products on a shoestring. @shoobe01 30
- 31. Who’s new? 31
- 33. “…inequality is where the opportunities/challenges for design really are.” – Andrea Resmini @resmini 33
- 34. Embrace failure and complexity. 34
- 35. 35
- 36. There is no happy path. 36
- 37. 37
- 41. Look over your shoulder. 41
- 45. Know what the audience uses. 45
- 46. Know how your audience works. 46
- 47. Don’t forget the browser. 47
- 48. Think about the ecosystem. 48
- 50. Thing 50
- 51. Thing 51
- 54. Context is more important than working code. 54
- 56. One on one. 56
- 57. Ask them, don’t tell them. 57
- 58. Your memory is terrible. 58
- 59. 59
- 60. 60
- 63. 63
- 65. Ask for help. 65
- 66. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 045 @shoobe01 shoobe01 on: www.4ourth.com 66
- 67. 67
- 68. 68
- 69. 69
- 70. 70
- 71. 71
- 72. 72
- 73. Contact me for consulting, design, to follow up on this deck, or just to talk: Steven Hoober steven@4ourth.com +1 816 210 045 @shoobe01 shoobe01 on: www.4ourth.com 73
Notas del editor
- PHONES, WOOD PHONEPOST-ITS, MARKERS, PAPER, TAPEA FEW PRINTOUTS OF FAKE VIDEO SERVICE1 COPY OF BOOKGIVE AWAY EURO BOOKCARDS, TOUCH TEMPLATES, STICKERS, ETC.I hope no one is here for a coding workshop…
- Because they didn’t get the name right in the promotion. The description was right, so hopefully you are all expecting what I’m going to call Entrepreneurial User Experience. Now, I am a UX expert. I make lots of money per hour being a consultant for this, and I encourage everyone to hire at least one UX guy for any product. More is better. And we have proof, it pays off in customer satisfaction, stickiness, reduced development effort, reduced bugs, etc. But I am pragmatic more than idealistic, and know you won’t do that. So, I am going to help you add a LITTLE BIT of user-centered thinking to your work instead.
- I am going to use the term UX a lot today. Get used to it. It means User Experience. But what’s that really mean?
- On a vacation over Christmas, this toaster oven was the bane of my existence. There was no microwave, so we had to use it a lot, for heating things as well as toasting. But the timer was mechanical, so it would merrily tick away when the toaster oven wasn’t even plugged in. You come back when it goes DING to find that nothing happened. Actually ALL controls are independent. So, you can set the wrong mode and get no heat even though it’s now plugged in, so there’s a light on to tell you it’s “working.” The dials are badly labeled. Some say OFF for the off setting, some have a dot. I assumed at first the dot was “default” but it’s not, so again came back minutes later to a cold oven. And so on. We could easily come up with a half dozen small fixes to this OR take the whole thing back to basics and create a new design. But we’ll do more fun and hands on design work later. Instead I ask, how did they get there?
- Because they had a laser focus on quality of individual parts. The dials work fine, and I am sure to specification. They click in firmly, and it’s full of features (which look great on the side of the box or the Amazon product page) so does much more than my old toaster oven at home. But they forgot that they were making a toaster oven. That people had to be able to use it, quickly and easily, to make toast, or warm up their dinner. Without knowing you, by default I will accuse you all of making bad toaster ovens also. The way product development — not to mention software development, or even business these days in general — encourages short-sighted goals, a focus on process and a navel gazing attention to what you know of the product, and think you know about our customers.
- So, that’s the focus of these few hours we’re together. How to think about, like and for the user. Not just altruistically, so we build better products; not just because you work in a regulated industry and are required to; but so you build products your customers will buy, and will keep on using. *** NEXT ***UX is not not the interface, but the EXPERIENCE. So it involves EVERYTHING that impacts the experience. If you have a note to go hire a graphic designer, don’t do that. UX design is not UI design. http://www.helloerik.com/ux-is-not-ui
- I came to many of these realizations and convictions by massively failing and wasting my time. I re-confirmed it recently, building a very beautiful product that’s somewhat odd and disjointed. Because if you go to drawing too early, you get locked into interface and interaction decisions. So the first thing to do when designing is to resist the urge to draw at all. Instead, we need to understand, and define.
- And you define, the basic outlines of your product. What is your audience?What are their goals?What are they using now to solve this need?Why is your company doing this? The second to last one is going to surprise you. It’s very unlikely to be whatever your existing formal answer is. It won’t just be the competition’s website or version 1 of your product.
- The point of many modern technologies — mobile andwearables more than the desktop Web — is not to allow that existing stuff to be on cheaper and more popular platforms, but to address more emergent needs and fill the gaps. If you really look into how people get and need knowledge you are going to find:Nothing. The first answer is very likely to be that they don’t engage, or re-engage. At all.Ad hoc methods. Asking co-workers, or just doing what they see everyone else do. Or not do. Printouts. And other ways to make the current stuff portable. Sometimes, shared informally.Hacks. Using the existing system (poorly) on their own devices, or just using other information sources which might not be approved or even accurate. It could be just individuals finding info online, or it could be well-intentioned, with departments making their own training notebook or friends sharing links.
- You find a lot of this stuff out first by determining who will use your product. Remember, your audience is not you, it’s not your developers, and if you are moving from a website to a mobile app it’s not those same people on the go. Because even if they ARE the same people, they don’t work in the same way they did (or we made them) on desktop. Playing a game while waiting for the dentist is not the same as sitting in front of the Xbox at home. Don’t make assumptions about use, platforms, needs. Mobile (and I am a mobile designer so get used to this) offers the ability to use information in such ways you need to consider that this is the first time you have met your users.
- So, you need to find out what your audience, or your users think of it and how they use it. Which means you need to know who they are. Here we come to the first shortcut. Ideally, you are going to go out and find people directly. That’s expensive and to do it right requires some specialized skills. Even I am not the right guy to hire to do this research, but I know how to specify it. Instead, you need to read user feedback, watch what others in the space do, pay attention to web analytics (time on page and abandon rates aren’t always your fault but can be the way the people want to engage). Then answer some basic questions to define your audience. Remember: LIST
- So while I am going to talk a lot, it’s true it’s not a lecture, but a workshop. Time to get workshopping.Everyone split up into groups. DISCUSS – WHO IS A DEV, DESIGNER, BUSINESS/MARKETING/PM… OTHER? Group to spread them around? Teams that came together should stay together, and you can use the actual product you are working on. Ideally, you can all do that, but if you don’t have enough people or it’s secret, talk amongst yourselves and pick a public product. Something that works here, so you can pop open your laptop, phone or tablet to show everyone how it works. Once you have a project in mind, raise your hand. ASK SOMEONE TO VOLUNTEER THEIR PROJECT, AND I QUIZ THEM ON THEIR CHOICES…
- Don’t worry, I’ll do more group exercises later, but that one’s harder so it seemed best to demonstrate so we could get it out of the way. A term you’ll hear if you start reading about UX work, or worse yet hire one of us, is the principle of user-centered design. I like to extend this to user-centered execution, which we’ll talk about in the next section. A key tenet of UCD is what I already mentioned, identifying your users and understanding their needs. There are lots of clever techniques to get this data, but most of them take forever. Like, 6 months per analytical phase. But there are cheats. Common, well-used cheats. Like using your knowledge.
- If you get a team together who have been working on similar products, or have been talking to customers on the first or failed version, they have a lot of knowledge in their heads. Annoyingly, it’s inside. And people are bad at analyzing and sharing really. But, we can use this technique to extract the information and find really, really interesting answers as a result. And, quickly. Ideally, we have a couple hours, but you can do something in a few minutes. Which is all the time we have.
- You can do this several times. These are some questions I like to ask, though I don’t always find them by this process. If some like “what is the product” seem simple, I have never asked this of a team — even a team three years into a project schedule — without getting multiple answers. You have to know what you are working on, and make sure everyone is on the same page.
- Pick a whiteboard. Let’s just answer one question. What ONE problem does it solve. Everyone write that answer on a post-it, and put it on the whiteboard. Now I said ONE, but I mean that per card. Torn? Write two. Or five, or fifteen answers. That’s fine. Start doing those now, as I keep talking at you. 20 MINUTES IF POSSIBLE.
- 20 minutes! Pick a moderator. You can’t spend more than 5 minutes per step. You can argue for hours about this stuff.
- PAUSE A website is not a digital strategy, and an app is not a mobile strategy. You know this. We all know this. Though with the number of people confusing the ACA with the website fiasco, I wonder sometimes. But anyway, how DO we get to a digital strategy? How do we find the right answer for you and your organization?
- First, think in terms of systems, and of data, and set aside platforms.
- Thinking of systems means thinking about how information works agnostic of channels. It means thinking of Information Architecture, data architecture, even storage technologies and what’s in the API, first. Think about some really successful products. Twitter, which is SMS based, but you use as a Website, as an app on your computer or handset, or tablet… Or take Evernote. Who used some competing tool to keep track of stuff like that a few years ago? Well, most of those disappeared. Why? They were websites. Or apps. But Evernote is a platform, more than anything. Their platform even has a name (Trunk) and teams work on that as a product in and of itself. Thinking of their product as a service meant they could move into new platforms immediately, without re-thinking their business model, or re-architecting their systems.
- Remember when I asked what your audience uses now to solve the problem your product will fix? Well, that might not be a competing website, but a book, catalog, pair of scissors, or Post-It note. Think about all the systems we use every day, maybe by stopping and just observing how much you yourself email, IM, SMS and just walk over and talk to people. A website is not a digital product, and an app is not a mobile strategy. You have to consider the whole ecosystem, and design the password reset emails, make it easy for customers to send links to their friends and family, and make sure the invoice in the box uses the same terminology as the product sales website.
- To think in terms of ecosystems it helps to be a clever data-centric type, but thinking of the users will do nicely as well. You can only go so far improving that website, so think of their tasks, their locations, their motivations, the other tools they use, etc.
- Exercise time. You can document this any way you want. Paper, whiteboard, etc. Define the current domain. Website? App? Assume that you want your users to be re-engaged and to use some version of your product everywhere. What problems do they encounter with each of these facets? Take into account your previous work. Your audience identification and so on, to figure out how they might actually interact with your systems. 10 MINUTES. This one is quick on purpose.
- You wrote down those issues because we’re going to solve them now. This is another where I want to demonstrate thinking outside the box by pairing your teams. Pair off across the table with another team. Move around if you need to, or just turn your chairs so your whole team faces another team. (UNEVEN GROUPS? I will help one of them)Now, one team volunteer to present the problems you just found. The other is going to: Review the previous worksheets. Explain it to them briefly so they know your product well. Then ONE AT A TIME, quiz you as needed and consider if the answer to the issue is providing the information in another channel.
- 5 MINUTE LECTURE after this, so whatever time is left! Channel can be pretty broad. Not just web or app or email or postcard. But what about a Facebook plugin. Or TV advertising. Interactive billboards? Think broadly, and do not worry about cost or (within reason) plausibility. A key reason you are doing this is just to set the scope, and make sure that everyone is thinking about the possibilities, so your database and APIs are built with these crazy ideas in mind.
- In case you haven’t picked up on that, or I accidentally implied any of the things I said are a new process, or steps in your existing process, they aren’t. You should use almost all of these during your design process, but routinely. If not hourly, then check for resilience and consider platform specifics daily. Eventually, you can do this automatically. It becomes second nature. To me, I am serious when I say this is developing a philosophy of design.
- Ask for Help –Lastly, there is a lot of information, scads of research, good guidelines, and a lot more mobile consulting out there than you might think. If you can’t hire an expert full time, try to get one in to help for a bit at those key junctures, and as early as possible. Assign existing people jobs to find information, and share it with the organization so you raise the level of knowledge in the new domain. You people: go back home and tell everyone what you learned here. Now, what didn’t I answer for you? What specific problems do you have with your organization, environment or users? GIVE AWAY BOOKS TO FIRST FEW WHO ASK QUESTIONS.
- Bring your product. If you have one, and can share it, bring it. Preferably, bring some printouts on paper, at the scale they are viewed. If it’s on a handset, don’t take up the whole piece of paper. By bring it I mean: Bring several pages, a process that you could demonstrate to others without using a computer or your phone. If you can’t bring a real product, bring something. A favorite site or app, or one you want to use more but find to have issues. In two days, we’ll work on more specific design issues of interface and interaction, and learn a little about evaluating your work to confirm it is good and to improve it.
- So, whose confused, disagrees or doesn’t see how it applies to them?
- Because they didn’t get the name right in the promotion. The description was right, so hopefully you are all expecting what I’m going to call Entrepreneurial User Experience. Now, I am a UX expert. I make lots of money per hour being a consultant for this, and I encourage everyone to hire at least one UX guy for any product. More is better. And we have proof, it pays off in customer satisfaction, stickiness, reduced development effort, reduced bugs, etc. But I am pragmatic more than idealistic, and know you won’t do that. So, I am going to help you add a LITTLE BIT of user-centered thinking to your work instead.
- First, who was not here on Monday? … Too bad, there’s no time to catch up. But, it’s all by teams so you won’t be too far behind. Also, put your hands back up. Let’s move you to WHICHEVER TABLE IS LIGHT. PROBABLY THE FRONT ONE.
- So of those here Monday, who went home or to the office and tried to chat about Monday’s work with people or Googled the keywords and… got confused? Briefly, what didn’t make sense so I can try to fix it before we continue?
- Okay, so where we left off moving from ecosystem design, to starting to identify which platforms are the right ones to work on. I actually don’t have a simple enough checklist to pick which platforms you need to focus on. Just opening yourself to the possibility of others, or awareness that it’s an ecosystem and has to be consistent should be enough to get you started. Platform differences should not be worried about as “fragmenting” the development or your experience. Differences tend to disappear in the end, not in the sense of merge, but because the capabilities and interactions are matched to the way they are used. Embrace these differences.
- Just trust me on this one: Everything you do is too complex to adequately model and map. Assume you have always missed something, so you are prepared to deal with the unexpected, both in design and so you can modify your product over time to take advantage of new ways you find people using your learning information. You could just remember instead…
- I say there’s something called Resilience Design. Or there should be. Here’s a simple example… I also still wear normal watches. One is a dive watch, because it’s shiny, not because I am a diver or anything. It is one of those with a twisty ring around the outside. That part with the numbers twists around. If you don't know, and I didn't until recently, this is used as a simple timer. But on mine, and on all dive watches (vs. Aviators watches), the ring only goes one way. The clicky detent lets it go counter-clockwise, only. WHY? … Because it's for timing remaining air. The ring might get bumped and change it's setting. Having it show less time might be inconvenient, but going the other way might kill you. And, you don't even need to know this. It just works. That's the sort of brilliantly-simple answer I am talking about with resilient design.
- You need to make your designs resilient because users will never, ever do what you expect. You, or others in your organization, probably draw diagrams that assume everyone starts at the home page, drills down through a preferred path and gets their information. It’s not true. People bookmark, share, and search. They use your process in unexpected ways, and your system returns errors or data you didn’t expect. If you try to design to accommodate these, or to test for them in the traditional use case model, you CAN’T. For one project I worked on, I did some quick math and to create the use cases for all variations would take approximately the remaining life of the universe. Really. These are arbitrarily complex products, so don’t lament, embrace the complexity.
- On a typical website, I find that home page as the entry point is rarely over 10%, and is often so low as to be ignored; hundreds of visits a month when hundreds of thousands visit the site. This is real data.
- This is even more important with the way people engage on mobile devices. People seek out and consume content sometimes a few seconds at a time. They get interrupted, and come back to read a bit again so it has to be ready for them. Does your information work well and make sense if set aside for a few minutes? A few hours? Make sure session expiry and other technical things don’t get in the way of users coming back. And, remind them to come back. Use SMS, and app notifications or reminders within the site or app of items that may be interesting or that they didn’t complete. Or emails. Or postcards. Or whatever fits the way you have a conversation with your customers or users.
- The exercises we’re gonna do today are around what I could call User Centered Execution. Ideally, this is part of how development and test is approached also, and you can ask me about that as well, but we’re going to talk about it from the design side still. Because design is ongoing, iterative and evolutionary.
- PAUSE My kids routinely do what all children do: they don’t clean their room, they leave the bathmat wet on the floor, they leave the cereal box out. The typical excuse is “oh, I forgot…” to do whatever. Lately, that thought process has struck me. Their expectation seems to be that following the rules is about memorizing, and complying with, a long checklist of appropriate behaviors. I remind them instead that I don’t remember anything, either. I actually have a sort of terrible memory for processes and steps and procedures. I made most of this deck by pulling my best practices from my Wiki where I write everything important down so I don’t forget and you all can use it.
- So what I do is turn around and look over my shoulder. Just like you look before crossing the street, you should make sure the bathroom looks neat before you leave it after taking a shower. We as humans actually become pretty good at doing this; when we take a moment to step out of our normal, rushed lives we notice what is wrong, broken, or out of place. Yes, I’m talking about this in our professional lives also. How bad is your current product on mobile? How good is the competition, or that vendor product? Well, you should find out.
- And expert reviews, or heuristic evaluations, work very well to find the vast bulk of issues. Without getting into the whys too much, or addressing what heuristics I use, here are some basic guidelines for evaluating existing work, the competition, or that vendor suggested solution. I won’t talk about the specific heuristics you test to, as that’s way too long as list for me to read. I have some articles about this on the wiki, so just ask if you can’t find it later when you need it for your work. But in principle…
- The project will have limits of engagement. Even if answers below are different, and your users actually have lots of featurephone use of the Web, if the business has decided to only address how it works on iPhone 4 and above, there's no point in logging issues on Android or Blackberry much less featurephones. It's not ideal, but it's how the world works. Argue that in a different document and discussion.
- We talked about this, but you are an office worker. 25% of us remote work, so it's irrelevant if your office is the park, your back yard or Starbucks. You are therefore probably not who most of your users are. Try to emulate how they work. What do they expect, what do they use on their device right now and how often and the environment. Loud factory? You might be clever enough to realize sound won’t work, but did you know the frequency of many machines makes it hard to detect vibration also?
- Within the limits above, find out what devices and browsers your users employ. Ideally, you have specific research and maybe even analytics from the first launch or similar products. Otherwise, use basic knowledge of the industry and regions.
- Just last week I kept going outside to check on the readability and legibility of an interface, both as I designed it and as it was built. Because this information is to be consumed by mechanics who might be in repair shops, truck cabs or even outside. It has to work everywhere. Ideally, I'd account for dirty fingers also, and within the limits I have (I don't make phones) I did by making targets even bigger than usual for the basic functions. Editing the equipment name? That's a small target, because you do that when there's time to stop and think.
- (Only for Web) In some markets, the default browser is not used, or is no longer the default browser due to language or other regional needs. Know this, and check in the correct browser, or in several.
- How do people discover this? For apps, check the store screenshots and descriptions, pay atttention to icons and app names. For the Web, do NOT assume everyone starts at the home page. Simulate entry points from Google searches, shared links, or whatever is the really likely way they will enter the site. Check on sent emails, sms and make sure the links to the camera or maps all work.
- Make a chart of what you are going to test, both process and platforms, and mark it off as you go. Some of these can take all day. Or two days. You will forget what you did or where you left off at lunchtime.
- Tactically, what this means is that you have to get the devices your users will use, or maybe just a whole bunch of them to represent the range of devices, and see if it works. If this looks complex compared to the desktop web, you probably have just been ignoring a bunch of users on other platforms or other browsers already. Fragmentation isn’t a bad word, it’s just about supporting user choice, and well-designed, well-built products don’t have as many issues as you might expect. If it looks expensive, there are shortcuts. Device Anywhere is worth writing down, as a way to not have to buy a big pile of devices, and even to automate some of the testing.
- EXERCISE:How many people brought some printouts of a product to test? MAKE SURE THERE ARE AT LEAST ONE PER TABLE. Vote on which one you are going to use — real products are better so if someone is willing to share their work, use that — and evaluate using these sheets I am passing out. I made you use paper for various reasons, but mostly because it’s easier for several people to see them all at once. If the product you are evaluating is available on a computer, tablet or phone, share the link and some at the table can evaluate live, on the digital device also. If it’s a web product, you can even compare on different screens like I am doing up here. We’ll limit this to 20-30 minutes as usual, so you won’t finish. I would normally take 4-5 hours to evaluate a simple site, but you can get the gist.
- … I am starting to see lots of small, fast, nimble startups show their ideas and alpha products to actual people. Yes, usability testing just like big, serious UX groups have been doing for decades.That’s great and if you aren’t going to make a UX hire your next task, you should at least do this. But, there’s very little guidance on how to do it, especially for mobile, so even if you are experienced in usability you might be testing the wrong thing, the wrong way. Working with a real set of experts in this is truly beneficial, but basic usability testing doesn’t need a masters degree, a lab and a staff. Just try to follow a few basic guidelines…
- An aside. Much of my work in mobile is on a shoestring, or otherwise secondary to the important, core desktop Web work. Because they don’t have hardly any mobile users. I only get the job because “mobile is the next big thing” and they want some of that market they see the Facebook kids having. And every single time I drill into the analytics they have gathered (usually from their website), I find that they’ve been looking at the numbers wrong. One organization I worked with (and this is not an unusual example) said they had 95% desktop users, and 5% iPhones. Looking deeper: their tools was badly calibrated so all sorts of browsers including almost all mobiles were being called “Other” and years ago the analytics team decided to zero out this confusing “Other” category. It was 60% of their traffic. Over half their traffic was mobile, and they didn’t know. However your users engage, having basic (BUT ACCURATE) information from analytics can focus what needs to be tested face to face with users.
- But back to usability testing. You can get good results by sketching ideas on a bit of paper and letting users interact with the “system” (have another developer be “the computer”). But try to do it in their office, or at a desk like they would use. If mobile, tape it to a bit of wood, or an old phone and have them carry it while you follow them around.
- Find people with jobs similar to your real audience, and especially avoid anyone involved in the project. I went to my neighborhood auto repair shop recently to test out an auto parts finder on actual mechanics. Try to remove yourself a step and use friends of friends, if you have to recruit like that. Don’t use anyone at your company, or anyone in development or design unless that’s your audience.
- Do not do focus groups. Just trust me, it’s the wrong thing to do. Get one user, and one moderator at a time and run then through the process. Make sure they talk about what they expect, and what they think they are looking at. Reassure them you are testing the product, not them; say “there are no wrong answers” in the intro. And lie if you need to, that you are just testing, but didn’t build it. They will be more honest if they don’t worry about hurting your feelings.
- Don’t lead the test participants. Be careful what you say when writing a test plan, and let them fail for a bit before you assume they won’t get it. Don’t tell people to click on a link, but give them goals, then listen and watch how they try to get there. Only correct them after recording their actions, and if they have to go down a particular path to complete the test.
- Record, or write everything down. Confirmation bias is real. You will remember only what reinforces your pre-conceptions of how you expected the tested interface to work. Ideally, bring someone else along who can just take notes, or film the test on their phone.
- EXERCISENow we’re going to do a usability test of your product. We’re going to do this off the printed out bits of paper, just to show you that even low fidelity designs work. You don’t need the interactivity of the screen to test always. You can even test hand-drawn sketches, very effectively. Now, this is again going to be one where we cross tables. But I want everyone’s product that you just evaluated to be tested. SO, split your table in half. Half of you will keep the paper: 1 is a the test moderator. You will explain the product like you have been, in basic broad strokes. Sit across the table from the participant. 1 is the COMPUTER. You will present the right piece of paper to use the user. Only talk if you ABSOLUTELY have to, like if a popup would appear you didn’t bring, or something else interactive happens you didn’t plan on. 1 should take notes of what the participant does, and what they say. The other half will go to the table across the aisle, and be the test participants. Actually, only ONE of you will be the participant, the rest have to just watch.
- We DO NOT have time to make a test plan. This is a bad thing but it takes days of pondering to make a good one, and it is specific to the product, so I can’t give you a fake one. So you have to wing it. Basically, you need to come up with a simple task, that takes several steps or screens to accomplish, but can be done on the piece of paper you have. You just did the heuristic evaluation though, so maybe you found something you worry isn’t good. Use that. See if someone fresh to the product can do it themselves. When you get all settled, and are prepared, do not start. Indicate to me you are ready then we’ll do ONE MORE THING before you really start. WELL ALL WATCH ONE TEAM DO IT, WHILE I CORRECT AND ADVISE. LEAVE 10 minutes for the end!
- Two more key notes now that you’ve done a usability test of sorts. You will find a lot of complaints and failures. Look closely at the notes. No matter how badly one person does, it’s just one person and you can ignore it. Even without real statistical analysis, you can look at the raw numbers and find that only a relatively few problems are shared by most participants.
- Go back through the steps above, and think about ecosystems, structures and bigger solutions to fix your problems before changing anything. Separate users’ preference from their performance: generally you can ignore what people think the system should be like (suggestions to move things and change labels), and find better answers to the deeper issue instead.
- Ethnography is good! That means seeing people in their natural environment. Or even just tours. Here, Hallmark clients are showing off how and why the store is laid out like it is. It’s not a robust, scientific test but like the post-it exercise Monday, it fosters ideas in a way that cannot happen in a conference room.
- In case you haven’t picked up on that, or I accidentally implied any of the things I said are a new process, or steps in your existing process, they aren’t. You should use almost all of these during your design process, but routinely. If not hourly, then check for resilience and consider platform specifics daily. Eventually, you can do this automatically. It becomes second nature. To me, I am serious when I say this is developing a philosophy of design.
- Ask for Help –Lastly, there is a lot of information, scads of research, good guidelines, and a lot more mobile consulting out there than you might think. If you can’t hire an expert full time, try to get one in to help for a bit at those key junctures, and as early as possible. Assign existing people jobs to find information, and share it with the organization so you raise the level of knowledge in the new domain. You people: go back home and tell everyone what you learned here. Now, what didn’t I answer for you? What specific problems do you have with your organization, environment or users? GIVE AWAY BOOKS TO FIRST FEW WHO ASK QUESTIONS.
- So, whose confused, disagrees or doesn’t see how it applies to them?
- We should never expose the edges of the system like this, much less require the user to tap the screen (button or not) to have the system try again. We need to design and build with an understanding… no, an expectation of delay, and difficulty. Both technical delays and because of our lives. Users get interrupted, and switch platforms. Networks fail, and stall, and delay. We have to cache data, allow working offline, build for multi-channel, multi-device use cases. We have to automatically synch and not cause errors when there are mismatches. We should build resilient systems that encourage sharing so users can resume tasks when they get home, or get to work and sit down.
- When you write, or draw concepts, they should talk about services, data, sensors, networks and users. Not screens. Don’t just put your goals and objectives on the wall, or on the first page of the deck, but bake them into the diagram. This is what I think of as a Task Map, and my Customer Journey Maps look similar. With no start, no stop and no happy path. Lots of circles.
- Think about that. How would you design your product if it wasn’t for an iPhone screen, but for the whole world? I am not kidding, or weaving crazy tales. How does, say, Facebook work? Or Twitter?
- Storyboard. Think about processes from entirely the user’s point of view. Storyboards are a great way to force yourself to think about users, their context, and their behaviors off the screen.
- Of course, you can also do screens the same way. Draw comps parallel to the storyboard, or like this with bits of the user and context. And, you don’t need to settle on a platform for this. Here, it’s SMS, notifications and apps. Sketched out as part of the user task.
- It doesn’t mean you don’t do the best possible job when designing interfaces. But first, you allow arbitrary access, so there’s customer choice; they get to pick the platform they are most comfortable with.And you need to push to platforms that fulfill these needs. Any platform. Screen-free platforms, like this are critical not just for special classes of uses, but to assist everyone in using technology all the time. We get “temporarily disabled” so need vibration and voice readouts. And users become exposed to your information from several sources, so it becomes almost ambient. Think about where and how your information can do the most good.
- So, whose confused, disagrees or doesn’t see how it applies to them?