Archive for the ‘Getting from good UX to great UX’ Category

You ship your culture: Why Microsoft didn’t invent the iPad

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?

Good question!

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 got it wrong

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.

Microsoft is a technology company, but the iPad success required an experience company

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:

  • Define problem Create a tablet-based OS that works with the most popular apps.
  • Find a solution Identify the top usability problems (often called “pain points”) with using Windows on a tablet, develop technologies to work around them, and ship a version of Windows with those technologies.
  • Evaluate Determine if users can browse the web and use Office reasonably well. If so, problem solved. Ship it!
  • Improve Continually improve the product and Office integration over time based on customer feedback.

(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:

  • The iPad is a success because it’s delightful. The iPad is optimized for the top tasks that don’t require a keyboard. The software is simple, easy to use, and responsive…you don’t have to futz around to use it. The multi-touch support is responsive and intuitive. The device itself is light, feels great in your hands, has fantastic battery life, and is a perfect gaming device. Overall, it’s fun, fast, and hassle free. Merely being functional or having a reduced set of “pain points” is a non-starter.
  • Running Office is the least interesting thing you can do with a tablet. Note how getting support from Office was a crucial part of Mr. Brass’s story. But aside from simple email, Office-type tasks are too cumbersome for a tablet. The iPad’s simple, hassle free operation is optimized for browsing the web, reading books, playing games, watching videos, and having fun. That is, everything other than using Office.
  • People aren’t going to wait around for you to get it right. More on this later…

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).

Something everybody wants, but nobody needs

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?

Getting it right the first time

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.

Lessons learned

OK, enough about Microsoft’s problems…what does this mean to you? Here are the key takeaways:

  • You ship your culture The products your team creates are a reflection of its culture. Your team’s vision, plus it goals, team members, reward system, and decision making process are all a reflection of its culture. If that culture doesn’t value great user experiences, your products won’t have them. That’s that simple. A dysfunctional design culture is an executive problem—it’s not a problem non-exec employees can possibly fix.
  • Top players are getting right the first time now The “three times to get it right” approach doesn’t work anymore. If you don’t create a great user experience, your competitors will do it for you. Don’t expect your customers to wait around.
  • Experiences matter; features, technology and “innovation” don’t. Innovation is a meaningless word. Nobody cares. People do care about features and technology, but only as a means to an end. Great experiences do matter—people want to be delighted by the products they buy and use.

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.



Courageous Design

On November 6, 2010, I gave the Keynote at Design Camp Boston/New England UX entitled Courageous Design: Why great design requires intelligent risks.

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.



Innovation: Overrated

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 design is innovative when it is new. Whether the novelty is revolutionary or evolutionary, a novel design has a form or function that hasn’t been done before.
  • By contrast, a design is great when it fulfills its purpose extraordinarily well—whether through its value, capability, appearance, elegance, simplicity, or refinement. It has to go beyond being functional and easy to use—that just gets a design to good.

A great user experience must go beyond the ordinary. It’s about love and delight, not about satisfaction or acceptability.

The software industry is obsessed with innovation

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?

Innovation is great, sometimes

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.

Change is bad unless it’s great

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.

Innovating is easy—excellence is hard

Fact is, innovation for the sake of innovation isn’t all that hard. Here’s a few chapters from Product Innovation for Dummies:

  • Find a product with problem, find a suitable solution from some other domain, apply it. Done!
  • Find a product that requires a tool to operate and redesign to eliminate the tool. Done!
  • Find a product that is large and redesign it into a smaller form factor. Done!

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.

Is Apple innovative?

Surely Apple is an innovative company, right? For starters, they’ve invented many successful product categories, such as:

  • Low-cost personal computers
  • Easy-to-use graphical user interfaces
  • Portable computers
  • Portable music players
  • App-based smart phones
  • Tablet computers

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.

Apple fan boys, relax!

I’m not trying to take anything away from Apple—they do design great, innovative products that their customers love. My points are simply:

  • Applying the definition of innovation, Apple isn’t as innovative as you might think. Rather, Apple’s true expertise lies in perfecting the innovations of others.
  • Ultimately, it doesn’t matter. If customers love your products, they’ll consider your products innovative regardless. First UX not to suck gets full innovator credit!
  • If your customers aren’t thrilled, being innovative won’t save you.

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.



Design scenarios—and how thrilled users ruin them

Scenario-based design is the best tool we have for designing great products that our customers will love, yet all too often I see scenarios that are completely useless. Like this one:

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.

Feature- and task-based design

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.

Scenario-based design

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.

Scenario analysis

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.

What’s wrong with having a thrilled user?

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.

Let’s try again

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!



NBC Olympic Coverage and Courageous Design

Know your users, design for your users… right?

I loved the 2010 Olympic Winter Games. Vancouver did a fantastic job. CTV did a fantastic job too. And NBC? Well, let’s say they did OK.

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.



For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge