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 for Design Camp Boston 2010, 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.”
2. This is a rerecording 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 this guy?
• 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
25. Why does this happen?
Group decisions political decisions
Holistic vision minor details
Design integrity compromise
Copyright 2010 UX Design Edge
26. The art of compromise:
Obtaining something that
nobody wants but everybody
can accept
Copyright 2010 UX Design Edge
32. Getting from good UX 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 always safe to get
consensus, there’s no courage
in consensus or compromise
Copyright 2010 UX Design Edge
41. The classic excuse:
We don’t know for sure what
users want or do
Copyright 2010 UX Design Edge
42.
43. The foundation of all 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’t know 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:
If a 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 always safe to ask,
there’s no courage in asking
unnecessary questions
Copyright 2010 UX Design Edge
49. What is simplicity?
Simplicity is 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 UX Design Edge
“Everything
should be made
as simple as
possible,
but not simpler.”
Albert Einstein
51. The classic excuse:
We don’t know for sure what
users want or do
Copyright 2010 UX Design Edge
52.
53. Q: What does 0.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
made this letter
longer because I
have not the
time to make it
shorter.”
Blaise Pascal
55.
56.
57. While it’s safe to offer
everything, there’s no courage
in complexity
Copyright 2010 UX Design Edge
77. “…data eventually becomes a 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
78.
79.
80. What you do with data is the key
While good design follows
data, great design leads with it
Copyright 2010 UX Design Edge
81. How to tell the 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 offers safety, there’s
no courage in following data
Copyright 2010 UX Design Edge
85. Copyright 2010 UX Design Edge
Conway’s Law:
“Organizations are constrained
to produce designs which are
copies of the communication
structures of their
organizations.”
89. My answer:
No! Any organization that
doesn’t reward great design
will produce mediocrity
Copyright 2010 UX Design Edge
90. Attention managers:
If you have a great team
shipping mediocre products,
it’s because your culture
rewards mediocrity
Copyright 2010 UX Design Edge
91. No manager’s career or compensation
was harmed during the making of this
mediocre user experience.
Copyright 2010 UX Design Edge
92. The Innovator's Cultural Dilemma
Over time, team cultures drift
towards safety and discourage
courageous design
Copyright 2010 UX Design Edge
93.
94. “You can measure the 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 learn more?
Check my website: uxdesignedge.com
Subscribe to my blog
Register for Good UX to Great UX
Copyright 2010 UX Design Edge
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.”
Intro: Before getting started, I should say a little about who I am and what I do. <read slide>
…based in St. Albans, Vermont
I started UX Design Edge in January of this year,
but before then I used to work on the Windows team at Microsoft.
…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
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
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
User Account Control was especially embarrassing, and had all three of these problems.
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!
Intro: I’ve heard of many different ways of thinking about design before…
Last bullet: I’ve even heard of…Humane design
<advance slide>
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
<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
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
Intro: Today, I’d like to look at courageous design in <read slide>
But before continuing, I should point out that…
of course, taking risks is risky and can lead to disasters
<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:
<don’t be in a hurry>
Or of career moves that look like this:
<don’t be in a hurry>
I want you to remember the intelligent clause in my proposition.
OK, let’s talk about how *courageous design* affects consensus-based decision making
Intro: The goal of user experience design is <read slide>
Intro: Many job descriptions look like this <read slide>
<don’t advance too quickly—spend some time to absorb>
The problem is that a thing of beauty might not look quite the same
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”
<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
Intro: What is the art of compromise? It’s <read slide>
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.
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.
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
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.
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
<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.
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.
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.
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?
<read slide> Because there are just so many examples of unnecessary questions out there.
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.
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.
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.
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>
“bull!”
Intro: The foundation of all user experience design: <read slide>
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.
Intro: Here’s what I like to call the “McKay/Turing Test” for asking questions.
<read slide>
<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
Let’s talk about how *courageous design* affects simplicity
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.
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
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."
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>”
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
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
<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.
It’s actually much easier from *the design point of view* to offer everything.
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.
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
OK, let’s talk about how *courageous design* affects software personality
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!
<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
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.
Intro: <read slide>
Outro: Typically, such software is designed without any thought about its personality.
<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.
<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*.
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.
Intro: <read slide>
*Great design* requires proper social behavior.
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/
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.
<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
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…
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…
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.
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.
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.
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.
Another challenge with using data is that while data points may be valid individually, there is no guarantee that they can be combined harmoniously.
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
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.”
Finally, something needs to be said for all the extraordinary things mankind has done *with absolutely no data whatsoever*.
Intro: <read slide>
Intro: <read slide>
First approach: that’s following
Second approach: that’s leading
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.”
OK, let’s talk about team culture
I’ve saved the best for last!
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.
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
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.
<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.”
Intro: So here’s an important question: <read slide>
Answer: (Uhhhh) No! <read slide>
Outro: You ship your culture!
Every artifact an organization creates is an embodiment of its culture
Intro: <read slide>
Look no further for an explanation!
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…
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.
OK, let’s wrap up!
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.”
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