I recently presented UX Design Essentials for Managers to a group of executives. Everyone there had an iPad and loved it. Most said that they were using their iPads for routine tasks now, and rarely needed their laptops anymore. Their top question for me: Why didn’t Microsoft invent the iPad?
It’s a very reasonable question to ask, and the answer is extremely relevant to the course. After all, Microsoft had a huge head start, with an early lead in tablets and touch. Windows XP, Tablet PC Edition was released in 2002, Windows Vista had pen support built in by 2007, and Windows 7 had touch support built in by 2009. And Windows has a huge market share advantage to help get traction.
By contrast, after the failed Newton, Apple showed very little interest in tablets. My friend Bert Keeley, a tablet and touch expert, approached Apple about creating a tablet but was rebuffed by Steve Jobs, who said “We won’t do those.” When Apple finally shipped the iPad in April 2010, it was extremely late to the party.
Fashionably late, it appears, as the iPad has driven Microsoft’s tablet efforts into oblivion. And it took all of a week on the market to do so.
Dick Brass is a former Microsoft VP who led their tablet and e-book efforts. After the iPad was released, he wrote the New York Times article Microsoft’s Creative Destruction, where Mr. Brass explains how Microsoft’s “dysfunctional corporate culture” squandered its early lead. He tells a tale of technology backstabbing and sabotage remarkably similar to the plot of Mean Girls.
But is this really the reason why Microsoft didn’t invent the iPad? Here’s an interesting thought experiment: suppose Microsoft executives were a little less adept at backstabbing and sabotage, and gave their full support to Mr. Brass. Would Microsoft-based tablets have been as successful as the iPad?
My answer: No.
Many people believe that UX design is problem solving and Microsoft definitely falls into that camp. Here’s a problem solving approach to designing a Microsoft tablet:
(BTW: What’s up with “pain points”? Many people talk about these—as if not being painful is a good user experience design aspiration.)
If the iPad didn’t exist, this might seem like a reasonable plan—especially to a Microsoft VP. Exploit the Windows market share, get something out there quickly that runs Office, and see what happens.
But in the context of the iPad, there are three glaring flaws with this approach:
Having tablet technology doesn’t matter. Running Windows and Office doesn’t matter. Having a delightful, hassle free experience does. That is why the iPad is successful.
Apple gets this, but Microsoft doesn’t (Mr. Brass included).
The iPad is unique among consumer electronics devices. The iPad is something everybody wants, but nobody needs. There is nothing you can do with an iPad that you can’t do with a laptop or a smartphone.
This is not a slight. After all, nobody needs a Ferrari either. Rather, it sets an extremely high bar for UX design. There is no clear need to fill—beyond customer delight. Without a clear need, if the results aren’t delightful, what’s the point?
Microsoft can create delightful products—but only after it has exhausted all other possibilities. The much-maligned Zune is an interesting example. While the initial release was weak, the Zune desktop software was delightful and made iTunes look like a spreadsheet. But by the time Microsoft got it right, it was well beyond the point where anybody cared.
The “three tries to get it right” approach worked just fine in the Windows and Office era, but doesn’t work anymore when your competitors are hitting grand slams every time at bat.
OK, enough about Microsoft’s problems…what does this mean to you? Here are the key takeaways:
Attention managers: Do you need help improving your team’s design culture? Please consider hosting UX Design Essentials for Managers for your management team. This class will help your team identify and work through its design culture challenges (having a neutral outsider drive really helps), plus help boost their UX design skills.
Here’s a synopsis:
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.”
Here’s a rerecording of the Keynote:
Here’s a link to the Courageous Design slide deck.
While I felt good about the Keynote and received a lot of generous, supportive feedback afterward, I felt great about it after seeing Casey McKinnon’s Building a User-Centric Company because it could have easily been retitled “FreshBooks: Why everything Everett just said really does work.” Loved it! If you didn’t see Casey’s presentation, I strongly recommend taking a look.
I’m definitely interested in giving this presentations (or variations) at companies and other conferences. If you are interested, please contact me.
When I was creating my Good UX to Great UX course (subtitled Ten practical ways to take your product’s experience to the next level), I was surprised to discovered that innovation didn’t make the list. It didn’t make the top 12 list either. Perhaps if I had gone to 15 ways… *
My explanation is that a great user experiences and an innovative user experiences are orthogonal concepts. Sure, an innovative UX can be great, but it can just as easily be lousy. A design isn’t inherently superior just because it’s innovative. The definitions help explain why.
A great user experience must go beyond the ordinary. It’s about love and delight, not about satisfaction or acceptability.
What’s remarkable about my omission is that we talk about innovation so much that you’d swear it was an absolute requirement. World-class industrial designer Dieter Rams seems to think so, as innovation made the top of his Ten principles for a good design. Apparently Steve Ballmer agrees.
Somebody is wrong here and I don’t think it’s me. It could be that leaders like to talk about innovation because it sounds impressive and inspirational. Innovation is a design management MacGuffin—it drives the plot but is otherwise unimportant. Perhaps they use innovation as a code word to mean something less impressive sounding such as good design (just as people often say intuitive to mean consistent or simple.)
But for the sake of argument, let’s assume that people really mean what they say. What could possibly be wrong with innovation?
Don’t get me wrong, I love great, innovative products as much as the next guy. I get extreme pleasure from their ingenuity of their design and the naturalness of their mechanics. Zero turn mowers—amazing! A multi-touch mouse—brilliant! Suspension packaging—pure genius!
But notice that I said great and innovative. At best, innovation is a supplement to greatness, not a substitute. To think otherwise makes you vulnerable to mediocrity. On their own, great ultimately beats new every time.
Not all innovation is good. Shocking to say, but it’s true.
Unwise innovation can lead to complexity, inconsistency, confusion, unintended consequences, and even danger. One way to do something is good, two ways might be OK, but five can be a mess. It’s fortunate that the basic operation of a car hasn’t changed much since its invention. Imagine the turmoil if the accelerator and brake pedals weren’t consistent across makes and models. As for unintended consequences, we learned from the housing bubble that financial and innovation should rarely be used in the same sentence.
While at Microsoft, I saw the Windows 7 team deal with downside of years of innovation on the Windows desktop. Over time, each element of the Windows desktop evolved to provide yet another way to launch programs, access commands, and show status. Consequently, each element had a mishmash of features, commands, and status instead of a clear, distinct specialty. The Windows 7 desktop was redesigned to address this. The purpose of each feature was sharpened and any excess baggage (such as the Quick launch bar) was removed.
Great innovation needs a high bar for quality and a strong motivation. We innovate best when we must, not because we can. Innovations need to solve actual problems, not just do things differently. And to handle the scale problem, introducing a new way to do something suggests that you should retire some old ways too.
Fact is, innovation for the sake of innovation isn’t all that hard. Here’s a few chapters from Product Innovation for Dummies:
These are actually pretty easy to do. What’s much more challenging is to adapt a solution that’s been used a thousand times before and somehow doing it better than anybody else. That’s really hard to do.
Turkey and gravy flavored ice cream might be innovative but difficult only in the technical sense. By contrast, creating the world’s best vanilla would be a remarkable achievement.
Surely Apple is an innovative company, right? For starters, they’ve invented many successful product categories, such as:
Actually, Apple didn’t invent any of those. But what they are really good at is innovating great features, such as:
OK, so they didn’t invent any of those either. But nobody can say that Apple doesn’t have great, innovative industrial design. Perhaps not.
I’m not trying to take anything away from Apple—they do design great, innovative products that their customers love. My points are simply:
Now, you might be thinking: OK, perhaps Apple isn’t the first in many areas, but that’s not what matters. Rather, they are often the first to really nail a design, and that’s what matters most.
My point exactly!
If you do only one thing:
Remember that innovation for its own sake is a distraction that does not guarantee success. Better to nail the basics instead and innovate as required to do so. Innovate because you must, not because you can!
Give two teams—one focused on innovation, the other focused on great design, my bet is that is that the team focused on great design will win. And ironically, customers will perceive them to be the innovator.
* Perfection also didn’t make the list. People often give the impracticality of achieving perfection as the reason for not pursuing great experiences, but I think that’s just a cop out. Greatness is about being extraordinary, not about being perfect. Any product has practical potential for greatness.
Joe works at a Fortune 500 company. On occasion, he needs to access Snarfbladt info for his customers. He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Joe is thrilled.
What’s wrong with this scenario? In short, everything. It’s not really a design scenario but a thinly veiled feature advertisement. Its only purpose is for the feature owner to say “somewhere out there is a customer who needs Snarfbladt info, so please don’t cut my feature.” Beyond that, it accomplishes nothing.
Unfortunately, most scenarios I’ve seen in practice follow this basic template.
New! To learn more, join our first virtual UX design class on scenarios on September 10, 2015. For more information and to register, check Effective Scenarios.
To better understand the problems with this scenario, let’s quickly review the history of scenario-based design. In the early days of the software business, there was very little software with very little capability, so there was a feature arms race. Feature-based design boils down to creating products with long feature lists and the product with the longest list wins.
The problem with this approach is that user don’t do features, they do tasks. So while having a long list of features might initially appear impressive, having many complex, poorly coordinated features doesn’t help users get their work done. As an alternative, task-based design is all about helping users get their work done, with efficient, well designed end-to-end tasks.
Task-based design sounds pretty good, so what’s the problem? The problem is that great user experiences are designed for their target users and task-based design doesn’t consider target users at all. Add the tendency for people to design for themselves, and task-based design often leads to designs that developers love but customers hate.
Great design requires designing for a clear target. Enter scenario-based design. What’s a scenario?
A scenario describes a specific target user trying to achieve a specific goal or task in a specific context or environment.
Or more concisely:
Scenario = user + task + environment
So, the difference between scenario- and task-based design is the focus on users and their environment. Good designs are useful, but great designs are usable and desirable by providing what users need. Design scenarios are about excellence, not acceptability. You can get to acceptable through good task design.
Best of all, a solid set of scenarios creates a decision making framework. Brainstorming? Review your scenarios to give you inspiration. Choosing between two alternatives? Use the scenarios to help you decide. If you aren’t constantly referring to your scenarios throughout the design process, you’re doing it wrong.
What’s wrong with the original scenario? Let’s analyze each sentence:
Joe works at a Fortune 500 company. A meaningless attempt at providing a description of the user and environment. This tells you nothing about Joe—he could be anybody doing anything anywhere. Not a clear target.
On occasion, he needs to access Snarfbladt info for his customers. At least we have a goal/task.
He discovered that the BladtBlaster 2000 allows him to request access to Snarfbladts from the BladtBlaster website. Here’s the advertisement that suggests why Joe wants the feature. But there’s a first degree scenario-writing crime here: the scenario provides the solution. Who says Joe wants to request access from the BladtBlaster website? Aren’t there other possible solutions? By putting the solution in the scenario, no other solution is possible. (Unless, of course, you ignore the scenario.)
Joe is thrilled. Another first degree scenario-writing crime. See why below.
It might seem like a small detail, but ending a scenario with a thrilled user completely undermines the scenario. Why? Consider Everett’s Rule of Scenario-Based Design:
If success is shipping a feature, you aren’t doing scenario-based design! Rather, you’re doing feature-based design.
Instead of using scenario-based design to figure out how to thrill Joe, we have guaranteed “success” by simply shipping the feature.
But who says Joe is really thrilled? What specifically about the design is going to thrill him? That information should be in the scenario, but it’s not. By adding those three little words, we’ve devolved all the way back to feature-based design. We’re now doing scenario-based design in name only.
Joe works in the shipping department of a large company, where he is responsible for the pickup and delivery of about 200 packages a day across 10 buildings. To maintain his aggressive schedule, he is always on the move, either with a cart or carrying a few packages underarm.
Between deliveries, Joe occasionally needs to access Snarfbladt info for his customers. The BladtBlaster 2000 allows him to access the Snarfbladts info instantly. Best of all, he can do it while walking, using a single hand with only three thumb strokes or less.
While the new scenario doesn’t have a specific solution or tell us that Joe is thrilled, we now have a pretty clear picture to help us visualize what might thrill him (as well as what might frustrate him.) It’s now up to us to design a solution that nails this scenario for Joe.
If you do only one thing:
Write scenarios that can be used as a decision-making framework. Provide details about users, goals, tasks, and environment. Don’t provide a solution because figuring out the best solution is the entire point of the scenario. And don’t declare that the user is thrilled because a feature exists. Provide the details for what it would take to thrill the user instead.
Congratulations! By reading this post, you have mastered about one hundredth of what you would learn by taking User Experience Design Essentials. What to learn more? Sign up now!
Know your users, design for your users… right?
Living near the Canadian border, I’ve long had access to Canadian broadcasting and greatly prefer their coverage over ours. Apparently, I’m not the only one. I took a short winter vacation at Stowe, VT and of the Olympic coverage that I saw displayed in public, the score was CTV 6, USA 1, NBC 0. Not one set showed NBC!
Before the games, I had two predictions about NBC’s coverage. First, I expected to see a lot of Michael Phelps as a cheap ratings ploy (sorry guys, wrong Olympics!) Second, I expected to not see any significant coverage for events that 1) are unpopular with Americans, 2) didn’t have any American medal contenders, and 3) don’t immediately appear exciting or dangerous. In other words, no cross-country skiing and for sure no curling. I nailed the first prediction but was pleasantly surprised to see NBC cover entire cross-country skiing events that had no American contenders. (Didn’t see any curling though).
As a user centered design challenge, this presents an interesting question: what’s wrong with giving people what they want? If most viewers aren’t interested in cross-country skiing, wouldn’t user centered design suggest that NBC would be right to not include it? (Let’s assume for a moment that user centered design is what NBC tried to do, as opposed to, say, maximizing advertising revenue.) NBC does extensive viewer research and their programming choices reflect their data, so we should love the results based on our own input. Why then did so many people prefer CTV’s coverage?
The answer, I believe, is that giving people what they ask for can lead to good design, but it doesn’t guarantee great design. You can be good by following your users, but to be great, you have to lead them. In short, great design often requires courage.
Following your users is safe design. It requires research, analysis, and process, but little more. By contrast, courageous design is risky. It 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.” This is hard to do well because you have to discover desires that people don’t even know that they have. And if you fail, you fail big. You might be leading your customers to some new, exciting place…or maybe somewhere they have no desire to go.
Why is this important? Well, nobody asked Apple for an iPhone. Nobody asked for Facebook. For sure nobody asked for Twitter. Revolutionary innovation requires courage. You can’t lead by following.
If you do only one thing: Do the best user research you can, but be willing to see beyond the data.