5 Design Decision Styles. What’s Yours?

by Jared M. Spool

In the early days of e-commerce, we studied how seasoned hiking customers bought hiking boots online. Two sites in our study, L.L. Bean and REI, both sold virtually identical boots at the same price with practically the same marketing copy. Yet the customers we studied were far more likely to buy the boots on the REI site than on the L.L. Bean site.

Why? Because the product pictures on the REI site showed the bottoms of the boots, whereas the L.L. Bean imagery only showed the boots standing upright. For people experienced with buying hiking boots, the tread on the bottom is important. Choosing a tread, for some hikers, can be a matter of life or death. The experienced hikers were more comfortable buying their boots from the site that clearly featured the tread design.

We were very curious how the REI design team knew to tip one boot over to highlight the tread. We figured it was because they’d done extensive research on which pictures sold best, settling on the configuration with the best performance. We called them and asked if our theory about their research was correct. They laughed. Loudly!

Once the laughing stopped and they recomposed themselves, one of them volunteered no such research had been done. Instead, the idea came from their photographer who, they revealed, had previously worked in the footwear department at one of their stores. He just instinctively knew to tip over the boots because, in the stores, he watched the customers pick up the boots to look at the tread. Had he not worked there, the team never would’ve thought to tip the boots over. (Apparently, the laughing was because they constantly teased him about this, not knowing his idiosyncrasy was the key to their success.)

Design Decision Styles

The photographer on the REI team was making design decisions, not based on thorough, conclusive user research, but from his own experience working in the store. L.L. Bean’s photographer didn’t share the same experience, so didn’t make the same decision. The results of each decision showed in the sales of their products.

Over the last few years, we’ve been studying the process designers (and their teams) use to make important decisions like these. In the course of our work, we’ve discovered there are five common styles of design that almost every team uses: (1) Unintended, (2) Self, (3) Genius, (4) Activity Focused, and (5) User Focused.

The order reflects the increasing amount of research the team employs to make decisions. While one could also think of the order as a growing maturity of the team, it turns out that each one has its place. Some projects don’t warrant the costs, time, and resources necessary for extensive user research, but other projects will fail without it. Knowing when more extensive research is necessary is key to good experience design management.

Decision Style #1: Unintended Design

“The reason this product is so frustrating to use is that nobody actually designed it.” That often felt sentiment is not quite correct because every product has a design. It’s just that the people building the product didn’t pay attention to its design during the construction.

Unintended Design happens when the team focuses on the act of development and deployment without any consideration of what will happen when people try to use it. Not all unintended designs are bad—some can be quite usable. It comes down to a game of chance. (Think of the old maxim, “Even a blind squirrel finds an acorn every so often.”)

Decision Style #2: Self Design

Another “low-end” decision style, Self Design, results from teams that design purely for themselves. Most common in single-person teams, this approach has better odds of success than Unintended Design, but not by much.

It works best when the team members really are the primary users of the application. For example, many in-house bug tracking systems are self designed and quite good. They do exactly what the team needs without a lot of fuss.

Unlike the Unintended Design decision style, where design decisions are usually informed by a “what’s easiest to implement” rationale, decisions from the Self Design style are informed by the team members own use of the design. The quality of the decisions will improve the more the team members seriously use the design themselves.

Decision Style #3: Genius Design

Like the Self Design style, teams employing Genius Design don’t look beyond their own experience to inform their decisions. However, the Genius Design style looks to the vast previous experience of the team members.

The REI photographer used this decision style when revealing the boot treads in the photographs. He looked to his past, remembered how he observed people making purchases, and decided accordingly.

Genius design works well with very experienced team members. If you’ve already designed five different shopping carts, each complete with thorough research on the users and their scenarios and follow-up work to see how well the designs met expectations, then designing a sixth shopping cart without all that rigorous research will probably produce great results.

But that’s the trick to Genius Design—there has to be solid research experience in the past to base the current decisions on. Just having designed the functionality before doesn’t count, unless the research also went with it. (We could’ve called this style Seen-It-All Design instead.)

Decision Style #4: Activity-Focused Design

Teams using the Activity-Focused style will plan and execute research looking at the users’ activities. For example, when designing a photo sharing web site, the team would research the specifics of uploading, sharing, printing, and the other direct functions supported by the design.

Teams need this style when the activities are new or foreign to the team members, and can’t rely on their own experience, like when using the Genius Design style. Often the research utilizes activity-based techniques, such as workflow diagramming and task-based usability testing. These simple techniques can provide important insights that improve the design decisions.

Decision Style #5: User-Focused Design

Those teams employing a User-Focused Design decision style are the ones who conduct the most user research, looking beyond just the activities. These teams look in-depth at the goals, needs, and contexts of the users, using that information to drive decisions into depths the team can’t reach otherwise.

This design style is the high-end approach and is necessary if the team is looking to create an excellent experience overall. To do that, the team will use user-focused techniques, such as field research and robust persona creation, ensuring the team understands the contextual nature of the users’ experience.

Using these techniques, a team working on the photo sharing site might discover that people often peruse photos of people they don’t know, because they respect their photographic skills or subject decisions. This could lead to insights into developing new functions that let people track photographers they admire or look for examples of people using certain types of camera equipment. These “fringe” ideas would be hard to come by using other design styles, but could provide delightful functionality that strengthens the engagement of the users.

Different Styles for Different Projects

In our research, we found that the most effective teams were skilled in all five styles, choosing the style that best fit the needs and goals of a project. For example, they might concurrently be involved in deep research on a User-Focused project, while relying on their experience for a Genius designed project, and spend a little time whipping out some one-shot functionality whose results would be Unintended Design.

Since the teams are working with different styles all the time, does it matter? Our research says it does. The teams that produced the best experiences knew these styles well and how to quickly switch between them. They knew when they needed to go whole hog and pull out all the stops for a User-Focused style project, while also knowing when it was important to bang out a quick design, knowing the results would essentially be unintended. Those teams had a rich toolbox of techniques and a solid understanding on how and when to use them.

Published here on January 21, 2009.