Figuring Out Your Design Decision Style

Suddenly, it got meta. There we were—the team and I—trying to decide which styles of design decisions the team would use from now on.

Deciding how to decide things sounds like we were in one of those corporate stalling tactics, like talking about having a planning meeting to talk about planning meetings. Yet we weren’t stalling. We were making an important decision about how the team would work together.

At the time, this was a fairly new team. The bulk of the team had worked together for a little longer than a year, with a couple of new additions in the last few months.

In that period, the team found themselves reacting to what the company needed built. They had become a service team that made quick and obvious product improvements.

From the team’s work, the company had realized the successes that come from focusing on experience design. They were directly responsible for happier customers, lowered support costs, and increased sales. The company’s executive team saw these results and was hungry for more. The team needed to become more proactive.

Making Smart Design Decisions

Like many teams I work with, they had learned to work together through an ad-hoc process. They never decided how they’d make decisions. They made each decision based on whatever information and opinions they had at the time.

For small, quick projects, I’ve seen ad-hoc decisions work pretty effectively. However, over time, the decision process starts to look like a drunken sailor’s walk, meandering in different directions with different approaches every time they face a new decision. When you’re building a team and trying to have a larger affect on the organization, this approach won’t get you there easily.

In our research, we’ve seen the most effective design teams are very deliberate about how they make decisions. They pick a decision-making approach early on, get everyone on board (including senior management), and then stick with it throughout the project.

The team’s Director of User Experience had seen me give a presentation about our research. (This one, in fact.) He now wanted his team to choose the right decision style for their future work. He invited me to help work through their choices.

We collected the team together. These were super talented folks, with a wide variety of backgrounds. Like many teams, there were a few members with strong opinions about the right way to do things. Others were more open to exploring approaches. We gathered in a conference room and started the conversation.

The Cheap Style: Unintentional Design

“Ideally, whatever we do should be cheap and easy,” the Director of UX told the group with a big smile.

“The cheapest style is Unintentional Design,” I responded. “But they wouldn’t need any of you to do it.” Unintentional design is what emerges when a team only pays attention to the technical implementation or the specific needs of the business.

A simple example of unintentional design is an error message written quickly as a placeholder by a developer, expecting someone will write something better later, but nobody does. For example, in the most recent release of Healthcare.gov, leaving the gender field empty gets an error message simply stating “Sex is required.” Nobody decided this was the right error. But a message was needed, so in the rush to get it out the door, that’s what got shipped.

When nobody pays attention to the user experience details, they evolve on their own, creating frustration and confusion for users. The emerging poor user experiences are haphazard and unconsidered. They raise support costs and users hate them, making word-of-mouth recommendations hard to come by.

However, it’s inexpensive to implement unintentional designs. As I told the team, “Once you remove quality as a requirement, building your product gets a whole lot easier and cheaper.” Talented designers aren’t needed if you’re willing to let any experience emerge out of the rubble of the technical design.

“Ok, that’s not going to work for us,” the Director said with a smirk.

The Expensive Style: Experience-Focused Design

“What about Experience-Focused Design?” one of the senior team members asked. “I heard you talk about that. It sounds exactly like what we should be doing.”

Experience-focused design is when the team focuses on the total experience of the users. In addition to designing the interactions of any applications or web sites, they design the users’ experiences leading up to, between, and after those interactions.

Disney’s new Magic Band bracelet, for example, is much more than a wearable device. The Disney design teams worked on how the bracelet changed the total experience for their park and resort guests. Every place the bracelet could do magic, like being the key to the guest’s hotel room door or the credit card for any payments in the park, they built it in.

I’ve found working on an experience-focused design project is a common dream for passionate user experience professionals. This kind of work gives the designer control over many of the contextual and environmental elements, from signage to network integration. It’s amazingly challenging and hugely fun. Done well, it changes the lives of the users. Who wouldn’t want to be part of that?

However, it’s also hugely expensive to pull off. Disney spent more than one billion dollars on the integration of the Magic Band. This kind of investment is beyond most organizations.

“Someday, but we’re not there yet.” the Director pronounced.

The Talent Investment Style: Self Design

One of the newer designers piped up. “I liked what you said in your talk about Self Design. Maybe we could use that?” Self design is when each designer creates a product they’d personally like to use.

The first iPhone is a famous example of a team using the self design decision style. The team at Apple didn’t need to go off and do a ton of research about the problems and frustrations people had with their phones.

Each member of the iPhone team hated the old phone they were using. They experienced the problems and frustrations first hand. They created something that would make them happy, in turn creating something that made millions of people happy.

Self design works best when the product is something they use every day. If the team unintentionally introduces a frustrating feature or aspect into the design, they’ll encounter it and fix it.

Self design teams tend to have limited diversity. After all, you need everyone to think the same way to make the product feel cohesive. The teams also can’t grow very much, because adding more designers will introduce variations in perspective, which will introduce rough spots into the designs.

Cost wise, it’s a relatively inexpensive approach. The organization’s primary investment is in the talent of the designers. However, it’s a limited approach. It’s great for a first version of a new type of product, but doesn’t work for ongoing versions of the design, especially when the team needs to introduce features they may never use themselves.

The Research-Grounded Style: Activity-Focused Design

“It’s sounding like Activity-Focused Design may be your best option,” I suggested. Activity-focused design is the closest style to conventional ideas like user-centered design. It’s when the team spends their time researching the users and their activities. The team uncovers the users’ needs and how the product will address those needs.

Using an activity-focused design decision style, the team looks past their own opinions of how the product should work. Instead, they spend time with their users, diving deep into what those users’ objectives are.

With this style, teams use tools like personas, scenarios, and journey maps. They regularly conduct extensive user research through usability testing and field observations. They create prototypes for users to try and iterate through variations on designs.

All that research isn’t cheap. It takes time and resources. It is most effective when everyone—including the product managers and developers—meet the users and see how they interact with the designs. The costs for all this research adds up quickly.

Yet these costs are worth it for organizations serious about meeting the diverse needs of their most critical users and customers. The designers spot frustrations and smooth out the rough edges. They can create delightful experiences that easily differentiate their product from their competitors.

“That’s what we’ve been trying to do,” the Director said, “but when we skip the research, we fall back into self design.”

“Yea, except our designers are not all alike,” added one of the team leads. “That explains why some parts of our product are frustrating users. We’re all approaching our assignments differently, not taking our users into account.”

The Long-Term Style: Genius Design

“I supposed we should use Activity-Focused Design from now on,” the Director declared.

“It’s a good place to start,” I replied, “but you could work your way to Genius Design.” Genius design happens when a team gets to know their users so well that they can accurately predict the results of any research. They learn to become geniuses about their product’s domain.

We see this decision style most often in agencies that are chasing a particular niche market. For example, an agency that works with high-end boutique bakeries would learn everything there is to know about small bakeries and how they operate. They’d study up on the variations and operations. The agency’s offerings could include consulting and expertise on how to run a bakery efficiently, because they’ve learned the best practices of other non-competing bakery clients.

The path to genius design starts with activity-focused design. When the team has studied the users and activities of a variety of their customers, patterns will start to emerge. Over time, the team becomes so versed in the commonalities across customers they can predict what future research will tell them. Those predictions can become so accurate, the team no longer needs to do most of the research. They are now using the genius design decision style.

Genius design reduces the cost of any given project, due to economies of scale. Because the team has learned what’s common, they can develop tools that will meet the needs of a large number of their customers. Using those tools across further projects brings down the overall investment.

Genius design only works when the work from new projects can take advantage of the research and design work from previous projects. If there’s not much overlap in the users and their needs, then activity-focused design is the better option.

A Different Style for Every Team

This team settled on starting with activity-focused design, looking to move to genius design after a while. They believed their future product plans would give them a lot of overlap as they expanded new functionality, which would let them take advantage of what they already have researched.

That won’t work for every team, however. Every design style has a place and time. The competitive landscape, the nature of the product or service, what the customers need, and how mature the UX efforts in the organization will all play a role in the decision.

Teams need to regularly re-evaluate their own decision styles. Are they still using one that’s appropriate for their needs? Are they sticking with it as the projects progress? Is everyone thinking it’s the same style?

The best teams stay on top of how they are making decisions, not just the decisions they are making.