Design & System requirements template

Documentation Type
Last updated
Mar 13, 2023 6:01 AM
Research Type
This document aims to summarise the findings in this current stage of the research and to provide guidelines for the design based on this research.

📝 Summary

Research done at this stage

  • list your research methods that you have performed up untill this stage
  • blabla

Summary: [research method]

Copy paste the summary from your previous research methods in here. Repeat: a summary, so a brief statement of the findings/conclusions that you need for the requirements. Repeat this chapter for all the research methods listed above.

👂 Design & System requirements

By triangulating these findings, design requirements can be created for the designer and the developers on the project. Design Requirements: aim to give goals for the design to the designer, without coming up with solutions for the designer. System Requirements: aim to inform the developer of the system needs in order to fulfil the design requirements and user needs.

These requirements will be presented in a table below.

Explanation of the table

The table has several columns which will be explained below.


The connected research to this requirement will be displayed for better understanding and links are added to the process pages in case the designer/developer needs more information. The research has been triangulated and that data has been added here to ensure validity for the design process.


These are split into 2 options: needs for the user (for the designer) and needs for the system (for the developer). As you can see they both have a different colour marking to ensure readability for the right person. Both are needed to be looked at to decide what is in or out of scope for this project. When speaking of the user we mean the user of our product and when speaking of the system we mean the product. System needs should be discussed with technical based off of the design. This responsibility falls under the designer and PM.


The scope section will be filled in in cooperation with the product manager of the project as they decide which requirements become part of this project and which ones are for future projects. Decide if a requirement is 🟢 in or 🔴 out of scope. And add whether or not 🟠 the requirement already exists (or partially exists) in the product.

  • 🟢 in scope
  • 🔴 out of scope
  • 🟠 already in product

Order of importance

This gets filled in by the product manager of the project as well. They will decide which of these requirements needs to be fulfilled first. This will help the designer & developer decide where to focus when doing the redesign/development.

If you’d like an example of a filled in table used in a project, check out the insurance workflow requirements:

Design Requirement
System Requirements
In Scope?
Already exists?
Order of importance
[topic name] give the topic of this row a name
copy paste the research belonging to this topic here
write down: the user needs to ….
write down; the system needs to…
🟢 or 🔴
🟠 (+ explain where, and/or what parts)
PM numbers these requirements in order of importance.