Gathering requirements: defining scope and direction

Gathering requirements is a bit like a checklist of all the things your solution needs to do or be. It’s a key document where everyone can see what the project is, what the problem is and how they hope to solve it. It involves a lot of research, lots of interviews and reading – aside from lots of writing things down.

But why is gathering requirements so important? What’s the gathering process like? Who should participate? Read on as we discuss a crucial effort that starts by a simple conversation with the client, and ends with a realistic prototype that represents your requirements in all their glory. Somewhere between these two extremes sides of the spectrum, you’ll find the need for things like MVPs and low-fidelity representations of the design.

In general terms, the act of gathering requirements is basically putting together a list of things your product needs to do. These requirements can have very different backgrounds, which is expected from a multi-faceted product.

What we mean by that is that you’ll encounter design requirements and business requirements in the same product, because every single product out there needs to worry about more than the design of things. How will your product make money? What are the technical requirements of your product? Do these technicalities affect the general design or chosen features?

In gathering your requirements, you effectively ask the question of “what does my product need?”. This can seem like an easy question for a newbie, but you may be surprised to find that gathering requirements properly can be challenging. Mainly, because it involves many different people (from designers and engineers to developers and business analysts) and a multitude of points of view.

One of the biggest challenges in gathering requirements is that it doesn’t just need input from many backgrounds, but it also represents your knowledge about the user needs the product will cover. The requirements are a representation of what you know regarding the user and what the stakeholders want from the product – which means there’s a considerable amount of research due even before any requirements can be added to your list.

The great thing? Precisely because you need different team members to give their input, your requirements can shed new light on the product and change the way you see the design. It makes for a complete view of the product, laying all the main characteristics bare for the team. Let’s take a look at how we can gather our requirements on a more practical note.

So, how does one gather requirements, exactly? Generally, the process is closely related to the definition of a problem which we aim to solve – and goes all the way until prototyping ideas.

Firstly, you want to understand the general terms of the project as a whole. For the client, what is the main goal here? Has the client tried to create this solution before? If so, why do they think it failed? Does the client already have an idea for what problem the product will solve?

It’s important to cover the basics early, so you and the client have plenty of time to get on the same page. You want to not just know what the client’s goal is – but you want to make sure you understand what the client wants and needs from the project as a whole.

It can be complex to give a one-size-fits-all recipe for gathering requirements, because each design team has their own way of doing things. And that is ok because in UX, most processes can be modified and adapted to suit the team in question. At this stage, the main idea is to understand what the client wants. With that said, take the information that is given to you with a grain of salt.

All of this initial information is very valuable, but don’t think that any of it is set in stone. Over time, it’s possible that the details may change as you develop the project and discover new aspects of the solution. Other times, a little research may change the way you look at the problem the solution needs to solve, which is likely to change the solution itself.

All products deal with some sort of process on behalf of the client. What is the step-by-step process of any purchase made by clients? You want to understand how the client’s business operates so you can create a solution that adapts to it nicely, which is crucial in avoiding chaos when the solution goes online.

Making it visual can be super helpful, especially to a visually-oriented group like UX designers. Seeing each step on the client’s process can help the team understand how things are done and how they can reflect this process in the design itself. It’s important here to not just try to understand what the client wants, but also how the client’s business works.

Once you have all the previously mentioned information, you want to put it down in a way that is organized and within reach of anyone in your team. Remember that these requirements will be your guide, map, goals and objectives. This isn’t the kind of thing you can leave to a selected few – you want everybody to be able to refer back to this document.

It’s also very important that you write down everything. When encountering a brand new project, a completely new brand and market situation, you can’t leave anything to memory. As we’ll see later on, many of the methods for gathering requirements at this point will include interviews with the client and with users, questionnaires, surveys and a general gathering of information. That’s why you want to have a well categorized and organized requirements document. It will be an encyclopedia on the product, client, project and the context around it all.

Once it’s all written down, it’s time to take a close look at the requirements and try to expand your knowledge on them even further. You want to make sure you keep communication with the client open, as you and your team will have more questions as the project develops and it’s important that these questions are answered.

As your team starts to get a better idea of what the product will look like and do, we recommend you engage in some serious user research. Keep the information that the client gave you close at hand, but always be diligent in your research. You want to validate that the problem the client defined is indeed worth solving and validate the definition of the problem itself.

You want to double check that the definition of the target user is relevant and start to understand users. This is the part where gathering requirements becomes a close partner of user research, where you start to learn more about the people who will use your product. This learning process can impact the requirements you end up including on your list, as you get a better idea of what checkboxes you need to tick with your design.

We always recommend going all out with user research. This is the time to take out the big guns like mental models, user journeys, user personas and any other tools that can shed some light on what the user needs and wants.

Once you have design requirements, it’s important to share them with all the stakeholders and different parts of the team. For example, the initial requirements we got from the client might have made some technical needs clear to the engineering and development department. The newly added design requirements also have technical implications that lead to more engineering requirements – that is ok.

Feel free to check out this post and discover some powerful presentation techniques for sharing your work with stakeholders in the best possible way.

You want your requirements to be well-organized, so everyone can appreciate that it gives a complete overview of the product. It’s helpful to have the connection between technical requirements and the other requirements that led to the technical needs, so that the client can understand the jump in requirements. This is mainly because the links between requirements can be tricky to understand to a person that doesn’t participate in the UX industry.

All these requirements are meant to define what the final solution will feel and look like. All of it is meant to help you and your team create a prototype that can translate all these requirements into something tangible, something concrete.

At this stage is when a key concept comes into play: requirements gathering, much like user testing and prototyping in general, isn’t a linear process. Just like when you carry out your usability testing and iteration after iteration ultimately leads you to the final design, so too will your requirements and prototyping work together to show you the way. Starting with design in its simplest form, the team will create a paper prototype and work their way up to a more refined design.

The role of prototyping in requirements gathering is paramount. A common mistake is leaving the overall requirements to the imagination of stakeholders until late in the product’s development process. Even early on, when you first start to understand the client’s requirements, making a prototype might add some serious value to the project.

If you’re looking to learn more about other forms of digital design, why not check out our guide to dashboard design?

Logically, you won’t be able to change your requirements as easily as one changes colors in button states.

That’s why there’s a certain balance between your stability in having the same requirements for the entire project and your flexibility to adapt to change if you need to. At first, your requirements will be fluid as you discover the specifics of the project. After that, changes will be less likely as you validate your decisions and advance in the prototyping of the solution. Remember, having a professional prototyping tool for this is a bare necessity!

When it comes to gathering requirements, it’s mostly about increasing your understanding of the solution, situation, client and user. Doing a lot of research online can be a handy way to understand the sector and industry the client is in, but it won’t help you understand the inner dynamics of the client’s company.

Depending on what you’re designing, you may need true knowledge about how things are done in the company and how they do business with users. For that, you’ll need to get real close to clients.

This may be the easiest form of requirements management. Many design teams use questionnaires at first, in order to get some context before sitting down with the client to discuss basic things like project goals and requirements.

This can be a good way to get some essential information like the sector the brand operates in and the main issue they’d like to tackle. This can be a great introduction to the client, so you enter the face-to-face meeting with some previous knowledge about who the client is, what they do and what they want.

There are some debates as to making these forms long and complete or short and easy. This is a matter of preference that changes from design team to design team, and there are some great arguments for both sides. On the one hand, you have more useful information that will make that meeting more fruitful and efficient. On the other hand, you have an easy form that won’t discourage potential clients from getting to that crucial first meeting.

Surveys and forms can also be a handy way to gather lots of data on users. Just like they can help introduce the clients, they can help you understand basic traits of users – making them a very handy method to gather requirements.

This is by far the most important and telling of the requirements gathering methods. At the end of the day, no other method is going to live up to a conversation with the client. The chance to ask questions freely and get a feel of the client’s needs and wants can be illuminating to you and to your team.

Chances are, you’ll need more than one interview with the client. You’re better off going all out, meeting and interviewing more team members in the client’s company. The fact is, trying to understand the client’s company and problem is key – it’s the rock the solution is built on. You want to dedicate as much time and effort as necessary to get it right.

The same applies to observation. Observing a day or two in the shoes of the people who work in the company can show us some of their pain points, workarounds, and day-to-day tasks. In fact, observation can go on for more than a single day depending on how complex the problem and corresponding solution might be.

With both interviews and observation sessions, be it with clients or users as we test the solution ideas, writing things down is very important. You want to register the answers, reactions, context. You want to gather and identify all the pieces of the puzzle before your and your team can begin putting it all together. Remember that documentation is crucial for your requirements gathering.

This can be a good way to get input from every relevant department. How exactly teams approach brainstorming can vary from team to team, with varying degrees of structure and freedom to add ideas. Some teams prefer to structure the conversation so they have a little more focus while others simply have a blank board as a starting point.

This can be a great way to get your team members discussing and debating on what the base requirements are, what they mean and what the consequences of each requirement might be. Besides getting a little deeper into the meaning and consequence of each requirement, it’s very helpful to have everyone in the same room, covering the different aspects of the product.

We’ll take a look at the specific roles within the team and all the different sides that their input covers. But for now, suffice to say that having designers and developers or engineers in the same room discussing the same requirements will lead to a more refined and realistic set of requirements.

Use cases are basically hypothetical situations that take place when the user is interacting with the product. These tend to be very contextual and are all about the situation the user finds themself in.

Scenarios are a similar tool that tend to be used together with use cases. Take the following example: the use case is a user trying to log in to your product. The use scenarios are that the user successfully logs in or there is some sort of error that prevents the user from logging in.

Together, these can help the design team cover ground in making sure the product works correctly and that the experience is up to our standards. It’s ideal to go for a wireframe tool that allows you to put the scenarios and the actual product in the same place!

Business analysts play a key role in gathering requirements. They are all about making sure the project has realistic business goals and enjoys the necessary means to get there.

These are the folk that will tell us about business competitors and the market, as well as shed light on the business model the product is for. Moreover, these are also the guys that make sure the product is profitable, ensuring some way of monetizing all this effort at the end. Needless to say that they are vital in making a project that can stay afloat.

PMs are the general rules of the project. They will keep a close contact with business analysts and the client as well as other key stakeholders. The Product Manager may or may not engage in some design – the exact scope of the PM’s job can vary from company to company.

One thing that doesn’t change, though, is that the PM is the person holding the control. The PM is the person that ensures deadlines are met, oversees resources and efforts, handles upcoming problems and allocates tasks among the team. It’s a pretty important job, as the PM can be considered the captain that makes sure the ship stays on-course.

Designers are the soul of the team. These are the people that will take abstract ideas and concepts and put them down, making them tangible. The creative work is absolutely crucial to the project, not just in terms of visuals but also of more important aspects of the product, like the interaction and navigation design.

Designers can vary from company to company. Large companies can have a UX designer, a UI designer and an Interaction designer, all in the same team. Smaller companies are likely to have a couple of designers that cover all aspects of the design.

Either way, your UX designers will be the people who look at the initial requirements and can add a few more that represent the design needs for the product. More and more checkboxes will be added to your list by your designers as they start to go from a mere concept into a more defined idea of the final solution. You definitely can’t make do without these guys!

The technical side of your product is just as important as the business or design aspects. Your engineers and developers are meant to be in the same room as everyone else in your team, because they’re the ones who can tell us what we need to be able to deliver the design.

While PMs and designers can marvel at a brand new requirement for the solution, engineers are the ones who tell us if a solution like that is even technologically possible. They add a necessary point of view to the requirements that represents the more practical and scientific side of requirements.

Gathering requirements for a brand new UX project is a process that can take time and effort, but is a non-negotiable. No matter the brand or industry, design teams need direction – they need to know what they’re aiming for. That is the role of the requirements: it gives you scope, limitations, definitions and goals.

As a crucial step in any project, you want to make sure you take the time to validate the initial requirements you get from the client. Make sure you and your team understand the client and the struggles they aim to solve with the product, before you start trying to understand the users themselves. Documentation, made with care and with plenty of input from everyone, is key.