Defining Clear Product Requirements | Viewpoints for Design Reviews

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.”