Eliciting Business Requirements

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