• Making Research Actionable: An Introduction to Design Criteria

    Hello! At Adaptive Path there is a near constant discussion about practice development and which methods apply best to which kinds of challenges. These conversations take place on our blog, in our publications, and at our conferences. I'm looking forward to facilitating this dialog at UX Week in August on our home turf in San Francisco. In the meantime, I'd like to share an essay with you about how to guide the research process. I've also included links in the AP Blog section below to method-related posts. I look forward to hearing your feedback, and hopefully meeting you in person at UX Week.

    Sarah Nelson

    Making Research Actionable:
    An Introduction to Design Criteria
    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.

    Adaptive Path News


    Adaptive Path Partner Acquired by Nokia
    Last week, Nokia announced an agreement to acquire Plazes, the Berlin-based service for connecting people to the places where they spend their time. We’re very excited for our friends on the Plazes team, and offer them our heartfelt congratulations.

    MX Speaker Videos Are Now Online
    We’re happy to announce that this year’s MX Conference presentation videos are making their way online. If you didn’t get a chance to attend, this is a great opportunity to see complete talks by Chip Conley (Joie de Vivre Hotels), Matt Jones (Dopplr), and Margaret Stewart (Google). Chip told us how he successfully applied Maslow’s Heirarchy to a fundamental reinvention of his hotel business, while Matt blew our minds with “Battle for the Planet of the Apes:  A Perspective on Social Software and Social Networks.” Margaret Stewart’s presentation on “The Manager as Tailor” was highly entertaining and gave attendees some great tools and tips to help them identify their management strengths.

    AP Named as a Mobile Innovator
    The recent E-Commerce Times article, Moving to the Mobile Web lists Adaptive Path as one of the leading designers in the mobile space. Check out some of our recent mobile design posts.

    Get the FeedSelections From Our Blog


     

    • Sebastian Heycke: Chatting with Stamen Design
      Sebastian Heycke recently interviewed Mike Migurski (Director of Technology) and Tom Garden (Interaction Designer) from Stamen Design about their upcoming workshop for Adaptive Path’s UXWeek.
    • Peter Merholz: Microsoft Surface Added to UX Week
      We’ve just added a presentation on Microsoft's large-scale multi-touch device: Surface. Titled “The Challenge of Emotional Innovation,” the talk will address the evolution of the gestural and affordance-based design of the Surface, and the research that supports and refines it.

    What We're Reading


     



  • Close
    Team Profile