blog home

A requirements gathering process that helps solve the right problems

There’s an exorbitant amount of information circulating today regarding design methodologies and processes. Everyone thinks they’ve discovered the secret sauce that will make every project a huge success. 

I’m not here to make such lofty guarantees, but I would like to share with you a method I’ve honed over the years that helps me narrow down requirements and ensure I’m solving the right problems before getting to the design phase of a project. I can’t take credit for coming up with all the pieces on my own, so I’ll be sure to reference designers much smarter than myself as we go along.  

Define Business Goals

Source

Nail Down Terminology

It’s difficult to build a rapport with someone when you’re speaking different languages. Take a beat and get on the same page with acronyms, abbreviations, and proper titles/descriptions. Not only will this help you in discussions with the business leaders, but if you’re able to discuss processes and tasks with the users, knowing what to call things can really help!

Set yourself up for success

When you begin project discussions with a client or stakeholder, start by asking them what they hope to accomplish. It’s tempting to immediately jump into the weeds and ask specific user-focused questions – but that’s a mistake. Knowing where you’re going will help you avoid scope creep. Stakeholders will inevitably bring up all sorts of wants and needs when you dig deeper, but you’ll be able to stop and remind them that those items won’t get them to their end goal and should be discussed separately. 

TIP: I’ve found it helpful to start a separate document for stakeholder wants/needs that are out of scope. This makes them feel like their voice is being heard, while also allowing you to focus on the matters at hand. If you’re working with a client, it can also be helpful to bring up at the close of a project and sometimes can lead to more work for your team!

Then you’re going to want to discuss the importance of each of their goals, this will really help you with prioritization as well as give you a more in depth understanding of their needs.

Finally, you’ll want to ask them why they want what they want. Understanding why something is necessary can help you flesh out the root cause of the problem you’re supposed to solve. 

5 Why’s Model

“You’ll naturally discover a process or lack thereof by asking “why” a couple of times (you don’t have to exactly ask “why” 5 times). I’ve been able to save our engineering team from working on low-value projects by uncovering customer needs that can be fixed with process or approach rather than developing a new feature.” – from Chuck Liu’s Never Ask What They Want — 3 Better Questions to Ask in User Interviews

source: https://expertprogrammanagement.com/2019/05/the-5-whys/

To summarize, we need to ask business leaders the following:

  • What do you hope to accomplish?
  • What’s important to you?
  • Why?

GET TO KNOW THE USERS 

User Observations

If you have access to the user, then watch them work. One of the most valuable tools in a designer’s arsenal, is observing a user perform a task, rather than have them explain it. 

Think of it this way- if you were asked to explain how to make a PB&J sandwich, you’d likely skip steps that, to you, are obvious. You’d also describe the best case scenario, without accounting for issues. Users do the same thing when they describe a workflow to you.

Some tips for success include-having the user talk you through the entire process step by step. Be sure to ask why they do the things they do as you observe, to help you better understand their motivations and reasoning. This will really help you differentiate vital steps from those specific to the user you’re observing. 

Bottom line- there’s a lot you can learn from watching a task and questions you’ll think to ask during an observation, that you wouldn’t during an explanation.  

Personas

If you don’t have access to the users, you’ll need a detailed persona. It doesn’t have to be pretty, in fact it can be written on scrap paper. Its primary purpose is to help you understand the users your design will serve.  

Ask the right questions

“Whether you are launching a new product, feature or service — asking the right question is like the water that cleans the dusty front window of your car. More questions you ask, clearer the front view becomes.” – from Eugen Esanu’s Top Questions To Ak Before Designing Anything

Sometimes when asked what I do for a living- I reply with “I get paid to ask great questions” – because there are times when I feel like that’s my primary directive. The ability to formulate the right question to the right person is what takes a design from good to great.

Now that you’ve met with business leaders and users, it’s time to take a look at the data and processes you’ve outlined and see where the holes are- go back and ask for more information. 

By this point, it’s important that you have answers to these questions (Liu):

  • What are users trying to accomplish? (Gather context & define goals)
  • What is their current workflow or process?
  • How can the current process be improved? (Find opportunities & identify pain-points)
from Top Questions To Ask Before Designing Anything

Never ask users what they want

While it’s important to ask questions, there are a few you’ll want to avoid, and asking a user what they want is one of them. 

“When you ask a person what they want, you let them think within the realm of possibility. And that makes user research harder than it should be.”  – Chuck Liu

“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.”   – Steve Jobs

Critical Incident Method

“Ask users to recall specific instances in which they faced a particularly difficult case or when something worked particularly well. These extreme cases are often more vivid in users’ minds, and will give you the details needed to come up with useful features.” – from Interviewing Users

Beware the Query Effect

“Whenever you do ask users for their opinions, watch out for the query effect: People can make up an opinion about anything, and they’ll do so if asked. You can thus get users to comment at great length about something that doesn’t matter…If you ask, they’ll answer, even if the topic isn’t important. They won’t tell you it’s not important.” – from Interviewing Users

VALIDATE THE PROBLEMS

After meeting with clients and users, you’ll undoubtedly have a heap of problems to solve. Now’s the time to step back and validate that all of those problems meet the following criteria. 

1. REAL: Ensure the issue actually exists for at least one or more users. We want to solve real problems, not assumed ones.

2. RIGHT: It’s the right problem to solve, and not simply the result of a larger issue.

3. SYSTEMATICALLY SOLVABLE: The problem is best solved systematically with a tool, and not by other means (like a process change).

“Never accept a problem at face value. Instead, try to find what the real problem is — the problem behind the problem” – from Eugen Eşanu

FORMULATE FINDINGS INTO USER GOALS

from Identifying tasks and designing for User Goals

User stories are excellent for defining the scope and priorities and ensuring the end product meets all requirements. But they were designed for developers. For designers, user goals are where the magic happens.  

Let’s use a real world example. As 2019 comes to a close, lots of folks will be making their new year’s resolutions (NYR). When asked what their NYR would be, USER A responded with “I want to lose 50 lbs by June 2020”… Sure sounds like we have a User goal, right? … 

Wrong. Losing 50 lbs is the task USER A wants to complete. Their overall goal is weight management. They want to achieve a healthy weight and keep the pounds off for good. That’s our user goal. 

Now imagine how differently we would design a system that helped someone lose 50 pounds compared to one that helped people maintain a healthy weight. The difference is significant, which is why goals are so powerful.

“Users will not talk in goals. They talk in tasks…One of the biggest challenges in the analysis step is taking all the things that the users tell you and abstracting from this the goals that they are really aiming for.” from Brian McKenna

CONCLUSION

There you have it. I hope you find this article helpful on your next project! I’ve provided some resources below that should prove useful also.

Personas

User Interviews

Further Reading

We use cookies to deliver the best possible experience on our website. To learn more, visit our privacy policy. By continuing to use this site, you consent to our use of cookies.

Accept