Uploaded byEverett McKay
Courageous Design
The keynote presentation by Everett McKay focuses on the importance of courageous design in UX/UI, emphasizing that great design requires intelligent risks rather than consensus-driven compromise. Key concepts include user-centered design, the impact of team culture on design decisions, and the role of data in guiding design while maintaining a balance between safety and creativity. McKay concludes by urging designers to strive for greatness in their work, challenging the prevailing mediocrity in organizational cultures.
More Related Content
![Designing with Lean UX : Rapid Product Design [UX Lisbon 2014]](https://cdn.slidesharecdn.com/ss_thumbnails/uxlisbon2014designingleanux-workshopslideshare-140604100358-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Challenge:Future] Made4Me](https://cdn.slidesharecdn.com/ss_thumbnails/challengefuture-made4me2623-130226113008-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Courageous Design
- 1.
- 2. This is arerecording of my Keynote presentation at Design Camp Boston/New England UX on November 6, 2010 Access video and deck from courageousdesign.com Copyright 2010 UX Design Edge
- 3. Who is thisguy? • I’m Principal of UX Design Edge • I offer UX/UI design training (web, live, onsite) and consulting • I specialize in helping non-designers and software professionals that don’t have design resources Copyright 2010 UX Design Edge
- 9. “You need to practice courageous design!” Prof.Keith Edwards
- 10. User-centered design Intuitive design Empathicdesign Multi-disciplinary design Collaborative design Participatory design Activity-centered design Defensive design Inductive design Trustworthy design Accessible design Humane design Copyright 2010 UX Design Edge
- 12. Courage is oftenthe difference between great design and good design Great design requires taking intelligent risks Copyright 2010 UX Design Edge
- 13.
- 14. Let’s look atcourageous design in Making decisions Asking questions Simplicity Personality Using data Team culture Copyright 2010 UX Design Edge
- 16. Great design requirestaking intelligent risks Copyright 2010 UX Design Edge
- 19. Driving consensus isimportant, right?
- 20. The goal ofUX design To fully engage your entire team to create products that your customers will love Copyright 2010 UX Design Edge
- 21. A typical jobdescription Smart, gets things done,… drives consensus across a multi-disciplinary team… Copyright 2010 UX Design Edge
- 22. Consensus on keydecisions is a good thing, right? Copyright 2010 UX Design Edge
- 24. “…a horse designed bycommittee” Sir Alec Issigonis
- 25. Why does thishappen? Group decisions political decisions Holistic vision minor details Design integrity compromise Copyright 2010 UX Design Edge
- 26. The art ofcompromise: Obtaining something that nobody wants but everybody can accept Copyright 2010 UX Design Edge
- 27. In consensus-driven environments: Smartpeople who get things done propose whatever gets consensus fastest Copyright 2010 UX Design Edge
- 32. Getting from goodUX to great UX There’s nothing wrong with good —it’s that getting to great requires a different approach Copyright 2010 UX Design Edge
- 33. While it’s alwayssafe to get consensus, there’s no courage in consensus or compromise Copyright 2010 UX Design Edge
- 34. Do you reallyhave to ask?
- 35. You can’t alwaysbe certain, but you can usually be right Copyright 2010 UX Design Edge
- 36. Suppose you havea question, and there’s a 99% chance you know the answer 1% chance you don’t Do you ask anyway? Copyright 2010 UX Design Edge
- 37. Apparently some designers don’tlike those odds Copyright 2010 UX Design Edge
- 41. The classic excuse: Wedon’t know for sure what users want or do Copyright 2010 UX Design Edge
- 43. The foundation ofall UX design: You can’t design for random people doing random things —you must design for specific targets Copyright 2010 UX Design Edge
- 44. If you don’tknow what users are likely going to do or want, you don’t know your users! Copyright 2010 UX Design Edge
- 45. The McKay/Turing Test: Ifa question would be stupid for a person to ask, it’s stupid for your program to ask Copyright 2010 UX Design Edge
- 46. While it’s alwayssafe to ask, there’s no courage in asking unnecessary questions Copyright 2010 UX Design Edge
- 47. The ideal UXis both powerful and simple
- 49. What is simplicity? Simplicityis the reduction or elimination of design elements that target users are aware of and consider unessential Copyright 2010 UX Design Edge Simplicity is the reduction or elimination of design elements that target users are aware of and consider unessential Simplicity is the reduction or elimination of design elements that target users are aware of and consider unessential Simplicity is the reduction or elimination of design elements that target users are aware of and consider unessential
- 50. Copyright 2010 UXDesign Edge “Everything should be made as simple as possible, but not simpler.” Albert Einstein
- 51. The classic excuse: Wedon’t know for sure what users want or do Copyright 2010 UX Design Edge
- 53. Q: What does0.0033% represent? A: The probability a user really wanted Caps Lock on while typing a password Copyright 2010 UX Design Edge
- 54. “I have only madethis letter longer because I have not the time to make it shorter.” Blaise Pascal
- 57. While it’s safeto offer everything, there’s no courage in complexity Copyright 2010 UX Design Edge
- 58. All software hasa personality
- 60. Whether intentional ornot… All software has a personality Copyright 2010 UX Design Edge
- 61. Showing your personality makesyou vulnerable Copyright 2010 UX Design Edge
- 62. Talk about doingthe opposite… Too often software is rude, unforgiving, and dull Copyright 2010 UX Design Edge
- 63.
- 64.
- 65.
- 66. While it’s safeto avoid showing personality, there’s no courage in being rude, unforgiving, or dull Copyright 2010 UX Design Edge
- 67. Good decisions requiregood data
- 68. “You can't manage what youcan't measure.” W. Edwards Deming
- 69. Data helps solvethe HiPPO problem
- 70. Making decisions basedon data is safe Copyright 2010 UX Design Edge
- 71. Copyright 2010 UXDesign Edge “Not everything that can be counted counts, and not everything that counts can be counted.” Albert Einstein
- 72. “If I hadasked people what they wanted, they would have said faster horses.” Henry Ford
- 73. A potential problem: Datais backward looking Copyright 2010 UX Design Edge
- 77. “…data eventually becomesa crutch for every decision, paralyzing the company and preventing it from making any daring design decisions. Yes, it’s true that a team at Google couldn’t decide between two blues, so they’re testing 41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3, 4 or 5 pixels wide, and was asked to prove my case.” Douglas Bowman
- 80. What you dowith data is the key While good design follows data, great design leads with it Copyright 2010 UX Design Edge
- 81. How to tellthe difference Do you say “The data proves that…” or do you say “Our interpretation of the data suggests that…” Copyright 2010 UX Design Edge
- 82. While data offerssafety, there’s no courage in following data Copyright 2010 UX Design Edge
- 83. You can’t escapeyour team’s culture
- 84. MMC Team: “Weship our org chart”
- 85. Copyright 2010 UXDesign Edge Conway’s Law: “Organizations are constrained to produce designs which are copies of the communication structures of their organizations.”
- 86. “We ship our culture!We must fix our culture first.” August de los Reyes
- 87. Every artifact an organization createsis an embodiment of its culture
- 88. Important question: Can individualdesigners create products that transcends their team’s culture? Copyright 2010 UX Design Edge
- 89. My answer: No! Anyorganization that doesn’t reward great design will produce mediocrity Copyright 2010 UX Design Edge
- 90. Attention managers: If youhave a great team shipping mediocre products, it’s because your culture rewards mediocrity Copyright 2010 UX Design Edge
- 91. No manager’s careeror compensation was harmed during the making of this mediocre user experience. Copyright 2010 UX Design Edge
- 92. The Innovator's CulturalDilemma Over time, team cultures drift towards safety and discourage courageous design Copyright 2010 UX Design Edge
- 94. “You can measurethe greatness of a user experience by the courage required to design it” Copyright 2010 UX Design Edge If you remember only one thing…
- 95. Want to learnmore? Check my website: uxdesignedge.com Subscribe to my blog Register for Good UX to Great UX Copyright 2010 UX Design Edge
- 96.
Editor's Notes
- #2 For Design Camp Boston/New England UX, November 6, 2010 For more information on Everett McKay, check http://www.uxdesignedge.com/about. To access video and deck, check http://www.courageousdesign.com. <Blurb> While you can design a good user experience by playing it safe, creating a great design often requires the courage to take intelligent risks. In this keynote, Everett McKay explores courageous design and how courage affects making decisions through consensus and the use of data, asking questions in UI, simplicity, software personality, and, most importantly, team culture. As Everett says, “You can measure the greatness of a user experience by the courage required to design it.”
- #4 Intro: Before getting started, I should say a little about who I am and what I do. <read slide> …based in St. Albans, Vermont
- #5 I started UX Design Edge in January of this year, but before then I used to work on the Windows team at Microsoft.
- #6 …where I was the “guidelines guy”, responsible for the Windows User Experience Guidelines As part of that role, I helped other teams do guideliney things. Consequently, I was on the Trustworthy User Experience team, where I wrote a draft of their Trustworthy User Experience Principals and Guidelines On August 3rd, 2008 I was presenting these guidelines to a panel of industry and academic security experts
- #7 Now keep in mind that this was soon after the release of Windows Vista… <don’t read> World wide release date: On January 30, 2007
- #8 And customers were complaining about security features like User Account Control Security features, quite frankly, tend to be annoying because X They appear out of context X Are hard to understand X And usually aren’t *directly related* to the user’s goals or task at hand
- #9 User Account Control was especially embarrassing, and had all three of these problems.
- #10 After my presentation, Professor Keith Edwards, an Associate Professor of Computer Science at Georgia Tech, said to us: <advance slide> “You, meaning Microsoft, need to practice courageous design!” That was a very thought provoking statement!
- #11 Intro: I’ve heard of many different ways of thinking about design before… Last bullet: I’ve even heard of…Humane design <advance slide>
- #12 For me, this was something of a revelation! Since them, I’ve put a lot of thought into the concept of courageous design And have found how important *courage* is in the design process
- #13 <don’t read slide> Intro: …and I’ve come to realize that <slowly> Courage is often the difference between *great* design and *good* design Playing it safe can actually prevent great design. Great design often requires taking intelligent risks
- #14 The opposite of courageous design is, of course, safe design. The goal of safe design is to keep risks to a minimum To be clear, there’s nothing intrinsically wrong with safe design… You can create a *good* design by playing it safe But to create a *great* design, you often need design courage
- #15 Intro: Today, I’d like to look at courageous design in <read slide>
- #16 But before continuing, I should point out that… of course, taking risks is risky and can lead to disasters
- #17 <don’t read slide> So I want to emphasize the word *intelligent* here. Great design often requires taking intelligent risks So if at any time during this presentation, you start thinking about features like this:
- #18 <don’t be in a hurry> Or of career moves that look like this:
- #19 <don’t be in a hurry> I want you to remember the intelligent clause in my proposition.
- #20 OK, let’s talk about how *courageous design* affects consensus-based decision making
- #21 Intro: The goal of user experience design is <read slide>
- #22 Intro: Many job descriptions look like this <read slide>
- #24 <don’t advance too quickly—spend some time to absorb> The problem is that a thing of beauty might not look quite the same
- #25 Once everyone on the team has signed off on it. Outro: BTW: If you don’t know Issigonis by name, you are familiar with his work. He is the famous British car designer responsible for the Mini, is credited with saying that “a camel is a horse designed by committee”
- #26 <don’t read the slide> Intro: Things happen for a reason, and the reason consensus-based decisions so often fall short is that X Group decisions ultimately become political decisions X In group decisions, the focus tends to shift away from the holistic vision to rather minor details (after all, not everyone on the team is a visionary) X Politics is the art of compromise, so design integrity gets lost
- #27 Intro: What is the art of compromise? It’s <read slide>
- #28 Intro: So what tends to happen in consensus-driven environments? <read slide> …those things tend to be safe, uncontroversial, *and often boring*. Outro: Remember the goal of UX design To engage your entire team to create products that your customers will love Regardless of your own experience, you have to agree that consensus-driven decision making is *at least vulnerable* to falling short of that goal.
- #29 The interesting thing about firing squads is that they are an example of team execution—quite literally— expressly designed where everyone is responsible for the task, and therefore no individual is responsible. Outro: What is usually missing in consensus-driven cultures is individual vision, authority, and accountability.
- #30 Now we all understand *why* it’s a bad idea to give a crazy guy who doesn’t know what he is doing full authority
- #31 What about giving authority to those crazy guys (or gals) who knows exactly what they are doing? In this case, Frank Lloyd Wright <don’t read this!> An unstated assumption: There is an important assumption here, which is that you have someone with the skills required to assume a role that requires vision, authority, and responsibility/accountability. Consensus-based design, which favors team/compromise over individual/vision/integrity, starts to look much better if you don’t have such talent. So, a problem with my logic is that admittedly there aren’t a whole lot of Frank Lloyd Wrights out there and your typical architect is a lot more collaborative and consensus building. Another model that is more common and even more extreme is the role of the lead chef in a restaurant. Chefs never collaborate with the “stakeholders” or get consensus with their team. They have vision, authority, and responsibility. They need this power because they have a lot on the line—if they fail to delight the customer, they lose their job. But note that in the world of restaurants, chefs are far more likely to fail to delight their customers by being ordinary than they are for failing to achieve consensus. The keys: Greatness requires vision, authority, and responsibility/accountability. It doesn’t require consensus. It does require everyone on the team to deliver, but you can have great collaboration without consensus. To really drive this into the ground: The design process is highly iterative. I’ve seen teams waste an enormous amount of time to get consensus on details that were quickly rendered moot by the next iteration. An effective consensus builder must focus the team’s energy on getting consensus only on the things that matter.
- #32 I believe that only an individual has the vision and integrity to design something as great as Frank Lloyd Wright’s Fallingwater. Imagine what Fallingwater would look like had it required the consensus of 10 program managers across 10 different teams. What kind of compromises would have been made? What would be the nature of those compromises—would they all have been what’s best for the customer? And even though FLW had a reputation for leading his team with a rather firm hand, do you think anyone on his team gave this project *anything less* than their full measure of devotion? <Don’t read--keep it rhetorical> My answer: an ordinary house by a stream
- #33 <don’t read the slide, only the notes> Intro: Now to be clear, there’s nothing wrong with *good* In fact, quite often my advice to teams is to focus on getting to good and not worry about being great or trying to do too much—because that isn’t right for them or even necessary for their project. Rather, my point is that getting to *great* requires a different approach—you can’t get there by playing it completely safe.
- #34 Intro: <read slide> Outro: You might be able to obtain *good design* through consensus, but *Great design* requires individual vision, authority, and responsibility *and* a fully engaged team to help realize that vision.
- #35 OK, let’s talk about how *courageous design* affects asking questions As you recall, asking unnecessary questions was what lead Prof. Edwards to give his inspirational thoughts about design courage.
- #37 Intro: Consider this: <read slide> Outro: And to make this interesting: let’s suppose that the consequences for getting this wrong are minor. It’s not a big deal. Do you ask anyway?
- #38 <read slide> Because there are just so many examples of unnecessary questions out there.
- #39 Intro: Here’s an example on Expedia, where I’m traveling from Burlington, VT to Ontario, *California*. Apparently my request wasn’t clear enough, Expedia asks me if I really meant <read list> “They just wanted to make sure….” With only the *smallest amount of courage*, they could have gone way out on a limb and chosen the perfect match without asking.
- #40 Intro: It’s not just Expedia, there are many other such examples. Here’s an example from Bing Maps, where I’m traveling from St Albans, VT to the Stowe Mountain Lodge. Here Bing asks me if by “Stowe Mountain Lodge”, I really meant <read slide> “They just wanted to make sure….” With only just the *smallest amount of courage*, they could have gone way out on a limb and chosen the perfect match without asking.
- #41 Here’s one example of literally thousands of unnecessary confirmations out there. Here, Outlook gave me a reminder, which I just dismissed. Now Outlook is asking me <read confirmation>. If I had to chose one common UI design pattern that best embodies the lack of design courage, it’s the “Don’t show me this again” option. Yes, a lot of people like this option, but for me it proves that the designers lacked the courage to make the hard decision. This option shows that the designers of Outlook realize this confirmation is annoying and unnecessary, put left it in the product anyway—just in case. A much better design, which would require *only the smallest amount of courage*, would be to not ask me the question in the first place.
- #42 Intro: Things happen for a reason, and the reason for these unnecessary questions is always the same: People say “We have to ask because… <read slide>” Outro: To that I say <next slide>
- #43 “bull!”
- #44 Intro: The foundation of all user experience design: <read slide>
- #45 Intro: <read slide> Outro: Not asking the question requires you to know your users and take a chance—however small—of being wrong. By contrast, always asking when you aren’t *completely sure* is playing it safe. It’s also really annoying.
- #46 Intro: Here’s what I like to call the “McKay/Turing Test” for asking questions. <read slide>
- #47 <read slide> Outro: You might be able to ask unnecessary questions in a *good design*, but *Great design* requires you to know what your users want without asking
- #48 Let’s talk about how *courageous design* affects simplicity
- #49 Simplicity is a crucial element of great user experience design. While designers want to have simpler user experiences, they often have a lot of trouble doing so.
- #50 Intro: <read slide carefully> Some people have noted that my definition of simplicity is a bit ironic because it’s rather complicated. Let’s apply the definition of simplicity to itself and see if there is anything unessential here. Reduction or elimination Reduction or elimination is crucial to simplicity because that’s what makes it distinct from ease of use. You can make something easy to use by adding stuff. To make it simpler, you have to remove stuff. Awareness of target users Managing awareness and perception is crucial because it’s the perception of simiplicity—not necessarily the reality—that matters. This concept is essential for having both power *and* simplicity—many people falsely believe that simple UIs can’t be powerful. Consider unessential And to be clear: removing the essential isn’t simplicity, it’s just bad design
- #51 This is exactly what Albert Einstein meant when he said: <read slide> <don’t read> Another great quote is Alan Kay's "Simple things should be simple, complex things should be possible."
- #52 Intro: Things happen for a reason, and the reason for complexity is often the same: People say “We have to provide all these commands and options because… <read slide>”
- #53 Well, you already know what I say to that! The key to simplicity is to realize that what users *will do* is far more relevant than what they *might do* You must optimize for the probable not the possible …and to do that requires you to take full advantage of context To obtain simplicity, focus on what is likely; reduce, hide, or remove what is unlikely; and eliminate what is impossible
- #54 Intro: For example, <read slide> The key to simplicity is to realize that what users *will do* is far more relevant than what they *might do* You must optimize for the probable not the possible …and to do that requires you to take full advantage of context To obtain simplicity, focus on what is likely; reduce, hide, or remove what is unlikely; and eliminate what is impossible
- #55 <don’t read the slide at all> The thing about simplicity is that it requires more design effort. It requires you to understand your users, who they are, and what they do. Refining a design down to providing only what users need when they need it is very hard work.
- #56 It’s actually much easier from *the design point of view* to offer everything.
- #57 But it takes courage to keep things simple …to remove choices …to say “no”—sorry, you can’t do it that way. …and to know your customers well enough to limit the experience to only what users really want. BTW: For those of you who aren’t familiar with In-n-Out Burger, what’s on this slide represents their *entire* menu.
- #58 Intro: <read slide> Outro: You might be able to have some amount of unnecessary complexity in a *good design*, but *Great design* requires you to eliminate what isn’t really necessary
- #59 OK, let’s talk about how *courageous design* affects software personality
- #60 Users aren’t robots. Rather, users are emotional They have feelings, they want to be respected They have a lot on their mind They have an imperfect understanding of how things work They make mistakes They need motivation to do inconvenient tasks They don’t particularly enjoy being bored Users aren’t robots, and in a great user experience, they aren’t treated like one. <don’t use> It’s notable that in 2001, HAL had more human emotion than the humans!
- #61 <don’t read slide—but OK if I do> Personality is the characteristics of a program that connect emotionally with users All software has a personality, so it’s better to have one that’s carefully designed than accidental Personality is unavoidable—even having no apparent personality is a type of personality. Goal is not to make software behave like a person, but to have those the right personal and social attributes Software is designed by people, and users recognize this. Make your software feel like it was developed by intelligent, thoughtful, friendly, and caring people. Alan Cooper once said that “If we want users to like our software, we should design it to behave like a likeable person.” <Source> http://www.testingspot.net/archived/ac0699.pdf
- #62 Intro: <read slide> There’s always a chance that people won’t like your personality There’s a chance that people might find it offensive It’s easier to play it safe and try to hide it.
- #63 Intro: <read slide> Outro: Typically, such software is designed without any thought about its personality.
- #64 <don’t read slide> Intro: We should have the same standards for human-computer interaction as we do for human interaction. Polite, respectful software recognizes that there is an emotional human being at the other end of the interaction Rude software manifests itself through a variety of ways, such as: X Having a rude tone, where tone is attitude a UI conveys to the user X Interrupting users with issues that aren’t relevant to the task at hand X Drawing unnecessary attention to user mistakes X Putting the software’s needs ahead of the user’s needs. X Not remembering user input or paying attention to context. This error message example is interesting because it makes a token effort to be polite with “Oops!” and “Please”, but it’s inner rudeness shows through with the big red “Error” heading, the cultish looking error icon, and its serious over-communication over a fairly minor problem. *Great* design has good manners and social behavior.
- #65 <don’t read slide> Great user experiences are designed for people, not for robots or for technology. People have an imperfect understanding of how things work Users make small mistakes all the time. X They double click instead of single click X They miss targets by a few pixels X They don’t read instructions carefully X They forget things X They don’t know what things are called or how they are spelled When users do something slightly wrong but their intention is clear and unambiguous, *great designs* have the courage to do the right thing anyway. They “just work.” In this example, note how I got every word wrong in this search, yet Google did exactly the right thing anyway, *without asking*.
- #66 Intro: I’d like you to think about the most boring task in the world… <pause> OK, got one in mind? Now if you’re like me, that most boring task probably involves filling out some kind of form. Wufoo is a web-based app that helps you create, use, and manage forms. It has *every right* to the be most boring app in the world, yet it’s not. It’s loaded with personality and is a joy to use. BTW: Note that this is a solid error message. It clearly and concisely states a problem and its cause, and provides a clear solution, without making users feel stupid by drawing unnecessary attention to their mistakes. <unused> They could have easily played it safe and used a standard (crappy) error message like this: Wufoo <error icon> Invalid command! You have 0 report(s). [ OK ] Also, Paul Hibbitts pointed that Wufoo can do this only because they have such a high level of usability. I completely agree. In fact, for the internal Software Personality guidelines I wrote at Microsoft, the first thing I stressed is that you should only worry about personality once you have the core usability nailed. Try to be cute with a crappy UX and people are going to hate you.
- #67 Intro: <read slide> *Great design* requires proper social behavior.
- #68 OK, let’s talk about how *courageous design* affects making decisions using data. <sources> See http://www.uxdesignedge.com/2010/03/nbc-olympic-coverage-and-courageous-design/
- #69 Intro: W Edwards Deming is famous for using statistics for improving product quality, especially when he was in Japan. He is credited with having said that <read slide> Using data is a great way to make decisions. Certainly, decisions based on data are much stronger than those based on personal opinion. Windows, Office, MSN/EXP teams at Microsoft and certainly Google and Amazon have all done *amazing things* by making user experience decisions based on data.
- #70 <read slide> where “HiPPO” stands for the “HIgest Paid Person’s Opinion” In his blog Occam’s Razor, Avinash Kaushik, a web analytics expert, noted that “The HiPPO quashes ideas because they buck the traditional way of doing things…” Using data is a great way for you to challenge the HiPPO without harming your career
- #71 Intro: <read slide> And I should stress that practicing courageous design without understanding your users is a fool’s errand. Remember what I said about taking *intelligent risks*. Who can argue with data? Well, I will…I have observed a tendency to make decisions with data rather mindlessly. They follow data rather than lead with it. ….and so will Albert Einstein…
- #72 Einstein once noted that <read slide> Here Einstein is dealing with what I call the “proxy problem”, where the things we care about often can’t be measured directly, so we try to measure them indirectly by measuring something else. Is that metric an accurate reflection of what we really care about? Maybe…
- #73 Then there’s Henry Ford, who famously remarked <read slide> It’s worth noting that W. Edwards Deming was an expert at manufacturing process quality. As designers, we are dealing primarily with users and user goals, opinions, and desires. Those are a lot harder to measure. Now to be clear: the point behind this quote isn’t to ignore your customers, but rather that to achieve *great design* you have to understand your customer *better* than they understand themselves.
- #74 Intro: <read slide> Customer data reflects customers’ desire for minor improvements of their current experience—the status quo Data does not offer insight to their future desires. Consequently, customer data can be used for evolutionary design but data by itself rarely leads to revolutionary design.
- #75 While making decisions based on data is certainly is safe, it is not entirely risk free. Using data successfully requires you to have the correct interpretation. *Using data isn’t a substitute for thinking and judgment.* Turns out two of the biggest product design and marketing disasters ever were based on mindlessly following data. The most famous one is the Ford Edsel. The marketers at Ford discovered that they had a hole in the product lineup, and the Edsel was intended to fill that hole. The Edsel was a flop. People didn’t get it. Turns out people really don’t buy cars based on market segmentation data.
- #76 Another well known data-driven marketing disaster was New Coke. In the mid-80s, Pepsi was consistently beating Coke in their blind taste tests, so they formulated New Coke to beat Pepsi at their own game. Turns out people really didn’t chose their preferred carbonated beverages based on blind taste tests.
- #77 Another challenge with using data is that while data points may be valid individually, there is no guarantee that they can be combined harmoniously.
- #78 Intro: you might have heard this story… Douglas Bowman was the Visual Design Lead at Google, resigned last year. He posted his now famous resignation letter on his blog. Let me read you a key passage <read page slowly> Outro: While you can do great things with data, clearly to you take it too far. Data isn’t a substitute for having style and taste, nor is it a substitute for thinking. <source> http://stopdesign.com/archive/2009/03/20/goodbye-google.html
- #79 There are many great user experiences that are done *just because*…even if you don’t have data to prove your case. “…Not everything that counts can be counted.”
- #80 Finally, something needs to be said for all the extraordinary things mankind has done *with absolutely no data whatsoever*.
- #81 Intro: <read slide>
- #82 Intro: <read slide> First approach: that’s following Second approach: that’s leading
- #83 Intro: <read slide> You can achieve *good design* by following your users, but achieve *great design*, you have to lead them. Great design requires insight, creativity, and boldness to go beyond the data. Courageous design requires saying “we’re going to give you something you didn’t ask for, but we believe you might like anyway.”
- #84 OK, let’s talk about team culture I’ve saved the best for last!
- #85 When I joined Microsoft in 2000, I was initially on Windows Server team that was trying to improve the Microsoft Management Console. One frequent observation I heard was “We shipped our org chart” If you checked the MMC snap-ins (in the tree on the LHS), you would see that *sure enough* they largely matched the org chart This was a totally new concept for me because my background was mostly at working at very small companies where issues like this were never a concern.
- #86 Intro: Turns out this observation wasn’t entirely new. In fact, in 1968 Melvin Conway observed that <read slide slowly> Outro: I suppose Conway’s Law in part explains why some companies have so many reorgs. Source: http://en.wikipedia.org/wiki/Conway%27s_Law
- #87 But it turns out there is much more to it. Years later, I attended a talk by August de los Reyes, where he said <read slide—repeat first sentence> You cannot improve the quality of what your team produces without first addressing any cultural problems that inhibit great design.
- #88 <don’t read slide> Intro: It took me awhile to fully appreciate this idea, but it is absolutely true! The projects your team takes on, plus it’s X Vision X Goals X Team members X Recruiting system X Reward system X Decision making process X Willingness to accept alternative points of view X Willingness to have attention to detail and fix small bugs X And of course, willingness to take risks all are a reflection of its culture Your team’s culture determines what actually gets done “Every artifact an organization creates is an embodiment of its culture.”
- #89 Intro: So here’s an important question: <read slide>
- #90 Answer: (Uhhhh) No! <read slide> Outro: You ship your culture! Every artifact an organization creates is an embodiment of its culture
- #91 Intro: <read slide> Look no further for an explanation!
- #92 Here’s a software advisory label I’d like to see for companies with poor design cultures: <pause, don’t read slide> If the shoe fits…
- #93 Intro: <read slide> Outro: Thus making courageous design and intelligent risk taking progressively harder to do. I’m not completely sure what to recommend here, except that like any 12 step program, the first step is to admit that you have a problem. <Source:> Clayton M. Christensen The Innovator's Dilemma discusses values but not culture.
- #94 OK, let’s wrap up!
- #95 Intro: I want to leave you with one parting thought. Just as Steve Krug has established the principle that you can measure the quality of a UI by the amount of thought required to use it… I would like to establish the principle that “You can measure the greatness of a user experience by the courage required to design it.”
- #96 Intro: <read slide> Good UX to Great UX is a fun one-day class that provides you with 10 practical ingredients of a great user experience to help you to take your product to the next level. If you liked this keynote, you’ll love Good UX to Great UX