Introduction to requirements gathering
Requirements Gathering is without a doubt one of the most important processes in UI/UX design and development. It is a process that involves gathering information from users (or potential users) and stakeholders of your website, product or application.
In terms of the nuts and bolts – you are simply trying to find out what each and every concerned party expects from the outcome.
It’s not hard to imagine that when collecting this information from the relevant stakeholders – that various output measures from people can differ… for example the interests and expectations of investors may be very different from that of designers and developers.
In fact, the expectations of these different groups can sometimes be in conflict with one another. As a result, UI/UX designers and developers often find themselves trying to balance conflicting interests and messaging of different parties.
One of the reasons requirements gathering is essential is that extracting such important data from these stakeholders helps UI/UX designers and developers to bring to life informed data-driven designs that actually satisfy a set of criteria-driven expectations (or requirements) of all parties involved.
In other words, requirements gathering helps result in building a map that gives the UI/UX design and development team the relevant direction it needs – and sometimes even more importantly what needs to be avoided during the design and build phases of the project.
Another important note here is that the requirements gathering process often involves extensive data research. That means lots of interviews, surveys, use case scenarios and more!
Typical groups involved in the process
Taking a deeper look into requirements gathering it’s important to look at some of the various groups whose expectations (or requirements) may need to be met, why it would be important to try to meet these expectations and the typical process involved in gathering this information. It is also helpful to look at a simplified example when touching on these.
Product Groups – Develop Product Requirements
A really simple functionality breakdown of the product team sees them generally responsible for what the product does, how it functions, how it is to be maintained etc. For a deeper insight, it’s best to simply jump into an example of a product requirement.
IDEA: To build out the initial idea summary we are going to use the that of: ‘Building a Search Engine’
Our over-simplified version of the product requirements would be that this ‘product’ is a webpage containing a search feature – being a search box.
Users can enter search terms into the search box and get a list of search results from the internet that contain the terms entered into the search box. This is the main function of the product.
TASK: Understand the product requirements.
The elementary aspects of the product requirements will probably be the very first thing UI/UX designers and developers would likely want to know.
To get a better understanding of the actual ‘product requirements‘ – UI/UX designers and developers would likely conduct one or more ‘requirements gathering’ interviews with relevant stakeholders – for example, those who came up with the product idea.
UI/UX designers and developers would also be interested in interviewing the initial design and development teams as they likely have hidden gems of data and knowledge around the product and its feature sets.
User Groups – Develop User Requirements
UI/UX designers and developers love users and user data. There would always be a user (or potential user) focus when looking at the website, application or product.
The UI/UX designer and developer would want to know the different kinds (or classifications) of users that are (or would potentially be) interested in this website, application or product and what each of these user classes expects from the experience.
Every website, application or product has a problem (or problems) it should solve. In the minds of those who came up with the idea of the website, application or product, there is a vision of the problem to be solved and how exactly this should be accomplished.
Each potential user expects this to fulfill a need and there are steps they expect to take to get that solution.
IDEA: Continuing our earlier example of a search engine.
Define our User Requirements
The ‘user requirement’ in this case would state the solution this ‘product’ offers
“The search engine helps users find information and web-based resources on the internet”
The ‘user requirements’ would also include the steps to be taken by a potential user who needs these solutions – in this case
- every user would have to visit the search engine on their browser via the URL
- enter their search query when the page loads
- wait a few seconds for the search results to be displayed
- click on any of the links to visit the desired search result.
It must be noted that the ‘user requirements’ described above is a complete oversimplification. The typical UI/UX design project will have ‘user requirements’ that are likely far more complex – even for a simple search engine.
Define our User Classifications
To define the User Classifications a UI/UX designer or developer would need to know the details of each class of potential users. Generally, these details include factors such as:
- age range,
- lifestyle, and (most importantly)
- why each particular user class needs the product (the solution it provides for that particular user class).
This last item is important because sometimes a product can offer different solutions for different types of people (for example: why a hunter and a police officer might need a rifle for different reasons).
Other factors that might be included or considered in ‘user requirements’ are:
- How different user types are currently solving various problems the product is being created to solve.
- How much each user type would be prepared to spend for the product.
The process of gathering ‘user requirements’ may also include:
- Using surveys to find out the expectations of the user types that could be interested in the product.
- Interviewing those who came up with the idea for the product.
- Developing ‘user stories’ and ‘personas’.
What do User Stories and Personas Mean?
Personas refer to fictional individuals who have the very same characteristics the website, application or product’s actual users have.
Personas are creations of an imagination that help the UI/UX designers and developers better understand the user’s needs and how they interact with the product.
It is very much like UI/UX designers and developers are putting themselves in the user’s shoes to gain better insights from another perspective.
It must also be stated that the characteristics of each of these Personas are not based on assumptions. Instead, they are based on actual data and research findings.
User Stories are fictional stories that aim to describe all the possible experiences a user of the product may have. Like Personas, User Stories are also creations of an imagination that help UI/UX designers and developers chart a course of events from the moment a fictional user (Persona) is introduced to the website, application or product through to the end of their interaction with the website, application or product – whether or not the user’s needs are met at the end.
If you need to know why a UX’er would go through all this trouble to gather the ‘user requirements’ for a website, application or product – the reason is simple… any website, application or product that fails to meet user requirements is finished!
All stakeholders that have an active interest in the website, application or product – for example: at all levels from:
- Operational (the founders, investors, partners, managers etc.)
- Builders (designers, engineers, technicians etc.)
- Users – the one group you truly cannot afford to disappoint.
While no group can be ignored (eg. no investors = no money) – the one true group that always holds true with no workaround is the user’s group. If you don’t have the users onboard you find the product ALWAYS loses its basis.
Business Groups – Develop Business Requirements
This is where the expectations (or requirements) of all the stakeholders on the business side of things are described. These expectations can include:
- Sales and profit targets may need to be considered in certain aspects of product design.
- Marketing considerations must be made during the design process to align the product to the general marketing strategy.
- Branding requirements determine everything from shapes, fonts, and colors that can and cannot be used in the design of the product and its interface.
- Any other considerations that need to be made from a business perspective could affect the final design of the product.
Still using our previous example, the ‘business requirements‘ for a search engine undergoing UI/UX design and development could include considerations like conversion goals, font, shape and color recommendations for the search engine’s website and app. These might be made to match the style of the existing logo and branding.
The danger of ignoring ‘business requirements’ is that if a product is successfully designed to meet all other requirements but fails to deliver on the business side – then the entire project may end up being put on the shelf.
Methods used in developing ‘business requirements’ remain largely the same however the focus now shifts gear to operational stakeholders. Data gathering is mainly derived from business sources such as founders, investors, partners, managers etc and this is often a different conversation than previously had with people working in product and development.
You will likely be dealing with very busy stakeholders with limited time availability so be prepared, be direct and get ready for high-level and strategic conversation where you will be required to extract the data you need – often a short space of time.
Technical Groups – Develop Technical Requirements
The ‘technical requirements‘ are specifications that describe the inner workings of a product. These could include details such as:
- The software platform that supports the operation of the product.
- Any extra hardware the product needs to function.
- Any minimum regulatory or industry standards that must be met.
- Any other technical detail that could affect the final design of the product and its interface.
‘Technical requirements’ are developed by collaborating closely with those who are familiar with the technical aspect of building and operating the product and those who have an intimate understanding of what happens under the hood.
This is important because in many cases the ‘technical requirements’ help a UI/UX designer and developer stay within the confines of practicality.
Not fully understanding or comprehending ‘technical requirements’ can see design teams end up with designs that are completely impractical — even if they are incredibly powerful, beautiful or user-friendly. This means an end result that can’t move forward to a building phase.
Helpful Tools – Useful For Requirements Gathering
When embarking on your next ‘requirements gathering’ journey – here are some helpful tools that may be needed for the process:
Surveys are used to present questions that can extract some specific data and information. They will likely be needed for the ‘requirements gathering’ process especially when it comes time to gather your ‘user’ based requirements.
Surveys will help discover the general sentiments and opinions of a group of people around a particular issue. This can help UI/UX designers and developers make data-driven decisions that are more in line with the reality of people’s expectations rather than on assumptions.
Task Flows are UI/UX diagrams that show possible scenarios that could be encountered by a user of the website, application or product.
Designing and developing these diagrams make it easier to understand what would ordinarily be a very complex maze of possibilities.
Task Flows chart out possible courses showing how a user could move from one point to another in their interaction with a website, application or product. They also show the different options available to a user at each point in the journey and the outcome of each option.
Documentation with Change Logs
It is important to mention that UI/UX designers and developers undertaking the requirement gathering process should document their findings in a logical and structured manner that makes it accessible to all other parties involved in the development of the product.
Doing this helps to ensure it will serve as a later guide for all involved.
It is also important for this documentation to have a system for tracking the changes in requirements that will inevitably occur as the project evolves. This system will record the changes made and the exact point in the development process when they were made.
A style guide is a carefully prepared document that expresses all the requirements gathered which are visual in nature.
These include requirements that have to do with shapes, sizes, colour, fonts, branding assets, positioning of visual elements etc.
This guide is a collection of every expectation that needs to be considered when utilizing the design of a website, application or product. It must be considered and adhered to when producing anything with visual elements affecting the relevant brand assets, brand marks, appearance or associated interface elements.
When working on a website, application or product that has already been fully developed, manuals are needed that specify the information on how it is to be used and maintained.
Consider when approaching this step there may be different audiences – for example, there are ‘technical manuals’ that deal more with the technical aspects of operating a product and there is the ‘user manual’ that’s written for the average user, who has no relevant technical knowledge.
The UI/UX ‘requirements gathering’ process is an important aspect of UI/UX design and development that precedes every other process involved.
From the very moment a potential client who has conceptualized a product approaches a UI/UX designer or developer the ‘requirements gathering’ process has basically already started.
It’s important to note this process is not restricted to the beginning of a UI/UX design project. It is a continuous process that lasts for as long as a product is under development.
Data is always coming inbound and with multiple stakeholders involved in any given project build you can see how requirements can and do often change at a moment’s notice. Here is where the modern-day user experience designer and developer need to remain agile in their approach.
Above all – the biggest recommendation to leave you on is to keep the quality of your work to a very high standard. Listen more. Dig into the data to uncover the hidden gems. Produce excellent documentation that can be utilized by any team throughout the project and have fun with it.
‘Requirements gathering’ is and should always be a really fun part of the UI/UX design and development process.