Gathering requirements: defining scope and direction

Requirements gathering for your UX design 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 requirements gathering 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 UI 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 requirements gathering 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?

Begin the requirements gathering process by conducting in-depth discussions with the client to uncover their overall goals and expectations. Understand the desired outcomes, the target audience, and the key success metrics that will be used to evaluate the project’s success.

Once you have a clear understanding of the project goals, define the scope of the project. Determine the boundaries and limitations of the project, including the features, functional specifications, and target users. This will help you stay focused on delivering the most valuable aspects of the solution while avoiding scope creep.

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.

Seek their input, address their concerns, and ensure that everyone is aligned with the project’s goals and scope. This will help to build consensus and avoid misunderstandings later in the project.

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.

To gain a comprehensive understanding of the project context, conduct thorough research and gather relevant information. Explore the client’s industry, competitors, and target audience to identify trends, opportunities, and potential challenges.

Analyze existing solutions in the market to understand best practices, identify gaps, and learn from the experiences of others. This will help you benchmark your project and set realistic expectations.

Gather initial input from the client through interviews, workshops, or other appropriate methods. This will provide valuable insights into their specific needs, preferences, and expectations for the project.

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.

Create a comprehensive requirements document that captures all of the gathered information in an organized and accessible format. Use a consistent structure and numbering system to ensure clarity and ease of reference.

Categorize requirements based on their importance, urgency, and alignment with project goals. This will help you focus on the most critical features and avoid scope creep.

Use prioritization techniques like MoSCoW prioritization or Kano analysis to rank requirements. This will help you make informed decisions about which features to include in the initial release and which can be deferred to future iterations.

Involve stakeholders in the prioritization process to ensure that their needs and preferences are reflected in the final product. This will help to build buy-in and ensure that the project delivers value to the target audience.

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 wireframe that can translate all these requirements into something tangible, something concrete.

Start with low-fidelity prototypes to quickly explore different concepts and gather initial feedback. As you refine the design, create more detailed high-fidelity prototypes that closely resemble the final product.

Share prototypes with stakeholders and users to gather their input and identify any potential issues. Use their feedback to iterate on the design and make necessary adjustments to the requirement.

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.

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.

Throughout the requirements management process, make sure to regularly review the document to ensure that it remains accurate and up-to-date. As the project progresses, you may need to update requirements based on new information, changing priorities, or feedback from stakeholders.

Be prepared to iterate on requirements throughout the project lifecycle. Agile methodologies often emphasize iterative development and continuous improvement, allowing for flexibility and adaptation to changing circumstances.

And, as always, in each and every step, remember to collaborate closely with the team to ensure that everyone understands the requirements and is working towards the same goals. This will help to prevent misunderstandings and ensure a smooth development process.

Approval is a crucial step in the requirements gathering process, ensuring that all key stakeholders are aligned and committed to the documented and prioritized requirements. It serves as a formal agreement that sets the foundation for the project’s execution.

By obtaining formal approval, you’re not just checking a box; you’re creating a shared commitment among all stakeholders. It’s like signing a contract that outlines the terms and conditions of the project, ensuring everyone is on the same page.

A well-executed approval process offers several benefits. It reduces the risk of misunderstandings, boosts stakeholder buy-in, streamlines the development process, and enhances accountability. It’s like having a clear roadmap that guides your team towards a common goal.

So, don’t treat approval as a mere formality. Invest the time and effort to involve stakeholders, provide clear and concise documentation, and address concerns promptly. A strong approval process is the key to unlocking the full potential of your project.

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, and use the right requirements management techniques to achieve great results.

Traditional methods, often associated with waterfall methodologies, emphasize structured and sequential processes. They focus on detailed documentation and upfront planning, making them well-suited for projects with clear objectives and stable requirements. Interviews, document analysis, and surveys are common techniques within this approach.

Placing the end-user at the center of the requirements-gathering process is essential for creating products that truly meet their needs. Techniques such as user observation, prototyping, and usability testing are employed to ensure that the product aligns with user expectations. By understanding user behaviors, motivations, and pain points, you can develop solutions that truly resonate with your target audience.

Fostering collaboration among all stakeholders is crucial for successful requirements gathering. Workshops, brainstorming sessions, and focus groups provide platforms for open dialogue, idea generation, and consensus building. By involving users, developers, and business analysts in the process, you can ensure that everyone is aligned and committed to the project’s goals.

To uncover deeper insights into user needs and potential product innovations, consider employing creative and unconventional techniques. Design thinking, ethnographic research, and gamification can engage stakeholders in a more immersive and engaging way. These methods can help you uncover hidden needs, identify new opportunities, and foster a culture of innovation.

Agile methodologies prioritize a flexible and collaborative approach to requirements gathering, which differs significantly from the upfront documentation often associated with traditional waterfall models.

This approach emphasizes continuous discovery, active involvement of stakeholders, especially end-users, and the prioritization of requirements based on their value and urgency.

The project is divided into smaller iterations, each with its own set of requirements, and the product backlog is continuously refined through techniques such as user stories, story points, and backlog grooming.

This Agile approach leads to several benefits. First, it increases customer satisfaction by involving stakeholders early and often in the development process.

Second, it reduces risks by allowing for early detection and mitigation through its iterative approach. Third, it improves flexibility by enabling teams to adapt to changing requirements and market conditions.

Finally, it enhances collaboration among team members by fostering a collaborative environment where everyone works together towards common goals.

The general-purpose templates described below can be valuable assets in various software development projects. They aid in visualizing and understanding project requirements, facilitating effective communication with stakeholders, and ensuring the correct design and implementation of software systems.

• Use case diagrams: Visually represent interactions between users and a system.
• User stories: Describe a desired feature or functionality from the user’s perspective.
• Data flow diagrams: Illustrate the flow of data through a system.
• Entity-relationship diagrams: Model the relationships between data entities.
• Context Diagrams: Show the system’s boundaries and interactions with its environment.

The industry-specific templates can aid in adhering to established development methodologies, providing a structured framework for managing complex projects, and ensuring effective collaboration among cross-functional teams.

• Software development life cycle (SDLC) templates: Provide structured guidelines for different phases of software development.
• Agile templates: Support iterative and incremental development methodologies.
• Business analysis Templates: Focus on understanding business needs and processes.

When searching for requirement gathering document templates, the internet offers a wealth of resources. From specialized template libraries to project management tools and online communities, you can find a variety of options to suit your needs.

• Template libraries: Websites like Lucidchart, Draw.io, and Creately offer a vast collection of pre-built templates.
• Project management software: Tools like Jira, Asana, and Trello often include built-in templates for requirements gathering.
• Online communities: Platforms like Reddit and Stack Overflow can provide specific templates or advice based on your project’s domain.

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.