Top

Defining Clear Product Requirements | Viewpoints for Design Reviews

Ask UXmatters

Get expert answers

A column by Janet M. Six
March 21, 2016

In this edition of Ask UXmatters, our expert panel discusses two topics:

Our experts first discuss how to elicit clear product requirements from stakeholders. Does the right approach differ for small versus large companies? Do product requirements capture the goals of stakeholders? Do requirements reflect the true needs of users? Do they establish a good understanding of technical constraints? How can you validate the assumptions behind product requirements? What kinds of research should influence the definition of product requirements? How should you balance the needs of users versus the business?

Then, our expert panel considers some different viewpoints from which we can review design solutions: stakeholders’ business goals, the needs of users in various roles, and the feasibility or ease of implementation. On the other hand, focusing on one particular user’s needs during a design review can yield a greater number of insights. Considering different user-interface layers lets you structure your evaluation of a design solution. Plus, it’s important to consider the effectiveness of design artifacts as well.

Every month in Ask UXmatters, our panel of UX experts answers our readers’ questions about a broad range of user experience matters. To get answers to your own questions about UX strategy, design, user research, or any other topic of interest to UX professionals in an upcoming edition of Ask UXmatters, please send your questions to: [email protected].

The following experts have contributed answers to this edition of Ask UXmatters:

  • Pabini Gabriel-Petit—Head of UX for Sales & Marketing IT at Intel; Principal Consultant at Strategic UX; Publisher and Editor in Chief, UXmatters; Founding Director of Interaction Design Association (IxDA); UXmatters columnist
  • Caroline Jarrett—Owner and Director at Effortmark Limited; UXmatters columnist
  • Cory Lebson—Principal Consultant at Lebsontech; Author of UX Careers Handbook (forthcoming); Past President, User Experience Professionals’ Association (UXPA)
  • Mike Murphy—Senior Design Director at GfK
  • Rick Omanson—Vice President of UX at GfK
  • Baruch Sachs—Senior Director, User Experience at Pegasystems; UXmatters columnist
  • Jeremy Wilt—Lead Experience Architect at EffectiveUI

Defining Clear Product Requirements

Q: How do you elicit and define clear product requirements? Is the process of requirements definition significantly different in a large company—especially one that follows a more rigid approach to product development—than in a small company with a more flexible approach?—from a UXmatters reader

“Whether a company is large or small, there are several important considerations that typically go into defining product requirements,” replies Cory.

  1. “Why is the company planning to develop the product?
  2. “What do potential users want out of the product—that is, why are they going to care enough about the product to use it and what critical features are necessary for product adoption?
  3. “What are the known technological and business limitations that are going to place constraints on what the team can develop.”

“Ultimately, before the requirements become codified, it is important to do the necessary research. Interview the key leaders and stakeholders who are driving the creation of the product. Ask them why they want to create it—and don’t accept vague answers. Drill down until you can get to the very specific reasons they think the product should be created and for whom.

“Gather and use market-research data to provide context and better understand the attributes of your target market. Do ethnographic research to find out both what user expectations might be for the product and how existing or representative users currently use your product or competing products. And finally, talk with those who are knowledgeable about technology constraints to find out precisely what product limitations are immutable and what constraints may exist for which there are potential workarounds.”

“In my On Good Behavior column “Design Is a Process, Not a Methodology,” I wrote about product requirements in some detail,” answers Pabini. “In that column, the section ‘Step 4: Eliciting and Defining Clear Product Requirements’ covers business requirements, market requirements, user requirements, and technical constraints.”

Friend Advertisement
Continue Reading…

Writing User Stories

“I’ve since adopted the practice of writing epics and user stories to capture requirements,” continues Pabini. “This agile approach works well in both large and small organizations. Start by writing epics—big stories that provide an overview of a capability—then iteratively break the epics down into smaller user stories. Avoid decomposing epics into user stories too far in advance of their implementation. When writing user stories, determine the proper level of detail to provide, as follows:

  • Write small, fine-grained user stories and conditions of satisfaction, and capture notes from discussions about top-priority capabilities your team will develop in the next few iterations. As a team, set priorities and estimate story points for these user stories. Small user stories should typically take only 1 or 2 days to implement and no more than 10 days.
  • Write an epic and the key user stories—and any other user stories your team wants to capture—for capabilities you’ll implement during later iterations.
  • Write only epics for low-priority capabilities that your team either plans to develop in much later iterations, may defer to a later release, or may decide not to implement.

“There are two ways of adding detail to user stories: writing additional, more fine-grained, subordinate user stories or adding conditions of satisfaction to existing user stories. These approaches are not mutually exclusive.

“Write both epics and user stories using the following format:

  • As a[n]...—Describes a user’s role.
  • I want to...—This is the user story itself and describes a task or goal the user wants to be able to accomplish.
  • So I can...—Describes the value of the story to the user.
  • Verify that...—Describes the conditions of satisfaction for the user story.

“For complete information about writing user stories, I recommend that you read Mike Cohn’s book User Stories Applied: For Agile Software Development,” says Pabini.

First, Understand the Users’ Needs

“Focusing on gathering product and business requirements first is, at some level, altogether the wrong approach,” responds Baruch. “Capturing jobs to be done, or task goals, then distilling more granular requirements from them is what you really need to do—regardless of whether you are at a large or a small company.

“Too often, we simply accept requirements from the business or IT that are based on incorrect assumptions. In such cases, before you know it, you end up with a product that met all of the requirements, but did nothing for the people actually using the product. This happens because the product team never fully understood the goals. No one actually sets out to build the same system they already have or to recreate a manual process. Yet assumptions that are based on what already exists are the very essence of what feeds into the requirements-definition process. So why not look at this whole process a bit differently?”

Stakeholder and Customer Research

“Try doing stakeholder and customer research instead of defining requirements by committee,” suggests Jeremy. “There’s nothing more painful than spending hours in meetings only to come away with a huge spreadsheet of functional requirements.

“Interview your product stakeholders, then through analysis and synthesis, capture what they believe matters most for the product. This gives stakeholders a strong voice in defining the product direction—especially at a large, rigid company. Then interview existing customers or users or those who might potentially use the new product to understand their needs, motivations, and behavior. If you have time, dig into task analysis to better understand their needs and how the product’s user experience can support the way people would use your product.” Jeremy recommends reading Jon Strande’s article “Rich Task Analysis.”

“Once you’ve listened to stakeholders and customers, spend some time comparing what success would look like for each group of stakeholders,” continues Jeremy. “Capturing your analysis on sticky notes lets you quickly combine insights into groups—by doing affinity mapping—to see what features and requirements rise to the top. If you color-code your stickies for stakeholders versus customers, you can overlap the two to see where connections exist between these two viewpoints. This helps you understand what’s most important to both stakeholders and customers for the product to succeed.”

Viewpoints for Design Reviews

Q: From what viewpoints should we review designs?—from a UXmatters reader

“When reviewing designs, looking at them from both users’ role-based viewpoints, as well as the viewpoint of the larger business enterprise is best,” answers Baruch. “Looking at a design from a user’s perspective means determining whether the design fits the users’ task and experience goals. From an enterprise perspective, assess whether the design meets the goals that the business is trying to achieve. Or do the features of the design just copy what competitors are doing in the marketplace. You need to think about the perspective of the people who are actually building the product, too. If the design would take a long time to build or the product would be difficult to maintain, does that negate the design solution? Would a different design work just as well and be more cost effective?”

“Read Adam Connor’s book Discussing Design: Improving Communication and Collaboration Through Critique,” recommends Pabini.

Start with One User’s Story

“I’ve found that we get much better results when we start with the story of a particular user and keep that firmly in mind when starting a design review,” replies Caroline. “If you’ve got a set of well-researched personas, each person participating in the review can pick a persona as their starting point. If not, make up a story—noting the assumptions you’re making—so you can research the story to follow up after the review. Surprisingly, having a very specific user in mind actually helps you to get a wider variety of insights than trying to think of some amorphous everyone.”

Keep the Perspectives of Both the Users and the Company in Mind

“It’s important that you review designs from both the viewpoints of the primary user groups and from the viewpoint of the organization at the same time,” answers Cory. “To learn about the perceptions of the primary user groups, it’s best to involve actual representatives from those groups. Ask them to review and try out the design solution during qualitative research—for example, task-based usability testing. To make sure you consider the viewpoint of the company during design reviews, talk with stakeholders—before the project begins—about their strategy and why the business is creating the product in the first place. Then make sure the designs meet these corporate goals.”

“There are three relevant viewpoint dimensions: stakeholders, layers, and process,” reply Mike and Rick. “Stakeholders can include users, business team members, and the implementation team among others. The users are interested in the utility, usability, and aesthetics of the user interface in each context of use. The business team is interested in achieving the business goals for the project, brand, marketing, and desired outcomes such as profits or market share. The implementation team is interested in the feasibility and complexity of the project. All of these stakeholders need to evaluate the designs themselves rather than a designer’s simply adopting their viewpoints.

“Then you need to consider the different layers of the user interface: information architecture and navigation, page layout, interaction design, and visual design. When evaluating a user interface, it is often helpful to pinpoint what aspects of each layer are causing concern.

“The process viewpoint refers to the audiences for whom you’re creating design documentation: product owners, company executives, developers, quality assurance, and documentation. This aspect of the review doesn’t concern the user interface itself, but rather the appropriateness of the design documentation or design artifact for its intended audience.” 

Product Manager at Tom Sawyer Software

Dallas/Fort Worth, Texas, USA

Janet M. SixDr. Janet M. Six helps companies design easier-to-use products within their financial, time, and technical constraints. For her research in information visualization, Janet was awarded the University of Texas at Dallas Jonsson School of Engineering Computer Science Dissertation of the Year Award. She was also awarded the prestigious IEEE Dallas Section 2003 Outstanding Young Engineer Award. Her work has appeared in the Journal of Graph Algorithms and Applications and the Kluwer International Series in Engineering and Computer Science. The proceedings of conferences on Graph Drawing, Information Visualization, and Algorithm Engineering and Experiments have also included the results of her research. Janet is the Managing Editor of UXmatters.  Read More

Other Columns by Janet M. Six

Other Articles on Requirements Definition

New on UXmatters