The following experts have contributed answers to this edition of Ask UXmatters:
- Carol Barnum—Director and Cofounder, Usability Center at Southern Polytechnic State University; author of Usability Testing Essentials: Ready, Set. . . Test!
- Dana Chisnell—Principal Consultant at UsabilityWorks; coauthor of Handbook of Usability Testing
- Leo Frishberg—Principal Architect, User Experience at Tektronix Inc.
- Gerry Gaffney—Founder and Lead Consultant at Information & Design
- Adrian Howard—Generalising Specialist in Agile/UX
- Mike Hughes—User Assistance Architect at IBM Internet Security Systems; UXmatters columnist
- Jordan Julien—Independent Experience Strategy Consultant
- Tobias Komischke—Director of User Experience, Infragistics
- Whitney Quesenbery—Principal Consultant at Whitney Interactive Design; Past-President, Usability Professionals’ Association (UPA); Fellow, Society for Technical Communications (STC); UXmatters columnist
- Daniel Szuc—Principal and Cofounder of Apogee Usability Asia Ltd.
- Jo Wong—Principal and Cofounder of Apogee Usability Asia Ltd
Q: How do you bridge user research into design?—from a UXmatters reader
“I hardly know where to begin with such a big question,” exclaims Whitney. “The metaphor I used years ago is that starting a design is like reading fortune-telling cards. If you took some of the cards out of the deck, you wouldn’t get the right answer.
“In a non-UX process, we so often see business, marketing, and technical needs represented in design decisions, while the perspectives of actual users are completely absent. UX research brings those perspectives into the process, completing the deck. Design is not a mechanical process. UX design takes all the insights and skills of a good designer or design team. But what makes it UX is ensuring that design focuses on the user experience—context, activities, goals, and emotions.”
If you want to learn more about bridging user research into design, Whitney recommends that you read the works of Steve Portigal, Josh Seiden, and Indi Young. She also recommends Tomer Sharon’s upcoming book, It’s Our Research, “which stresses engaging the whole team in the research process.”
“This is a very broad question,” answers Jordan, “and the answer comes down to the type of user research and the type of design. I’ll assume we’re talking about designing a digital platform or program and will quickly explain how to use initial user research, goal-based user research, and on-going user research.
Initial User Research—Discovery
Platform—User personas, journeys, and scenarios
Use—These personas, user journeys, and scenarios should inform what feature sets and platform requirements get defined. It’s these feature sets and specifications that define what gets designed.
Program—User insight framework
Use—This framework should focus on a single important insight and expand on how it influences behavior. This insight should be the guiding principle for all ideation sessions. Ideation, of course, should lead to the design solution.
Goal-Based User Research—Testing
Platform—Card sorts, usability testing, focus groups, and surveys
Use—This type of research is helpful in defining design options, during the design process. It is often useful in getting user feedback on different design options, but also in gathering up-front insights.
Program—Heuristic testing and informal testing
Use—Generally, programs require a more emotional response than platforms. In this case, testing should focus on documenting users’ emotional state and emotional response to different design options.
On-Going User Research—Multivariate Testing / Goal Tracking
Platform—A/B testing, multivariate testing, and goal tracking
Use—This research can help you adapt your designs to how users are actually interacting with your platform. It’s best to plan what elements you want to test and what insights you’d like to get from the tests.
Program—A/B testing, multivariate testing, and goal tracking
Use—Often, programs don’t have a long enough lifespan to perform meaningful A/B or multivariate testing. That said, you should perform these types of tests and compare the results across multiple programs whenever possible. These learnings can help you optimize and refine designs.”—Jordan Julien
“I think this is a great question,” replies Tobias. “There’s nothing worse for a UX professional than standing in front of an empty, white wall. You have all your inputs, all the contextual knowledge, but yet, there are so many design alternatives! How do you start?
“Well, I just start with the first design alternative that comes to mind: think brainstorming with a pencil. Don’t constrain yourself, just sketch out as many ideas as you have. You can eliminate those that don’t make sense later. If you can show many design alternatives to your stakeholders, they can identify the good and not-so-good characteristics of each of them. Then in the next iteration, you can try to incorporate all of the good aspects into just one or two designs alternatives and take it from there.”
The Boundary Between Research and Design
“Research that doesn’t bridge into design is useless,” asserts Whitney. “The research team may have learned a lot, but unless the whole product team gets immersed in the research findings—even if they don’t become deeply engaged in the whole research process—it remains siloed knowledge.”
Leo agrees: “In my process, there is no difference between research and design. Good design begins with good research—it is all part of one continuum. When designers are on your research team, the diversity of the questions and insights you can glean from interactions with users increases substantially, leading to a very rich understanding of the problem space. When you have designers on your research team, the way they frame the questions and interpret, or code, the answers already sets the stage for actionable results.
“Because design is inherently a rapid, iterative process, designers with a sensitivity to user-centered processes not only expect to participate in the initial research, they expect to continue the process of research even as design artifacts are emerging.”
“If the challenge is to have the right inputs for the design—that is, the right outputs from research—I advise you to be conscious of the fact that your research methods pretty much determine how easy or hard it will be to start designing seamlessly,” says Tobias. “At a minimum, you need the following four inputs for design:
- data elements—the objects users refer to, present, manipulate, and act upon—for example, records, stocks, or photos
- functional elements—the operations users can execute on the data elements—for example, create, edit, or copy
- a taxonomy—the basis for organizing the data elements and functional elements and relating them to each other—for example, users need to be able to delete a photo
- scenarios, use cases, or user stories—the paths through the taxonomy that users follow when accomplishing a task—for example, users first upload a photo, then map it to a customer record
“Your research must unveil all four of these inputs. If you look at taxonomy, it becomes clear that there’s no clear distinction between research and design. A taxonomy can be the result of research—for example, when you use card sorting to understand how the users of a Web site envision the distribution of content across Web pages. But the taxonomy can also be the result of design. For example, you might change the taxonomy that resulted from your research by consolidating the content on two pages into one page.
“Let’s assume that you have all four of these inputs,” Tobias continues. “What’s next? I strongly believe in breadth before depth—meaning that you need to design for the full functional breadth of your product before you design for functional depth. If you don’t, you may learn about the need for some crucial parts of the system too late in the game and find that your already established design framework doesn’t accommodate those parts. It’s like building a house: You want to plan out all of the floors and rooms before you worry about the pictures on the walls. Oh, you want to add another room on the second floor without changing the existing rooms on the first floor? Not a good idea.
“The taxonomy should allow you to determine what data elements and functional elements should go together on one screen—or page or window—
based on the scenarios. With that knowledge, you can create a map on a whiteboard that includes all of those screens. The taxonomy and scenarios should also allow you to understand which screens should be close to others in terms of navigation—to support users’ various workflows. You can draw lines with arrows between screens to show those paths. The result might look similar to the map in Figure 1. (I had to remove the screen names. DE = data element; FE = functional element. The color coding of screens represents different user groups.)
“You should validate your map with stakeholders and users. Once this map is stable, you have the equivalent of a floor plan for a new house. The next step is to work within the rooms—your screens—to make sure that it’s clear how to get in, how to get out, and what to do within them.
“What’s the interplay between users and the product on any specific screen or within any area of a screen? To determine that, I recommend that you check whether there are already existing ways of doing that. The magic word is patterns—generic, reusable solutions to user-interface design challenges. You can buy Jenifer Tidwell’s book, Designing Interfaces, or you can use Quince, Infragistics’ free pattern explorer. All other user-centered design methods apply, including screen design best practices such as alignments, contrasts, and grid-based design, as well as formative usability testing.”