CHAPTER 12: The Process of Designing a Product – User Interface Design for Programmers

The Process
of Designing
a Product

We've talked about the principles of good design, but principles only give you a way to evaluate and improve an existing design. So how do you figure out what the design should be in the first place? Many people write big, functional outlines of all the features they have thought up. Then they design each one and hang it off of a menu item (or Web page). When they're done, the program (or Web site) has all the functionality they wanted, but it doesn't flow right. People sit down and they don't know what it does, and they don't know how to use it to accomplish what they want.

Microsoft's solution to this is something called Activity-Based Planning. (As far as I can tell, this concept was introduced to Microsoft by Mike Conte on the Excel team, who got bored with that and went on to a second career as a race car driver). The key insight is to figure out the activity that the user is doing and then make it easy to accomplish that activity. This is best illustrated with an example.

You've decided to make a Web site that lets people create greeting cards. Using a somewhat naïve approach, you might come up with the following list of features:

  1. Add text to card.
  2. Add picture to card.
  3. Get predesigned card from library.
  4. Send card:
    1. Using email
    2. By printing it out

For lack of any better way of thinking about the problem, this might lead itself to a typical Macintosh user interface circa-1985: a program that starts out with a blank card and includes menu items for adding text and pictures, for loading cards from a library, and for sending cards. The user is going to have to browse through the menus trying to figure out what commands are available and then figure out how to put these atomic commands together to create a card.

Activity-based planning is different. Activity-based planning says that you need to come up with a list of activities that users might do. So, you talk to your potential users and come up with this "Top Three" list:

  1. Birthday Greeting
  2. Party Invitation
  3. Anniversary Greeting

Now, instead of thinking about your program like a programmer (in terms of, which features do you need to provide in order to make a card), you're thinking about it like the user, in terms of what activities the user is doing, specifically:

  1. Sending a birthday card
  2. Planning a party, and inviting people to it
  3. Sending an anniversary card

Suddenly, all kinds of ideas will rush into your head. Instead of starting with a blank card, you might start with a menu like this:

Users will suddenly find it much easier to get started with your program without having to browse through the menus since the program will virtually lead them through the steps to complete the activity. (There is a risk that if you don't pick the activities correctly, you will alienate or confuse users who might have been able to use your program to, say, send a Hanukkah card but don't see that as a choice. So be careful in picking activities that blanket the majority of the market you want to target.)

Just looking at our list of three activities suggests some great features that you might want to add. For example, if the user is sending a birthday or anniversary card, they might want to be reminded next year to send a card to the same you might add a checkbox that says "remind me next year." And a party invitation needs a way to RSVP, so you might add a feature that lets them collect RSVPs from people electronically. Both of these feature ideas came from looking at the activity that users were performing instead of the features in the application.

This example is trivial; for any serious application, the rewards of activity-based planning are even greater. When you're designing a program from scratch, you already have a vision of what activities your users are going to be doing. Figuring out this vision is not hard at all, it takes almost no effort to brainstorm with your colleagues, write down a list of potential activities, and then decide which ones you want to focus on. The simple act of listing these activities on paper will help your overall design enormously.

Activity-based planning is even more important when you are working on version 2 of a product that people are already using. Here, it may be a matter of observing some of your existing customers to see what they are using your program to accomplish.

In the early days of Excel, up to about version 4.0, most people at Microsoft thought that the most common user activity was doing financial "what-if" scenarios, such as changing the inflation rate to see how it affects profitability.

When we were designing Excel 5.0, the first major release to use serious activity-based planning, we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn't even considered this before. Keeping lists turned out to be far more popular than any other activity with Excel. And this led us to invent a whole slew of features that make it easier to keep lists: easier sorting; automatic data entry; the AutoFilter feature, which helps you see a slice of your list; and multi-user features, which let several people work on the same list at the same time while Excel automatically reconciles everything.

While Excel 5.0 was being designed, Lotus had shipped a "new paradigm" spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it. For various strange reasons, Improv was first available on the NeXT, which certainly didn't help its sales, but a lot of smart people believed that Improv would be to NeXT as VisiCalc was to the Apple II: it would be the killer app that made people go out and buy all new hardware just to run one program.

Of course, Improv is now a just footnote in history. Search for it on the Web and the only links you'll find are from over-organized storeroom managers who have, for some sick reason, made a Web site with an inventory of all the stuff in their closet collecting dust.

Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they had asked people, they would have discovered that making lists was vastly more popular than multi-dimensional financial models. And in Improv, making lists was a downright chore, if not impossible. Oops.

So, activity-based planning is helpful in the initial version of your application where you have to make guesses about what people want to do. But it's even more helpful when you're planning the upgrade because you understand what your customers are doing.

Another example from the Web is the evolution of, which started out as a huge, searchable index of Usenet called DejaNews. The original interface basically had an edit box that said "search Usenet for blah," and that was it. In 1999, a bit of activity-based planning showed that one common user activity was researching a product or service of the "which dishwasher should I buy" nature. Deja was completely reorganized and today it is more of a product-opinion research service: the Usenet searching ability is almost completely hidden. This annoyed the small number of users who were using the site to search for whether their Matrox video card worked with Windows 2000, but it delighted the much larger population of users who just wanted to buy the best digital camera.

The other great thing about activity-based planning is that it lets you make a list of what features you don't need. When you create any kind of software, the reality is that you will come up with three times as many features as you have time to create. And one of the best ways to decide which features get done and which features get left out is to evaluate which features support the most important user activities.

When you are struggling to cut features, having a detailed list of activities you want to support is going to make it much easier. And it's a great way to convince crabby old Marge that her beloved lint-removal feature isn't really worth spending time on.

Imaginary Users

The best UI designers in the industry may bicker among themselves, but they all agree on one thing: you have to invent and describe some imaginary users before you can design your UI. You may remember back in Chapter 1 when I introduced an imaginary user named Pete.

When you read this, you can almost imagine a user. I could also have invented quite another type of user:

Obviously, designing software for Pete is quite different from designing software for Patricia, who in turn is quite different from Mike, a sixteen-year-old who runs Linux at home, talks on IRC for hours, and uses no "Micro$oft" software.

When you invent these users, thinking about whether your design is appropriate becomes much easier. For example, a lot of programmers tend to overestimate the ability of the typical user to figure things out. Whenever I write something about command-line interfaces being hard to use, I get the inevitable email barrage saying that command-line interfaces are ultra-powerful because you can do things like gunzip foo.tar.gz | tar xvf -. But as soon as you have to think about getting Patricia to type "gunzip..." it becomes obvious that that kind of interface just isn't going to serve her needs, ever. Thinking about a "real" person gives you the empathy you need to make a feature that serves that person's need. (Of course, if you're making Linux backup software for advanced system administrators, you need to invent a character like "Frank" who refuses to touch Windows, which he only refers to as an "operating system" while making quotation marks in the air with his fingers; who uses his own personally modified version of tcsh; and who runs X11 with four tiled xterms all day long. And about 11 xperfs.)

Designing good software takes about six steps:

  1. Invent some users.
  2. Figure out the important activities.
  3. Figure out the user model—how the user will expect to accomplish those activities.
  4. Sketch out the first draft of the design.
  5. Iterate over your design again and again, making it easier and easier until it's well within the capabilities of your imaginary users.
  6. Watch real humans trying to use your software. Note the areas where people have trouble, which are probably areas where the program model isn't matching the user model.

Watch Out for Unintended Consequences

One of the most famous UI metaphors of all time is the trash can from the Macintosh desktop. The original metaphor was terrific: when you dragged a file to the trash can, it was deleted. And the neat thing was, you could look in the trash can and see all your old deleted files! So if you ever dragged something there by mistake, you could get it back. How do you get a deleted file back? You drag it out of the trash can, of course! An excellent metaphor (see Figure 12-1).

There was one problem. After a few releases, the Mac designers went a little too far and decided that a trash can with something in it should look "stuffed," so when you drag something in there, you get a full trash can instead of an empty trash can. The trouble is that neat freaks were distracted by the full trash can. It looks messy. When they wanted to clean up, they would empty the trash. Over time, many people got into the habit of dragging things to the trash can and then mechanically emptying the trash so that the trash can wouldn't look messy, thus defeating its original purpose: to provide a way to get things back!


The Macintosh trashcan, bane of neat freaks everywhere

The moral of the story: spend a few hours quietly watching real users in their real environment; there's a lot you can learn. I'll talk a lot more about this in the next chapter.