Avoiding the Heuristic Solution: Moving past functional and correct to joyful and inspiring
•Als PPTX, PDF herunterladen•
4 gefällt mir•4,220 views
Slideshow for the O'Reilly Webcast "Avoiding the Heuristic Solution: Moving past functional and correct to joyful and inspiring" To be given on 31 Jan, 2012 -- Sign up for free, now: http://www.oreillynet.com/pub/e/2102 Interactive systems can be easily made foolproof and practical, but joy and delight all too often elude the final product. This author of two books on design process and interactive patterns has discovered that strict adherence to these same processes or patterns can result directly in functional, but ultimately boring interactive products. In this discussion, you will learn how to avoid the safe answer, while still embracing proven patterns, best practices and user feedback. You will also discuss how to recognize this problem, the principles to avoid these pitfalls, and how to implement tactics to encourage innovative design for your users, and that works within your organization.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (20)
Ähnlich wie Avoiding the Heuristic Solution: Moving past functional and correct to joyful and inspiring
Ähnlich wie Avoiding the Heuristic Solution: Moving past functional and correct to joyful and inspiring (20)
Mehr von Steven Hoober
Mehr von Steven Hoober (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Avoiding the Heuristic Solution: Moving past functional and correct to joyful and inspiring
- 1. Avoiding the Heuristic Solution Moving past functional and correct to joyful and inspiring 1
- 2. Patterns for interaction design 2
- 3. Patterns are • Universal • Generalized • Organized • Explained • Best practices 3
- 4. Patterns are misunderstood • Reactionary • Single view • First solutions • Rote solutions • Too high level 4
- 5. Avoiding the heuristic solution • Everyone understands radio buttons… • Consistency… • Always use best practices… 5
- 6. Avoiding the heuristic solution • Reduce clicks. • Improve clarity. • Maintain task focus. • Reduce cognitive load. 6
- 7. We’ll just… • Use a “standard” form. • Put it in a Pop-up. • Add a CAPTCHA. • Make them fill in the email twice. • Add a help page to explain it. Or you say… • Let’s make it look like iTunes. • Just like the iPhone’s [anything]. • What is [the competition] doing? • What would Amazon do? • You can’t fight best practice. 7
- 8. Be a conscious designer 8
- 9. Design methodologies to success • Understand the problem, and write it down • Leverage your team • No idea is worthy • Your competitors are not wizards • Embrace your constraints • Collaborate • Seek outside input 9
- 10. Understand the problem Put the markers down. First time, every time, talk to the customer, their workers, the users. They know more about their business than you do. Ask them about it. 10
- 11. Write it down 11
- 12. Leverage your team 12
- 13. Studio methods • 100 thumbnails • Moodboard • Sketch • Model • Co-design • Talk-aloud • Scissors and tape • Gesture and act 13
- 14. No idea is worthy Don’t do a little dance for your great idea. I promise it has flaws. Consider components individually, and look for flaws. 14
- 15. There are no design wizards Inspiration is fine. Copying is pointless. Follow your process to find the right answer for your business, and the current world. 15
- 16. Embrace your constraints Brainstorming doesn’t work. Working within your constraints adds focus to any design session and fosters ideas. 16
- 17. Collaborate Don’t just work together, collaborate. Use everyone’s skill, and knowledge, to find the best solution. 17
- 18. Seek outside input Systems, process, and business knowledge is held by specialists you won’t see. Unless you go looking. 18
- 19. Validate, and Iterate 19
- 20. Ask users Research can be quick and cheap. • Paper • Friends & family • Co-workers • Diaries 20
- 21. And now your design is perfect What could possibly go wrong? Well, execution. 21
- 22. Which I’ll talk about next time User Centered Execution for Mobile UX Designers Wednesday 29 February 2012 22
- 23. Steven Hoober steven@4ourth.com +1 816 210 0455 @shoobe01 shoobe01 on: www.4ourth.com 23
Hinweis der Redaktion
- Thanks…
- Naturally, O’Reilly is hosting this presentation because I wrote this book for them. But also because I had more to say. While writing it, I essentially raised more questions than I feel I answered.While it’s a pattern book, I am not entirely comfortable with a pattern-centric design methodology, such that I actually wrote a little on this very topic in the introduction for the book.
- There are many, many online pattern libraries, which are effectively showcases of shiny design. But patterns have a lot more going for them. And you have to understand these features to understand how to use them.Patterns are:Universal – They apply equally to everything possible. Mobile patterns are surprisingly similar to desktop patterns. And overlap massively with kiosks, TVs, tablets, game consoles, etc.Generalized – Specific implementations are not useful as examples, as their specifics are not yours. You need to understand what is part of the pattern, and what is not.Organized – Very often, there are multiple choices. Without good structure, indexing and cross-referencing, you don’t know what the options to choose from are.Explained – Just like in your design specifications, pictures aren’t enough. You need to know what the pattern does, and why it does this. You need to be able to find the reasons (rooted in cognitive psychology, or human physiology) behind each one. Without the reasoning, it’s just a guess.Best practices – Very simply, never just common practice. Do not assume a common practice is good until you prove it. But patterns are also…
- …mis-understood. Obviously, this is not a key attribute of patterns that we want to have. But it’s true. Patterns are mis-understood, and therefore mis-used:Design solutions are Reactionary and solve for point problems, instead of considering the entire system.Even when larger solutions are found, they are Single view: or only for one screen, one device or one platform.The first satisfactory solution is accepted, and rapidly becomes entrenched. There should always be incentives to keep working, to find the best possible solution.There is likewise no incentive to find unique, interesting or differentiable solutions. The Rote solution, or the published pattern, is used without modification (another reason I don’t like to give examples).Patterns that do consider solutions generally lead to excessively High-level design, with no reasoning (or an incomprehensible one). VizDs and developers won’t understand what part is important so will modify it and miss the point. I tend to derisively call all of this the “heuristic solution.” It’s not /bad/ per se, in fact the reason we’ve been getting away with it for years is that it checks all the boxes, but it’s not inspired, and is never /truly/ satisfactory. And I mean “satisfactory.” It might even pass CSAT measures, and show improvement. But it levels off and you never get up to that really top-tier, no matter what you do.
- Let’s try an example on for size. Very regularly, in discussions on design forums, LinkedIn groups and the like, someone will ask for input on a solution. And far too many responses offer up “best practices.” For example, just a couple weeks ago, there was this question involving three options and defaults and labeling. Everyone says, oh, no not a pulldown. But answers involve: “users understand radio buttons” and “why do anything but best practice?”Well, look at it more seriously. This solution offers: Two clicks when it’s one action only. Click a radio, then the Save button.Research shows that real users do NOT understand the difference between radios and checks.And, it also shows that understandings of details like this go out the window when users change contexts. No one understands form elements when on a kiosk, for example.It’s hard to call this a “best practice” anymore, with those answers. So, what else could you do here?
- A simple answer for something like this is to simply provide the buttons directly. This, to me, is a best practice, but to many it’s thinking outside the box. And, I’ll admit, this example is mine. I went with the radios, and let people spend an extra click and have the possibility of indication and selection overlap, all for consistency and ease of implementation. I now think it was the wrong choice and this would have been better. For your designs to move from acceptable to exceptional, you need to provide yourself and your organization an atmosphere in which new ideas can be discovered, and fostered.
- That was just one, simple example. If you find yourself (or your team) reaching out to simply copy “standard” implementations, or copy existing, well-known products, stop and think about it. Do you want your product to look like everyone else’s? Isn’t differentiation key?And, how do you know it’s the right solution for YOUR situation, and your users? I mean, it might be good. But you have to know. You have to prove it first.
- The most important thing, by far, is to be aware of what you are doing. At any step, be able to explain to yourself, to your team and to your bosses what you are doing. And why. If you do that, it’s hard to go wrong with any design decision. (It also helps get rid of disagreements, because there’s less opinion).
- But, I’ll make it easy on you by also giving a bunch of specific tactics you can work towards.
- Before even starting to design anything, ask questions. Perform user interviews, ask the business what they want, and gather any other information about current and expected usage you can. Develop measurable objectives, stick to them during design, and be sure to measure after it launches. Without feedback, you cannot learn.Try not to draw. This is hard to do, for me at least, but sketching concepts early will tend to lock you into that thinking. You might be on the wrong track. Keep away from this, and seek to understand the problem space first. If you are wondering, this is a project I did for Hallmark, where one of the first things we did was have them to the office for two full days of interviews and data gathering, kicked off with a visit to a store, to really understand their current processes, needs, and gaps.
- Then, write down what you came up with.I like to make brief, clear documents like:Problem StatementsProduct VisionValue StatementsDesign ObjectivesDesign PrinciplesDesign GoalsAnd then, once everyone has agreed to them, I put them on the wall. Just like you may have seen Personas go up, so everyone can refer to them, I like to print these out nice and big and stick them on the wall of the team room, or over every pod. For designers, product owners, and developers.
- The best ideas come from individuals, or small teams, working independently. To get the most good, unique ideas, task those individuals or small teams to develop quick, independent designs and regularly share and regroup, iterating to a final solution.Manage your teams to make sure they work well together, and keep working as a team, not as individuals.
- A number of these processes are what I call “Studio Methods,” as I learned how to apply them in Design School studio classes, which always threw together groups of students to come up with a single solution. Which solution works depends on you, your team, the project, the environment you work in, etc. Here’s a few key ones:100 thumbnails – The visual side of brainstorming, by yourself, sorta. Stretch your limits by forcing a slightly-impossible number of variations. If you have three ideas, and cannot think of a fourth, insist you make 10 more. Crazy or not, they get your brain working. One may be brilliant.Moodboard – Grab not so much good ideas, as good thoughts. From non-competitive industries. From advertising, and non interactive media. If they inspire you, specific to the project, stick them on the wall. Sketch – Draw. Whatever you do, draw the designs. Rapidly. Get the ideas down. Model – The 3D version of a sketch. For mobiles, this can be key. Even if you aren’t building hardware, tape designs to old handsets, or blocks of wood, or whatever. It matters. Co-design – At least occasionally, bring everyone together, as shown, and put up paper or give them whiteboard markers. Everyone can draw at more or less the same time. Talk-aloud – Remember when I said you should be able to explain your reasoning? Well, the next step is to explain your idea WITH the reason. We need to add buttons SO the user can selection options BECAUSE they are easy to read, and easy to use. Scissors and tape – Be ready to cut apart printouts of your designs, and tape them back together, especially as a team exercise. More on this next. Gesture and act – Even if not in the right environment, even if the device is a tape dispenser, acting out actions can help explain or help you understand the end user.
- Many of these involve individuals working independently. So, everyone comes back with ideas and you review them as a group. Then you evaluate not complete designs, but each component. How does it fit into the overall concept. Assign components that are similar to other designs, so they are combined in interesting ways, and people get outside their comfort zones. When working with design concepts, whether evaluating competitor sites, or with the design teams above -- remember to approach the design from a modular point of view, and evaluate the suitability of each element to the overall goals, and process. Do not just accept (or reject) whole designs.Even with one idea, whether just trying to determine if the idea is good yourself, doing an eval or whatever, do not fall in love with the idea so much that you:1) Look at it as a whole2) Miss the flaws.Deconstruct it, to understand what it is, what it is made of (patterns, components!) and then how it might NOT work. Deconstruct means: feel free to break out the scissors and tape. Or erase and scribble and draw lots of arrows on the whiteboard. This can be a challenge to your brain, since we like winners and losers. But stretch yourself and you’ll be surprised.
- I’ve already sorta said this, when I keep telling you not to clone screenshots, but it can go deeper. Your competitors and forefathers do not have the magic formula. Some just have better cultures of design.Some just lucked into it. When you are required to look at the competition, or the great previous-generation ideas, recognize that business models, customers, and goals are not the same over here, or in this day and age. Inspiration is fine – inspiration is to be encouraged -- but use good process to find the right answer.How many of you carry a Walkman phone? Of course, none. But for /years/ after the iPod came out, every pundit was sure Sony would come and crush the market.Didn’t happen, because Sony (apparently) builds good products, not good ecosystems. It seems no one was able to turn their tape player era devices into the digital music era.
- Brainstorming is for suckers: As we learned it in Grade School, it doesn’t work. Boosters will say it does, and the counter studies aren’t doing it right. To which I say: no one does it right, such that I never want to call it “brainstorming.”There are bad ideas.There are ideas that you shouldn’t even consider, as they are out of scope.Instead, I like to set preconditions and say Embrace your Constraints.Whether in concepting exercises, workshops or as individual designers, only work within the domain, set preconditions, and remind everyone that the goals and objectives define the desired end state.However, I have to warn you that the constraints need to be well-defined. They should be written down somewhere early on, while you are working on the Design Objectives. Sometimes, there are a lot of them. Here, for example, is a chart of desired features by persona, which was used to set the scope. THEN, after a couple weeks of research and analysis, we got into design solutions for these problems.
- (I have a 10,000 character essay on collaboration, which you can find on my blog. So this is necessarily a summary. If collaboration eludes you, or like I was, you get blamed for being not collaborative, check it out.)Design teams will, ideally, have a variety of individual skillsets, or at least multiple individuals, each with their own background and opinions. Use the individual skills of the team members to find solutions and explore concepts.Some other key attributes of good collaboration have been outlined above. Be a conscious designer, so you can discuss your ideas, or defend them. And not because you like it; defend only what you know to be true from experience.Collaboration can be very informal. When you get into it, you will start asking advice for even simple behaviors and problems. This sort of activity is why some people like open-plan offices. Just turn around and ask the team.
- Beyond collaboration, get input from people outside the design team. This is especially good in big places that have been around for decades, or centuries.Not everyone has all knowledge of the arbitrarily complex systems we work on all too much, so cross-functional collaboration can have great value in confirming concepts, getting input on the viability of concepts, and discovering tangential solutions already considered, or in progress somewhere else in the organization.This is not just useful for the gathering of information, which you should do up front, but to confirm that your design works. Often, those same people can add more value after they see what you mean. “Oh, you are using that information. Have you talked to these guys about their project in the stores?” etc. Do what it takes to get them there. If you have to, feed them.
- At each step of the process, you should be referring to the Design Principles, Design Objectives, Project Goals, Personas and whatever else you determined and set at the beginning of the effort. I have put this here as one step, at the end, but ideally you are doing this all along.Each working team (or here, the team room where everyone lives) has key documents up on the wall for easy reference. And, it falls back to some of the Studio Methods. When you come up with a solution, don’t just explain it as part of the IA, or the system, but how it fits into these principles. Say you have an objective of Trust, and have two design options on the table (which meet all other objectives broadly equally): the one that can more clearly be said to engender Trust wins. Every time.On the other hand, maybe your solution is brilliantly beautiful, but violates the objective of “no popups.” Always be open to re-evaluating the objectives and principles. These are essentially a hypothesis, and you haven’t proven it yet. Consider other solutions. This is NOT to say that you can just ignore the objectives. You must always be conscious and deliberate. If you change an objective, everyone has to buy in and sign off, and you need to go back and evaluate the whole project for impacts of this change. Changing your point of view like this can result in the best work you’ve done, but it’s not trivial.
- If you are designing products for end users, then at some point you want to make sure you get their feedback. Real user data is key to this, so at some point you need to gather it. And before I get to that, I want to mention that all data is good. I consider user information to include:AnalyticsCustomer SatisfactionLab studiesMarketing and needs researchCall center ratesSite feedbackYes, some you have to be careful with, and most of these require the product to be out in the wild. So, when still designing it, how do you get past evaluative techniques and make sure it’s something people want to use? Well, ask them. I am not going to get deeply into research, because it is a big field and there are many experts and other good presentations on the topic. Look it up. But a lot of people are only familiar with research taking lots of money or time. I have gotten plenty of good results from very cheap research in just a few days. Paper Prototypes – At their core, as shown here. The design is drawn on paper (here, at scale, with a handset frame around it). There’s a moderator to ask questions as usual, and another person (who usually doesn’t talk) is “the computer.” They move bits of paper around based on user actions. If a pop-up appears, they paste the “pop-”up piece of paper on top of the frame. The paper can even be hand-drawn, so this can be very cheap and quick to run. Similar results can be found with other types of quick-and-dirty prototypes. If you need to test an interaction, make it up in some digital tool, but don’t worry about making it very good or complete. Friends and family – Who do you use for these studies? Well, whoever you can get. If it’s hard to recruit, use friends and family. Or co-workers. But not those who have worked on the project. Put up a poster or a note on the corporate intranet, and let people come to the cafeteria to give feedback on the new product. Just like a big lab test, but quick and cheap. Ethnography – Remember people use products in specific environments. A call center worker uses a desktop computer in a very different environment and manner than you do at home. If possible, see them in their real work space. Or, ask people to track their daily use, or try out some version of the product on their own if you can make it work for even one user at a time. It can be expensive and difficult to follow people around, so let them take photos, or videos, or write in a diary how they use the product. Or how they would use a product you’ve shown off in the lab. This, then, becomes as valid a bunch of feedback as anything you’ve gotten before from the team. As I mentioned on the previous slide, whenever you get more valid input, reconsider everything and make sure that your design is on track, and your objectives are true.
- So, once you have done that, preferably a few iterations of it, now you have a great design settled on, and bought into, and not just by the business owner, but by everyone in the whole place, hopefully.And now the gulf of execution. No, not Don Norman’s gap between stimulus and understanding, but the difference between what you give design and what comes out of the development team.
- Questions?
- Of course, I also talk about design topics as well as the patterns in the book Designing Mobile Interfaces.Be sure to visit 4ourth.com to read it online, and get updates, especially to the design and test resource lists. And, please add to the discussion if you have other information. This presentation is already up on Slideshare, so you can download it whenever you want. But now, what questions do you have today?