Table of Content
Introduction: What is Requirement Gathering?
Requirement Gathering is the first step in the UI/UX process—it is considered the base of the project. A crucial opening step in the product development process, Requirement Gathering brings all involved parties together, both from the UI/UX team and the customer team, to discuss all the project’s goals and details.
This initial stage of a project is about getting the right content and the right amount of content so the UI/UX process will be developed correctly and will result in a successful product. Getting the right content is all about asking the right questions and speaking to the right stakeholders.
Types of Requirements
In Requirement Gathering, a wide choice of methods and documentation options can be used to obtain the most accurate information about a proposed product. If you are a designer, we hope this post helps you learn to ask the right questions in order to obtain all the necessary and correct information for your project. If you are a customer or a product manager, we hope this post assists and encourages you to gather all the needed information for your design team so everyone will understand the most appropriate approach to your project.
But where to start? First, consider developing a list of all the possible requirements a customer could expect. These may include:
Product Requirements
Product Requirements refers to all the definitions and descriptions of product features and functionality. Following is a set of questions that may help you best obtain a full understanding of product requirements:
- What will the product do?
- What is the product’s main functionality?
- What other actions should the product perform?
- How many sections does the product have?
- How many parameters?
- How does each parameter work?
- Does your product require maintenance?
- Does your product contain replaceable parts?
User Requirements
User Requirements refers to information about and classification of possible users. Developing this level of understanding about users involves an investigation into their lifestyle, the current products they use, their expectations, use conditions, and more. Getting users to engage with a product is the ultimate UI/UX goal—that’s why it is essential to gather all the right information about users in order to most effectively satisfy their needs. Following is a set of questions that may help you develop an accurate understanding of user requirements:
Regarding the user:
- Who will be the primary user of the product?
- What is the age range for the user?
- Where does the user live?
- How does the user live (lifestyle)?
- What are the user’s everyday life activities?
- What are the user’s interests?
Regarding the user’s relationship with the product:
- How will the user interact with the product?
- What need will the product satisfy for the user?
- How is the user currently satisfying this need?
- How much will the user be willing to spend on the product?
Business Requirements
Business Requirements refers to all aspects of a project that fall outside the actual product and user, such as timeline, branding, business goals, marketing goals, sales goals, competitors, customer service, etc. Although not specifically related to design, Business Requirements often include aspects that will be of interest and concern to product designers.
For example, branding decisions must be represented in product design. With no defined branding, design teams can encounter definition problems relating to how a product should look and/or what it should communicate. For this reason, it is vital to gather all possible information about what the business team expects from the product. (For more information about branding, read our blog post entitled “Essential Branding Rules for Mobile Apps in 2020.”)
The product timeline is also significant since it will mark important deadlines for design and development. Establishing a successful strategy to evaluate all the possible features of a product within the allotted time frame is essential, both to define the product as well as to ensure that expectations are met, from the product perspective as well as the customer’s perspective.
Following is a set of questions that may help you best determine the business requirements:
Regarding branding:
- What branding should the product have?
- Is the branding shared?
- Does the product have an independent branding?
- Is the branding adaptable to the product?
Regarding competitors:
- What is the main competitor for the product?
- What are the secondary competitors?
- What is the main competitor’s differentiator?
- What is the differentiator of the proposed product vs. all competitors?
Regarding sales and marketing:
- How will the product be sold?
- How will it be advertised?
Regarding customer service:
- What problems could the user encounter with the product?
- How can the user solve these problems?
- What channels are available for the user to seek customer service?
Regarding other stakeholders:
- What other stakeholders will be interacting with this product?
- How will these stakeholders interact with the product?
Technical Requirements
Technical Requirements refers to all the specifications about where and how the product will work. Technical Requirements are different from product requirements. While product requirements define only the desired actions of the product, the Technical Requirements include the specifications which define the implementation of those desired actions.
Following is a set of questions that may help you best determine the technical requirements:
Regarding platforms and devices:
- In which operating system will the product be developed?
(iOS, Android, Windows, etc.) - Which devices will the product need?
(mobile, tablet, wearables, desktop, specific, etc.) - Are there any limitations for the product with regard to technology?
To develop technical requirements, a Technical Lead must be advising the product team. In most cases, a software developer/specialist can best contribute to gathering technical knowledge.
Deliverables
Once requirement gathering for a proposed product is complete and the project has been defined, the information must be documented correctly. Documentation can be handled either by the UI/UX team or by the product management team. Documentation is often tedious, but it is a necessary process. It is essential to document and organize requirements and deliverables so the information is available for all stakeholders. A system of tracking changes is also necessary. Ensure that your method of documentation allows you to identify changes in the requirements, from old to new, as the project evolves.
User Stories
User Stories are tools commonly used in agile methodologies. The focus is to describe and develop short summaries of actions that users may need to perform. User stories answer questions such as:
- Who will perform the task?
- What does the user need to do?
- Why does the user need to perform this task?
User stories are often first developed in a brainstorming way, using paper and sticky notes. Teams gather and start to come up with all possible user stories for a product. Using sticky notes during this initial stage can be helpful, but it is vital also to formally document user stories, in a trackable file that all stakeholders are allowed to access.
(For more information about user stories and other documenting tools, read our blog post entitled “Understanding Use Cases, Use Case Scenarios, User Stories, and Flow Charts.”)
Personas
Personas refers to a description of fictional individuals who represent a group of potential users. Personas serve to describe each user with a set of specific characteristics that a product’s actual “users of interest” have. All aspects of personas must be based on user research findings.
Personas help a product’s development team and stakeholders better understand the users’ needs, their environments, and how users interact with products.
Another practice involves creating different types of personas based on the different kinds of actual users. Sometimes a product will have more than one type of user, so it is crucial to define the characteristics of each.
Task Flows
Task Flows are diagrams that show all possible scenarios that a user will encounter while using a product. It is essential to define task flows from a requirement perspective, noting where the user will face a decision, how many possible choices the user has to consider, and the details of the outcomes of each possible decision.
Surveys
Surveys are collections of questions designed to obtain specific data. For the UI/UX process, surveys help gather qualitative and quantitative information about product and users. Careful planning of survey questions is essential; they must be clear and direct. Questions with specific answers (such as single-choice or multiple-choice) often result in more precise information than that gathered through open-answer questions. New technologies now offer more accessible ways to create surveys, have them sent to many users, and receive live feedback with data analysis.
Style Guides
Style Guides are forms of documentation that describe a design’s specific characteristics, such as branding, colors, fonts, shapes, etc. Style guides are crucial in the requirement gathering process in order to determine certain aspects of a product’s appearance. There are different types of style guides with different focuses:
Branding: A branding style guide contains information about fonts, colors, logo restrictions, etc.
UI/UX: A UI/UX style guide defines deeper aspects of a product, such as components, menus, texts, placements within the screen, etc. When designing an already-developed product, it is essential to maintain the same graphic style and communication.
Marketing: A marketing style guide approaches a product from a communication point of view, describing how to place elements, photos, and illustrations, as well as defining what type of components should or shouldn’t be used in communication.
Specs
Specs are form of documentation that lists specific information or instructions on how to accomplish a particular task. This type of documentation defines a product’s technical and functional aspects, such as parameters and their characteristics, modes, states, feature specifications, etc. When writing a spec, it is vital to define and provide detailed specifications for each topic.
For example, when considering parameters, a number of questions must be answered. To name a few: What type of parameter is being discussed? Is the parameter editable or not editable? Does the parameter have a minimum and maximum limit? Can the parameter allow errors? How does the user set the parameter? Does the parameter have a range of frequency?
Also, when discussing modes or states, for example, it is essential to define what each state means, what implications it has for the product and the user, what behaviors change within each state or mode, what combination of ways and conditions the user may encounter, etc.
Specs can also describe feature specifications, such as what parameters each feature presents as well as the features’ wizards, table settings, or processes, etc.
Manuals
Manuals are used in requirement gathering when working with a product that has already been fully developed. Product manuals can be written from different perspectives:
Technical: A technical manual is written for technicians, installers, etc. Technical manuals offer more detailed and advanced information on electronics or advanced settings of the product.
User: A user manual is written for regular users/customers. User manuals offer information about the common usage of a product, how to use it, and when to use it. These manuals also provide warnings and restrictions, advising the product owner.
