Eliciting Business Requirements

Ask UXmatters

Get expert answers

A column by Janet M. Six
April 23, 2019

In this edition of Ask UXmatters, our expert panel discusses how to elicit business requirements, whose fulfillment is just as essential to a product or organization’s success as fulfilling user requirements. Our experts suggest some approaches for discerning and understanding business strategy, as well as for eliciting and defining specific product or service requirements.

To understand business strategy and requirements, our expert panel recommends talking with many stakeholders—both one on one and in groups. Our experts also suggest some explicit questions that you should ask stakeholders and specific learnings to explore—for example, to understand the competitive landscape. Depending on your work context, key people you might work with in eliciting and defining product or service requirements could include product managers or business analysts.

Champion Advertisement
Continue Reading…


Every month, in my column 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 month’s edition of Ask UXmatters:

  • Sarah Doody—User Experience Designer; Product Consultant; Creator of The UX Notebook
  • Leo Frishberg—Senior Manager, User Experience, at Home Depot Quote Center, and Principal at Phase II
  • Pabini Gabriel-Petit—Principal Consultant at Strategic UX; Publisher, Editor in Chief, and columnist at UXmatters; Founding Director of Interaction Design Association (IxDA)
  • Peter Hornsby—Director at Edgerton Riley; UXmatters columnist
  • Jordan Julien—Founder of Hostile Sheep Research & Design
  • Cory Lebson—Principal Consultant at Lebsontech; Past President, User Experience Professionals’ Association (UXPA); author of The UX Careers Handbook
  • Daniel Szuc—Principal and Cofounder of Apogee Usability Asia Ltd.
  • Jo Wong—Principal and Cofounder of Apogee Usability Asia Ltd

Q: What are some effective ways to source business requirements?—from a UXmatters reader

“To create a successful design solution, you need to understand both the high-level, strategic, business context and requirements for a product you’re working on, as well as the specific product requirements for a particular version of that product,” advises Pabini.

Understanding the Business Context

“This is a very broad question,” notes Leo. “But I’ll make some assumptions to narrow it down. I’m going to assume that you’re a member of a team comprising both technologists and businesspeople—for example, product managers or business analysts. Clearly, if your team includes business-oriented individuals, you should rely on their expertise and engage them to identify and advocate for the business.

“But perhaps you’re a team of one or your business folks aren’t as connected to the customer environment as you’d like. I’d recommend your getting a copy of the book Pragmatic Marketing: The Product Management and Marketing Authority. It offers a mature approach to capturing business requirements from many available sources. In brief, you should look at things such as the following:

  • competitive landscape—What is the competition doing and how should your offering differentiate itself?
  • customer landscape—What are your target customers’ needs—these could be companies—as opposed to user needs? What gaps could your offering fill?
  • user landscape—What are your actual users’ needs—whether they’re users working within an enterprise for a customer or individual users? What capabilities would improve their ability to get their jobs done?
  • technical debt—What is slowing down your company’s ability to get to the next big thing? How much investment would be necessary to overcome the anchors inherent in legacy code?
  • internal strategies—Who in your organization is driving current initiatives and what are their needs—political or otherwise?
  • problem pervasiveness versus profitability—Ultimately, the business requirements must identify and address key opportunities for the company to make money, as well as addressing existing issues.”

“I’d like to add UX debt to Leo’s excellent list of business concerns,” contributes Pabini. “Unless you’re working for a startup that has made UX design a high priority from the beginning so doesn’t have UX debt, it is essential that you include remedying UX debt in your business requirements. Otherwise, your company won’t ever achieve stellar experience outcomes and, thus, would be vulnerable to competitors’ taking over their niche in the marketplace. Today, a product’s user experience can still be a key differentiator in the marketplace for some domains—especially for enterprise products—but delivering an excellent user experience is rapidly becoming table stakes.”


“This question goes beyond just the sources,” acknowledges Leo. “How can you effectively obtain and leverage these data sources? Again, your Product Management team is usually skilled in the art of obtaining business information. But here are some ways for you to go about getting this information yourself:

  • third-party research—Companies such as Forrester and McKinsey provide broad market-trend information for your customer space.
  • direct interviews with key decision makers in your customer base—These are pretty straightforward interviews that let you identify what keeps customers up at night.
  • interviews with internal stakeholders—These let you identify what’s keeping your internal folks up at night.
  • social media and Internet surfing—Look at competitive products and your competition’s resources. Listen in on discussions that are going on in public. Capture what appear to be painpoints and strategic messaging.”

Have Conversations with Stakeholders

“The most effective method of sourcing business requirements is through conversations,” says Sarah. “Do stakeholder interviews, preferably in a group, then one on one. The group dynamic lets you see where there might be disagreements or lack of clarity across the team. Then, in individual conversations, you can follow up to understand the whys behind people’s viewpoints. Some people may be more comfortable sharing their concerns away from the group.”

“The most effective way is simply to speak with and learn from people in the business,” agree Dan and Jo. “This means finding stakeholders who understand the business they’re in, the products and services they offer, and who their customers are. It’s best to speak with and learn from a range of people within an organization. They can provide multiple perspectives and help you to gain clarity on both business problems and opportunities—historically, now, and in the future.

“When conducting stakeholder interviews, consider the range of questions you might want to ask—covering categories that include problems, opportunities, customer voice, channels, and customer interactions. Consider how the answers can help provide clarity. Focus on what needs improvement, as well as new things you should work on. You should also look for existing research and data on both the customers and the marketplace to gain context on how to position your offering.

“Unfortunately, business requirements are often poorly sourced or poorly translated. They rarely consider customer or user needs. This implies that the ways people are currently sourcing business requirements are ineffective—neither good enough, nor happening iteratively on a regular basis or in a repeatable way.

“Ultimately, you should aim for a diverse set of team conversations to better understand business requirements, including conversations with Product Management, Marketing and Communications, Technology, Design, and perhaps others. Each of these functions should consider their own practices and their intersections with the practices of other disciplines to create an environment in which they can make meaningful work. This enhances opportunities for gaining clarity and focusing on what the business is offering to customers and why. You should increase your focus on meaning and reduce the waste inherent in focusing on everything else.”

“In Jim Ross’s Practical Usability column ‘Understanding Stakeholders Through Research,’ he describes how to conduct stakeholder research.

Eliciting Product Requirements

Here is Cory’s basic process for eliciting product requirements:

  • Step 1: “Talk with high-level stakeholders to understand the needs of the business.”
  • Step 2: “Conduct research with actual or representative users to fully understand both what users want and what they really need.”
  • Step 3: “Fit these two puzzle pieces together in a way that leads to a successful product and business, as well as happy users.”

Working with a Product Manager

“If you’re designing products for users who are also your customers or work for your customers, your partner in defining product requirements is likely to be a product manager (PM),” answers Pabini. “I’ve spent almost my entire career working on products.

“My article ‘Sharing Ownership of UX,’ explored the relationships between the key roles on a product team in depth, including the role of the product manager. Since writing that article, I’ve taken a more and more active role in defining product requirements, writing user stories collaboratively with a product manager or even an entire product team.

In my article ‘Design Is a Process, Not a Methodology,’ I describe, in great depth, step 4 of my design process: eliciting and defining clear product requirements. My article ‘The Role of Constraints in Design Innovation’ takes another perspective on defining requirements, in the form of technical, business, and design constraints. We published a previous edition of Ask UXmatters on ‘Defining Clear Product Requirements,’ to which both Cory Lebson and I contributed, along with Baruch Sachs and Jeremy Wilt.” Another edition of Ask UXmatters considered ‘The Best Ways to Prioritize Products and Features.’

“Other UXmatters authors have written about working with product managers to define requirements. Tal Bloom’s article ‘Triangulation: Navigating the Stormy Seas of Project Requirements’ discusses a unique and very useful approach to defining requirements. In his series ‘Agile Manifesto for Product Management,’ Part 1 and Part 2, Andrew Micallef explores agile requirements definition in depth.

Working with a Good Business Analyst

“In contrast, if you’re working within an enterprise and designing applications and services for internal use, your partner in defining business requirements is likely to be a business analyst (BA),” suggests Pabini.

“Good business analysts are worth their weight in gold,” commends Peter. “If you have the pleasure of working with them, love them. Cherish them. Be their friend. The BA is one of the key people with whom you need to work closely. However, from the tone of your question, I’m going to assume that you’re working in an environment where you don’t have a BA available. In that case, consider putting the requirements together yourself. Doing so offers several benefits:

  • You get a set of requirements to work to!
  • You get to spend time with businesspeople so you can understand their needs and what their priorities are!
  • You get to build relationships with decision makers!

“After working in organizations with no BAs, I ended up training as a business analyst myself and using this skillset to complement my UX work. Doing this is something I can thoroughly recommend. It really is a hugely complementary skillset.”

The Business Requirements Document

“Business analysts often document business requirements in a ‘Business Requirements Document’ (BRD),” replies Jordan. “Typically, the business analyst owns the BRD and adds and refines requirements as the project moves forward. However, in some situations, there won’t be a business analyst, so responsibility for requirements gathering might fall on your shoulders. In such cases, I like to approach business-requirements gathering similarly to the gathering of user requirements—that is, by doing one-on-one interviews.

“The Discovery phase of most projects ends with a team meeting or workshop for discussing all of the requirements that the team has identified. Use some type of prioritization exercise to help you decide which requirements should make it into the next release and which requirements should wait for a future release. There should be a balance between business requirements and user requirements.

“It’s important to note that business professionals often have as much difficulty articulating requirements as users do. In fact, business stakeholders often have latent requirements. They may not even realize these requirements exist. It’s up to a professional analyst or user researcher to tactfully discover any hidden or unmet requirements.”

User Stories

“These days, in agile-development contexts, teams typically document product requirements as user stories,” answers Pabini. “Because user stories focus on meeting users’ needs, this method of defining product requirements is very compatible with user-centered design. Defining user stories is typically an activity that involves the entire product team, so you’ll be able to take an active role in their definition, allowing you to ensure that product requirements take user-research findings into account.

“In the edition of Ask UXmatters titled ‘Agile User Experience Design,’ I describe how to write user stories.” 

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.  Read More

Other Columns by Janet M. Six

Other Articles on Requirements

New on UXmatters