Feature Hoarders: Extreme Edition

I have an odd fascination with A&E’s Hoarders and TLC’s Hoarding: Buried Alive. It’s a sad human tragedy, where people harm themselves and their loved ones only because they collect too much stuff, let it all pile up, and refuse to throw anything away.

It’s harsh to say, but I’ve seen many apps that look like they were designed by feature hoarders—the equivalent of room after room of features and options of questionable value that have piled up over the years because nobody was willing to make the hard decisions to get rid of them.

This post explores why feature hoarding happens and what you can do about it.

Potential value

I should start by saying that I sympathize with hoarders to some degree. While I don’t get the shopping sprees (I get more delight in not buying stuff), I understand their reluctance to throw things away. When I look at something, I try to see its value and I’m reluctant to throw away things that have value.

If you watch a few episodes and listen to hoarders explain why they collect all their junk, phrases like “potential value”, “I’ll use that someday”, or “that will make a great gift” keep coming up. Emotionally, they see value even though rationally the odds of that value ever being realized are extremely slim.

Feature hoarders think about questionable features and options the same way. Even though the features aren’t necessary and rarely used, feature hoarders see the potential value and cling to the idea that one day somebody will find them useful, no matter how unlikely.

The value of simplicity and organization

While hoarders overestimate potential value, they severely overestimate actual value. They also underestimate the value of simplicity and organization. Being able to easily find and use things that you really need is far more valuable than having possession of things you don’t use.

The key to simplicity is to understand that the features and options that users will use are far more significant than those they might use. Ease of use equals use, so things that are easy to find and use have more value. Ultimately, potential value doesn’t matter much.

A bad day for user-centered design

If you were to ask a usability professional how to make a difficult design decision, there’s a good chance they’ll say “Just ask your users.” This isn’t always good advice, and these hoarder shows illustrate why. When dealing with hoarders, every day is a bad day for user-centered design.

Have you ever noticed how user centered these shows are? The hoarder is involved with every decision. In the beginning, the consultant/therapist/expert asks the hoarder item by item “Can we throw this away?” Each time, the hoarder’s answer is an emphatic “No!”, often accompanied with an “I’ll use that someday” or “I’m going to fix that” rationalization. This grinding process usually ends with shouting and tears.

The problem with user-centered decisions here is that users are good at giving their goals and setting priorities, but they are poor at making the tough, detailed decisions. If you were to ask users if they want something, the answer is almost always yes. I call these “Do you want fries with that?” questions, and as a designer you shouldn’t ask them.

A better approach would be to ask the hoarder to go through the house and point out their favorite things and the things they use the most. Then, remove everything from the home (including the hoarder), clean everything up, strategically replace and reorganize what the homeowner really needs, then evaluate the results with the homeowner.

Changing culture

Still, I appreciate what the consultants/therapists/experts are doing. Is relatively easy to clear out a house—it’s much harder to change the behavior that lead to the hoarding in the first place. If the expert doesn’t change the behavior, the improvement will be temporary at best.

Remember: the junk is there for a reason. The hoarder thought it was a good idea to buy and to keep all that junk, and without a behavior change they will do it again.

If you are trying to simplify a UI, I recommend understanding how that complexity got there in the first place. Chances are those unnecessary features and options are there on purpose, and that purpose was well intended. Somebody thought the features were a good idea at the time. Perhaps customers requested them directly. Simplicity requires saying “no”—it’s much easier to say “yes.”

Sure, you can declutter a user interface, but unless you change your team’s culture by setting a higher bar for adding features and a lower bar for removing them, that clutter will soon return.

Making the tough decisions

The top takeaway of these shows is that decluttering is much easier said than done. So, what can you do to declutter your UI? Consider using one of these techniques:

  • Gather real user data If you have the ability to gather actual usage data, you’ll have a strong case from removing unused or rarely used features. While I don’t advocate using data without interpretation, as long as there isn’t a discoverability problem, removal is usually the right interpretation.
  • Highlight your top scenarios With your team, make printouts of all your screens, perform your top tasks, and highlight what you actually use during those tasks. Take a good hard look at what didn’t get highlighted. What bad thing would happen if they were removed? With this activity, you’ve demonstrated the answer: not much.
  • Try a simplified version I’m a strong advocate of considering design alternatives. One alternative to always try is a simplified version of your current design. Instead of going through the grinding process of cutting feature by feature, just go directly to the simplified results and give it a try. I bet you’ll be surprised how nobody misses what was removed.

A devious use of iPhone design

Here’s a fun exercise to help your team simplify a UI and perhaps even change its culture. Assuming that you don’t already have one, have your team design an iPhone app. (If your app does many tasks, do this for a few top tasks.) Before starting, you might want to quickly review the iPhone guidelines, point out that there is only so much screen space, typing is a pain, and that the best iPhone apps focus on doing one task well.

Once you are done, evaluate the results by performing the top tasks. If successful, chances are your team will say things like “This is great!” and “If we had this, I don’t think I would use our original app anymore!”

Now, take a step back and compare the iPhone app to your original app. Justify the complexity of the original app. Do you really miss the features that were removed? Does the ease of use, speed, and delight of the simplified iPhone version more than make up for the missing clutter? Is there any reason why your original app can’t be more like the iPhone version?

I bet your team will have trouble justifying the complexity of your original app. The iPhone platform demands simplicity and starting from a clean iPhone slate allows your team focus on the essentials without legacy baggage.

If you do only one thing… Don’t be a feature hoarder. Focus the UI on the features and options that your users actually use, not on what they might use. Value simplicity, organization, speed, and efficiency by getting rid of what gets in the way. Get in the habit of creating simplified design alternatives and seeing if they work better. Chances are, they will!

Looking for UX design interview questions? Show candidates a complex UI and ask them to simplify. When they recommend removing features and options, challenge them by explaining why there are there and seeing if the candidate can still convince you to remove them. The ability to make a persuasive case for simplicity is a valuable design skill.


Don’t design like a programmer, part 2

In my original Don’t design like a programmer post, I explored a common UI design trap that programmers often fall into, where you have a data structure, map that directly to a UI, and expect the results to be a good user experience. Sometimes that approach works just fine, but often it does not. The original post explains the potential usability problems in detail. This is an easy trap to fall into if you are thinking about the code instead of your users. As a developer myself, I’m very sympathetic here.

Someone named pankratiev put a link to that post on Y Combinator Hacker News and my site traffic just exploded—so much that my web host couldn’t handle it. (Thanks pankratiev! Please do it again!) While the feedback and comments have been positive, the top request was to show examples of good designs too.

I will start that challenge with this post. I finish with a proposed design in Part 3.

First, the original designs

Here’s the first UI in the post:

Actually, I didn’t say this was a bad design—rather I showed how this UI is a direct mapping of this data structure:

     struct UserOptions {
          bool        Option1;
          bool        Option2;
          String      Option3:
          String      Option4:
          ...
     };

I made this example generic to focus on showing how a programmer might map a code directly to UI. Is this a good UI? Impossible to say without knowing more, but the original post gives reasons why the odds are against it.

I then ended the post with this example:

I chose this wGetGUI example because it so clearly illustrates several of the problems I mentioned in the post. For example, note that almost all the controls are text boxes, check boxes, and command buttons, which map directly to strings, integers, Booleans, and function calls. You can just see the underlying data structures that need to be filled out:

     struct RetrevalOptions {
          bool        NoClobber;
          bool        Timestamping;
          bool        ContinueFileDownload;
          int         Quota:
          ...
     };

This is the UI everyone wants me to redesign—to something that doesn’t look like it was designed by a programmer. There are some problems with this task though:

  • A good design requires applying a process, not jumping to a solution.
  • A good design requires understanding the target users and their goals, top tasks, environment, etc.
  • Unfortunately, I’m not a target user and don’t know anything about the target users and their goals, etc..

And as a courtesy to the wGetGUI developer, I really should add one more:

  • It’s presumptuous to redesign somebody else’s UI without being asked.

So for this post, I’m going to outline a process but not attempt to improve the original design. This might seem like a cop out, but it’s actually the first key takeaway:

Key takeaway #1

You can’t significantly improve a user experience if you don’t understand its target users.

Sure, I could possibly make some minor improvements to the labeling, layout, tasks flow, and control usage, but that is hardly a giant leap for design. It’s not like changing a check box to a pair of radio buttons is going to be a big revelation.

UX design CSI: Focusing on the code is backwards

At this point, I’m going to take full advantage of fact that I’m not a wGetGUI user and look at the design from a fresh perspective. If I were more familiar with the tool, it would be easier to rationalize the design.

Key takeaway #2

Target users aren’t you. They have different knowledge, goals, and preferences.

My first observation about this UI is that I haven’t a clue what to do with it. A programmer might say “Well of course not, you haven’t read the documentation. RTFM.”

Key takeaway #3

Good UIs are self explanatory. Users shouldn’t have to read a document to figure them out.

I’m wondering what the tool is for. Shouldn’t the UI explain itself? Why should I have to figure it out? (Update: I tried to deduce what the tool was for, then later RTFM. Turns out I was completely wrong!)

Key takeaway #4

Don’t make me think…Users shouldn’t have to figure things out using thought and experimentation.

Note that this UI presents settings and commands, but no obvious tasks. What are the tasks…what I am supposed to do? Am I supposed to know everything already?

Key takeaway #5

Good UIs are task centric, not feature or technology centric.

Just as the UI reveals how the programmer mapped the data structures to the UI, it also reveals the design process used. Something like:

Code -> UI

Instead, the process should look more like:

Target users -> goals -> tasks -> UI -> code

Key takeaway #6

The UI drives the code, not the other way around.

Starting with the code gets it backwards.

A process for doing it right

I’d now like to outline what the “target users -> goals -> tasks -> UI -> code” process might look like. There is any number of ways to do this, but I’ll outline a process that a programmer could actually use. No masters degree in design or UX professional staff required.

  1. Define the product. Write a short paragraph to explain what the product is for. What is its value?  How does it differ from existing solutions? Why does the world need it? Why will people care?
  2. Define the target users. Write a short paragraph to define the target users and their relevant characteristics. To avoid designing for yourself, specifically identify how they differ from you. (Hint: It’s a sure thing your target users don’t know how your code works.)
  3. Define the user goals. Write a short paragraph to explain why the target users are going to use the UI. What goals do they have? What problems are they trying to solve? What is going to satisfy them? Disappoint them?
  4. Define the top user tasks. Write a short paragraph to outline specifically what the target users are most likely going to do. Focus on the top six or so tasks—not everything that might be possible. If you have defined more than six, you’re not focusing enough.
  5. Define the user’s context. When and where are they doing these tasks? What facts do they know and data do they have? What do they not know? What other tools are they using? What other solutions are available?
  6. Explain each top task to a friend. Suppose that you are explaining each top task to a friend who is a target user. Pay attention to how you would explain it: the steps, the order, the details, the language you would use, etc. Also pay attention to the things you wouldn’t bother to explain. The way you would explain the task in person is the right way to explain the task in the UI. This explanation drives the remaining steps.
  7. Map your natural explanation into a page flow. Break that task explanation into steps, give each step a title that explains what the user is supposed to do, and list the elements required to do it. Don’t worry if you aren’t sure yet or if only one page is required. You can revisit this step as needed.
  8. Design each page. Start with the page with the title that explains its purpose (exception: skip the title only if the purpose is so obvious that the title is silly). Give the layout a natural left-to-right, top-to-bottom flow. Start the task in the upper left corner or upper center. Emphasize the elements that need emphasis, and deemphasize those that don’t. Put related elements together so that their relationship is visually obvious. Map the interaction to the simplest, most constrained controls that do the job. To simplify the page, consider displaying optional elements on demand. Make the control to complete the task or advance to next step obvious.
  9. Simplify and optimize the task flow and pages. Evaluate the design to make the operation simple and natural. Remove unnecessary effort or knowledge. Try to eliminate any frequently repeated actions. Provide reasonable default values. Take full advantage of previous user input, and avoid having users reenter information. Prevent input and other types of errors. To simplify, focus on what users will do instead of what they might do. Visually, remove unnecessary visual elements (like boxes, lines, 3D, meaningless icons.)
  10. Review the communication Now compare the design to what you did in Step 6. They should match—after all, that’s the way you would naturally explain the task in person so any discrepancies suggest problems. For example, if you mention five options in your explanation, but your UI always offers 40, you’ve got a discrepancy.
    Make sure the purpose of each page and control is clear. Sometimes adding a word or two makes a huge difference. But don’t worry: the goal isn’t to have a lot text, but rather less, better text. Iterate as necessary.
  11. Review the results. Now compare the design to what you did in Steps 1 – 5. Does it fulfill its purpose and provide value? Does it enable the target users to perform their top tasks to achieve their goals in their actual context? Any discrepancies suggest problems. Iterate as necessary.
  12. Test with real users. You’ll never be sure that you’ve got it right until you test with real users. There are many ways of doing this, but direct observation is important. People have a tendency to blame themselves for mistakes, so they might not self-report all problems. Iterate as necessary.

Done!

If you design like a programmer, you might be doing a little of Steps 7, 8, and 9 before you start writing the UI code. That’s at best—at worst you are skipping all these design steps and going directly to writing the code. If so, mapping the data structures that the code needs to directly UI will be an obvious, natural thing to do.

Isn’t this a lot of work?

Some of you might be thinking: What a pain! I’d rather just map the code to a UI and take my chances.

Sometimes that approach works just fine. But if not, you’ll later have to choose between unhappy users and lost market share vs. starting over. This above process wins long-term because you are more likely to get the UI close to right the first time. Having to start over or fix fundamental usability problems complaint by complaint, bug by bug is a much bigger pain. But you know that, right?

Want to learn more? Check out UX Design Essentials and UX Design Basics

If you would like to learn more about the process I’ve just described, please consider taking my UX Design Essentials course or my online UX Design Basics course. I’ve designed both of these courses to help non-designers get started in UX design.  I’ve only scratched the surface here.


Personas: Dead yet?

When I joined Microsoft in 2000, personas were hot. They were everywhere and Alan Cooper’s The Inmates are Running the Asylum was the most talked about UX design book. The persona posters were on all the walls. There were even persona ice cream socials.

By the time I left Microsoft in 2010, the Windows 7 team had abandoned personas. User researchers would only whisper the word in public. I met with a group forming a panel discussion called Are personas dead? As I recall, John Pruitt and I were the only ones taking the pro-persona side. Everyone else had abandoned them.

I’m still a strong believer in personas (but with a twist, as you will soon see). But what happened to make personas acceptance fall so far so fast?

Are personas necessary?

A persona is a fake person constructed with real user research data to represent a class of target users. Designing for users is, after all, the essential foundation of user-centered design, so it makes sense to have a tool to help teams define their targets. You can’t hit a target if you don’t have one.

The problem that personas solve is that without clear targets, everyone on the team forms their own independent picture of the target user. And somehow, those target users always seem remarkably similar to the people on the team itself…or perhaps their mothers. Furthermore, that target user may change from feature to feature, or even from discussion to discussion. Ultimately, without a clear definition, target users are basically whatever the person speaking wants them to be at the time. Not a very solid foundation.

This problem is known as the elastic user. Personas are a tool to define and communicate a clear, fixed target user—building a strong foundation for user centered design.

So, what’s not to like?

In practice, personas didn’t achieve that goal. User researchers would spend a significant amount of time gathering data about target users, defining personas to represent them, and crafting detailed persona documents.

Design teams would then use those personas by learning the persona names, their high level descriptions, and…well, that’s about it. So for Windows Vista, Abby was the soccer mom and she had a teenage son named Toby. Few people knew much more. Instead of having discussions about generic users, design teams would discuss what Abby and Toby wanted, but without regard to any facts in those detailed documents that the user researchers so diligently compiled.

In practice, “using personas” often boiled down to replacing an elastic user with an equally elastic user with a very specific first name. Instead, personas should have been about creating user models for a decision making framework using a well understood process. Mindlessly substituting “the user” with “Abby” wasn’t really a big step forward in user-centered design.

Doing personas right—don’t walk a mile in the user’s shoes

User researchers compiled these detailed persona documents because that’s what Alan Cooper recommended in The Inmates are Running the Asylum. The goal was to make the personas feel real—so that you could walk a mile in their shoes.

An unfortunate fact of life: People don’t read large documents. So nobody really knew any facts about the personas. And even if they did, relevant facts for specific decisions were often missing. For example, if you were designing a search feature, chances are the long persona document would provide no useful information about the user’s knowledge, habits, or preferences about search.

Instead of creating a long personal life story, why not create a short user model that focuses only on the details that affect design decisions at hand? Better to have a few relevant facts that everybody knows.

An example

In Design scenarios—and how thrilled users ruin them, I gave a scenario for Joe “the shipping guy,” who needs to access Snarfbladt info using a BladtBlaster device. Let’s make a persona for Joe.

To help you see the value of personas, please read the scenario (the good example at the end, not the bad one) before continuing, and put some thought into designing a solution.

Got it?

Now a traditional persona might be several pages long and give all kinds of personal and professional details about Joe. Much of that detail will be completely irrelevant to the design problem at hand—what I like to call the “four Ks”: details like koffee, kids, kats, and kars. Frankly my dear, I don’t give a damn.

I believe the long story of largely irrelevant details is what ruins traditional personas. So instead, let’s get right to the point with facts about Joe that are relevant to the scenario:

  • Has basic computer literacy
  • Likely right handed, but may be left handed
  • Received 20 minutes of BladtBlaster training
  • Top 6 tasks are 95% of his BladtBlaster usage
  • Familiar with Snarfbladt info, but doesn’t have it memorized
  • Looks up only one Snarfbladt at a time
  • Uses are cart if delivering many packages, o/w carries them
  • Prefers to use the BladtBlaster with a single hand using thumb
  • Works mostly indoors, but has to travel outdoors between buildings, so may wear gloves during cold weather
  • Always in a hurry—appreciates things that save time

That’s it! That’s all we need! This user model contains facts about Joe and his relationship to the product that are relevant to making design decisions. No life story here. No mile in Joe’s shoes.

I don’t know about you, but I now have a much better understanding of Joe and can make better design decisions for Joe, more quickly and confidently. For example, I know that a good design can optimize for right-handed users, but not in a way that harms left-handed users. To simplify the UI, I know that a good design will focus on doing the top 6 tasks efficiently, in a way that doesn’t require memorization. I know that a good design should have buttons large enough for use with a gloved thumb. And since Joe has basic computer literacy, the UI can have basic computer terms (like save or network), but should avoid advanced ones (like virtual or IP address).

Given several different design alternatives, I now know what Joe is going to want. By documenting this persona, everyone on the team will be designing for the same target. If someone makes an assertion about Joe that’s not in the model, we can easily flag it and either validate it or reject it.

The elastic user problem is solved!

If you do only five things:
1) Keep it simple and focused. Focus the persona on the design task at hand, not the target user’s entire life story. See what you can do with one page and at most two hours, using the facts that you already know. Anything beyond that is detail you won’t need anyway.
2) Make a user model, not a life story. Just give that specific facts to help make good decisions. If there’s not a potential design decision behind the detail, don’t include it. Don’t walk a mile in the person’s shoes. If your persona looks like an online dating profile, you are doing it wrong.
3) Use them when making decisions! If you aren’t actively using your models when making design decisions, you’re doing it wrong. And by “actively using”, I mean applying the model not making arbitrary assertions. Flag assertions that are outside the model and validate them.
4) Train your team to use a simple process. Give some simple training on how to use personas productively. Don’t assume that people will figure it out on their own—my experience shows that they won’t.
5) Be mindful of politics. If you can’t use personas for political reasons, just call them user models. If it helps, consider calling them “agile user models.” Most likely nobody will catch on.

Coda: It is not my intention to downplay the role of user research in this process. If your team has user researchers, of course they will own and drive this effort, using a far more substantial process than I describe here. Still, experienced user researchers will vouch for the importance of concise communication for their effectiveness within a team. Ease of use equals use, and that applies to design techniques. So keep your personas simple and focused.


The Dog and Its Reflection: My initial impression of Windows 8

Previews of Windows 8 are starting to trickle out, with Jensen Harris’ Building Windows 8 Video #1 and Ina Fried’s Making Sense of Our First Look at Windows 8. From what I’ve seen, my initial impression is that Windows 8 looks fresh, innovative, snappy, and has strong potential. It may even be delightful!

A great, freshing start!

The Windows 8 team has demonstrated much needed courageous design and creativity here. But as I mentioned in Everybody loves creativity, creative ideas often have problems—lots of them. I see several interesting challenges with Windows 8 that I’d like to share.

Serious iPad envy

The Windows 8 team clearly has some serious iPad envy. As they should. It would be a mistake to ignore the iPad/tablet phenomenon—to do otherwise risks losing relevance to an ever increasing part of the market. In fact, just yesterday I offered to upgrade my wife’s ancient Windows XP PC. She told me not to bother—just give her an iPad instead. What could Windows 8 offer to get her to change her mind?

Shooting in the middle…and missing?

Well, it could possibly change her mind by offering a better tablet experience than the iPad. But then Microsoft risks losing me. For me, Windows is for running traditional desktop and web software using a keyboard and mouse. I use Windows on a laptop for my business, so to get me to upgrade from Windows 7 would require a better, more productive traditional PC experience. For messing around at home, I’ve got an Apple iPad 2 and I’m not going to change that any time soon regardless.

So is Windows 8 a traditional PC OS for business, or a mobile/tablet OS for home? From Julie Larson-Green’s press release, Microsoft very much wants it to be both:

And this isn’t just about touch PCs. The new Windows experience will ultimately be powered by application and device developers around the world — one experience across a tremendous variety of PCs. The user interface and new apps will work with or without a keyboard and mouse on a broad range of screen sizes and pixel densities, from small slates to laptops, desktops, all-in-ones, and even classroom-sized displays. Hundreds of millions of PCs will run the new Windows 8 user interface. This breadth of hardware choice is unique to Windows and central to how we see Windows evolving.

And in Ina Fried’s article, Steven Sinofsky stated “It’s ‘no compromise’ and that’s really important to us.” Hmm…compromises and tradeoffs exist for a reason: it’s just not possible to do all things equally well for everything. You literally can’t aim at two independent targets with a single bullet. If you aim in the middle, you will certainly end up missing both. I sense a product planning Archilles’ heel here. Daring Fireball has drawn the same conclusion. It will be interesting to see how this plays out.

While watching Jensen’s video, I kept thinking “OK, but is that really something I want for my business computer?” and “Are these goals and scenarios that I really have at work?” Not really…at least not yet.

The finger that launched a thousand apps…but would I actually do this?

Scenario-based design in today’s connected world

A scenario describes a specific target user trying to achieve a specific goal or task in a specific environment. Many people underemphasize the user’s environment in their scenarios, but that’s a big mistake. It turns out that really understanding the environment is often what makes a great design.

So what is in today’s tech savvy computer user’s environment (that is, those who are likely to buy a new Windows 8 PC or tablet)? Probably an iPhone or Android smartphone, an iPad, or both, right? A scenario that makes sense if the user has only a Windows 8 computing device might not make nearly as much sense with a fully charged iPhone or an iPad nearby. So, for example, using Urban Spoon to decide where to go for lunch is a smartphone scenario for convenience, speed, and mobility, even if other solutions provide a richer, more powerful solution. This type of scenario is one that Windows 8 simply can’t win.

Assume that I’ve got four devices on my desk (Windows PC, Windows tablet, iPad, iPhone). Give me strong reasons to reach for the Windows 8 devices instead of the others. The difference between “can” and “want” is huge. Make me want it! “Want” is the ultimate manifestation of value—“can” just gets you in the door.

While watching Jensen’s video, I kept thinking “OK, how many of these Windows 8 scenarios fall down if I’ve got easy access to other devices?” I wasn’t liking my answers. Smartphones win a lot of these scenarios. The simplicity of the iPad wins many others. There’s nothing here to make me want to switch.

Authentic or WinFrankenPad?

Windows Vista introduced the Aero UI, where Aero is a backronym for authentic, energetic, reflective, and open. (Which, BTW, nobody really understood. Reflective? Open? Huh?) I have come to appreciate the value in being authentic though, sometimes with design decisions but more often with teams attempting to adapt design cultures alien to their own.

While watching Jensen’s video, I kept thinking “This new UI doesn’t feel authentic to Windows. It feels like a completely different environment that was stapled on.” To feel authentic, the new experience needs to sit alongside the old harmoniously. It should feel like it’s there because it belongs there, not because somebody had a stapler.

Here’s the staple.

BTW: Is it me, or does this page lack focus and flow? My eye has no idea where to go.

The wow starts…eventually

Demoware can be a dangerous thing because it gives everyone unrealistic expectations. I was on the Windows Vista team and the Vista demos were awesome. Snappy, action packed, …look at all the things you can do—so quickly! My real Windows Vista experience on real hardware was dog slow to the extent that the “spinning donut” would have made an appropriate product logo. It’s poor performance was a real buzz kill.

While watching Jensen’s video, I noticed that the Windows 8 performance was consistently fantastic. That’s not the Windows I know—I’ve never been impressed by Windows’ performance. I suspect demoware, especially this far ahead of shipping. But this is as it should be…there’s no point in demoing a sluggish UI.

But if Windows 8 doesn’t have fantastic performance on real hardware, nothing else matters. Doubly true for a tablet. Windows should wait for users, not the other way around. No matter how cool these new features might be, they aren’t going to be worth waiting for. I hope the Windows team recognizes this. It would be impossible to overinvest in improving performance, as performance is the currency with which modern user experiences are purchased.

Business productivity

I’m a big believer in using personas, and one of my favorite personas is the purchase decision maker. (BTW: The Windows team banned the use of personas starting with Windows 7.) Build a persona for the person who is going to decide to buy a product, and do what can you can to make that decision as easy and comfortable as possible. You need to explicitly design for that persona! For business decision makers, a realistic story for reducing costs and making employees more productive is effective strategy.

While watching Jensen’s video, I kept thinking “Why would a business buy this for its employees?” I didn’t see any answers. Launching apps from a tile-based Start screen is, ironically, a non-starter (just as Flip 3D was for Vista). In fact, all those live tiles demanding users’ attention looks quite distracting (I don’t want apps sending tweets to my employees), as does shifting between desktops. Hopefully, Jensen will address the business case in Building Windows 8 Video #2.

Ecosystem

Windows was originally successful because of its vibrant community of third-party developers creating Windows apps. The AppStore phenomenon is doing the same thing for the iPhone and iPad today.

While watching Jensen’s video, I kept thinking “Where are all these apps coming from? Third parties?” While Windows’ huge market share makes it attractive for third-party developers, success is far from certain. The lukewarm development of Windows Sidebar Gadgets demonstrates that.

What’s in Windows 8 for traditional Windows developers like Adobe? Why would an ISV create a native Windows 8 app over an html5 app? Hopefully that topic will be addressed by Video #3. If Office is the only major player, somebody is in trouble.

The Dog and Its Reflection

Windows owns the traditional desktop market, but it very much wants to be the touch-based tablet contender. This quandary reminds me of Aesop’s Fable of The Dog and Its Reflection:

A dog that is carrying a piece of meat looks down as it is crossing a stream and sees its own reflection in the water. Taking it for another dog carrying something better, it opens its mouth to bark at the “other” and in doing so drops what it was carrying.

While I see challenges for Windows 8, I believe the Windows 8 team is doing the right thing—they must respond to the iPad. The only question is whether grafting in new environment onto a legacy desktop OS is the best vehicle to do it. To that, I’m not so sure. Success here will require execution that Microsoft hasn’t demonstrated for quite a while.

I wish them every success. Vigorous competition benefits everyone, so the world will be a better place if Windows 8 is extremely successful.

Update: I had a chance to try a Windows 8 tablet recently. It’s performance is snappy and the metro UI has potential for being delightful. Still, I’m at a complete loss as to why any desktop or laptop user would want the Windows 8 Start Menu. The purpose of the Start Menu is to launch less frequently used programs quickly—nothing more. If Windows 8 offered an option to use the classic Start Menu instead, I’m sure I would choose that option immediately.


Designing for Trust and Confidence online course

I’m creating a new online course called Designing for Trust and Confidence and I’m looking for a small group of people who would like to help out.

Designing for trust and confidence is an interesting topic that goes beyond ordinary usability. The idea is that trust and confidence are critical ingredients to certain tasks that we often overlook. For an example from an everyday social interaction, consider asking for directions. While getting directions, you are also evaluating the trustworthiness of the person giving them. If the person doesn’t earn your trust, you won’t follow their directions regardless of how clear and easy they are to follow. For another example involving a CO detector, check TUX or SUX. If a task requires the user’s trust and that trust has not been earned, usability doesn’t matter.

I’m looking for people who are interested in the subject and are willing to review course material and give feedback on ideas. Your compensation will be what you learn from the experience, a free pass to the finished course, and my eternal gratitude.

If you are interested, please contact me. Please tell me a bit about your background and why you are interested in participating. Thank you!


For more information, please contact info@uxdesignedge.com

All Content Copyright © UX Design Edge