Making Research Actionable: An Introduction to Design Criteria

by Sarah B. Nelson

June 12, 2008

What happens when people want a company’s product, but are frustrated by the process of trying to get it? Obviously it should be reworked — but doing so can be easier said than done. When we’re asked to redesign a process, we often start by exploring the problem space with in-context research, which generates a large amount of data. That data tends to point teams in the direction of a number of possible solutions. But how should the team decide which direction is the right one? In such cases, I’ve found that Design Criteria — a set of rules a design team can follow — can be a key tool so when a design team creates or reworks a service or product, everything it does supports the user.

Rooted in Research

How do we draw up Design Criteria, and how can they help our clients? Let’s look at the case of a small company I’ve been working with. The company knew that users had difficulty dealing with its website, wanted to help them, and could explain some of the problems they were experiencing. It also knew that because its business is complex, one key problem couldn’t be solved: users need to devote a fair amount of time to setting up an account. But it didn’t think this problem explained its failure to turn so many prospects into customers.

We suspected that in dealing with account setup, people were having problems that hadn’t been revealed by the company’s site metrics or usability tests. So we launched an extensive in-context research study, mental model, and persona development exercise. We found that users rarely knew what to expect from the process, which constantly surprised them, particular with requests for new information. Often, they had to stop work to get this info. Users also consistently underestimated how long the process would take. Even two to three hours into setup, many said the whole process should take “about an hour.” A number either quit before they’d finished, or grew increasingly frustrated, sticking with it only because they felt they had no choice.

The client can’t do much to solve certain problems inherent in the setup process. Users have to retrieve information from their personal files and badly designed government web sites, and make decisions based on confusing tax laws. And users vary widely in their ability to deal with these obstacles, as well as with the site itself. We had to minimize the effect of all these factors, to make setup easier and quicker for everyone.

Enter Design Criteria

Project goals, success metrics, brand and mission statements, and universal design principles are all useful in their own way. But in improving specific experiences, Design Criteria can play the critical role, because they’re research-based, and tailored to each project.

There’s an art to drawing them up. They should give a design team clear direction, while leaving it room to explore different approaches to each problem. And they have to be clear and concise, but neither so reductive that they’re open to broad interpretation, or so abstract that they don’t suggest concrete solutions.

Let’s look at a key pain point for my client’s customers: information gathering. We knew that no matter what, they’d need to rely on a number of sources, and some information would need to come from other people. We could help them store and organize it once they had it, but couldn’t help them collect it.

What Design Criterion would help us make this process less difficult? We could have gone with something abstract and general — say, “Make information gathering easy.” But what’s “easy” in this context? And could we really make this process “easy?” We needed something more specific, pointing the way toward a viable solution.

We might have chosen “Tell customers upfront exactly what they’ll need.” But checklists didn’t seem like they’d be much help.

So we settled on “Find Efficiencies.” Working with this directive, the team looked at various stages of setup, and asked, “In this context, what does it mean to be efficient?” The next step was drawing up “dimensions of efficiency,” such as streamlining data entry, asking at the same time for information that’s taken from the same source, or entered in the same place on a form, and presenting tasks in groups, to make them more manageable. Following on this, team members asked more questions, such as: “How do we make data entry efficient?” “Can we provide access to electronic versions of necessary government forms, for example, and batch-upload entered data, rather than asking users to transfer it manually from forms to the system?” As we asked these questions, we built a base of ideas for creating workable, powerful solutions to the problems plaguing setup.

Generating Design Criteria

For most projects, I like to use five to seven Design Criteria. Too many, and the team can’t remember them all; too few, and they won’t cover all the problems at hand.

Rather than draw them all up at once, at the beginning of the design process, I tend to keep a running list of ideas as I work, making particular note of anything that jumps out at me as I look at the results of user research. At the end of the research phase, I put together the final Criteria, drawing some from my notes, and supplementing them as need be. Often our design team plays a key role in fleshing out the list.

A starter list might look like this:

• Ask customers for what they have, rather than asking them for what the company needs.
• Allow customers to say they “don’t know.”
• Provide a consistent experience, from interaction and visual design to copy.
• Be clear about what the system can do, and what the client is responsible for.
• Be friendly and reassuring.
• Show customers where they’ve been, and where they’re going.
• Allow graceful recovery from unexpected interruptions.
• Make it easy for customers who need to gather critical information to pick up where they left off.
• Set clear expectations.

Here’s where the art comes in. I’ll sort the list, identifying items that can be combined or are thematically related. Once I have five to seven that are both unique and specific to the project, I refine the wording. I look for statements that are short and memorable. The statements should both help team members focus, and inspire them to generate ideas. Then I test each draft Criterion by asking myself:

• Am I inspired by this? Can I think of ways to translate it into real-life solutions?
• Does this challenge me to ask useful questions?
• When I show this to someone else, can they understand it easily?

When sharing Design Criteria with clients or those outside the team, I like to support each one with a powerful quote from user research, as well as examples from the Web and elsewhere, showing solutions that embody it. These supporting materials serve as a source of inspiration, and a starting point for further discussion.

Using Design Criteria Throughout the Design Process

I’ve talked about Design Criteria mostly as a source for generating ideas early in the design process. But they can be used throughout that process, to support communication, evaluate concepts, and quickly bring new team members up to speed. Keeping them short, memorable, and directive will give your team a great foundation on which to build elegant, powerful designs, then help them do so, from start to finish.