Design
- Ian Dillon
- Astrid Decrop
Purpose of the design document
The design document (file in Figma) ensures that all design assets, decisions, and flows are clearly structured for a smooth handoff to engineering, and that any stakeholder can quickly understand and navigate the file.
It provides crystal clear design specifications, including all aspects of how the product should look and behave. This includes all happy and unhappy paths across different platforms and screen resolutions.
Leave no room for misinterpretation.
Guidelines for creating the design document
Key principles
Consistency: design files must adhere to a standard structure (coming soon) so that engineers, designers, and other team members can easily navigate the document.
Clarity: all design decisions should be well-documented and components should be labeled according to our naming conventions (WIP).
Completeness: every design handoff should include all necessary assets and specifications, ensuring nothing is missed in the transition to development.
Design brief
Your Figma file should include a dedicated page for the design brief to ensure all team members can easily access the project details, objectives, and acceptance criteria directly within the design file, facilitating clearer communication during the handoff process.
The design brief serves as the foundational overview for the project, outlining the key objectives, constraints, and deliverables. It provides the necessary context for both the design and engineering teams to understand the scope of work.
Name of the project | Clearly state the project’s name for easy identification. This should align with our naming conventions (WIP). |
Problem statement | Define the problem the design is intended to solve. This should be a succinct description of the user’s pain point or the business challenge being addressed. For example, "users are having difficulty navigating the payment flow, leading to a drop in successful transactions." |
User story | The user story provided by the PM (Jira ticket) should be documented here, reflecting the end-user’s need in the format "As a [user type], I want to [goal], so that I can [benefit]." |
Task description | Describe the specific tasks involved in delivering the design solution. This should break down the key steps that the design team will focus on to solve the problem. |
Acceptance criteria | This will primarily be provided by the PM (view acceptance criteria documentation) and sets the conditions that need to be met for the design to be approved. However, designers must also consider additional criteria, including:
|
Deliverables & success metrics | Define the expected design outputs and how success will be measured.
|
Relevant links | Include links to related tickets, product requirement documents, research, or any other documentation essential to the project. This ensures easy navigation for stakeholders reviewing the design. |
Design-to-dev. handoff
Design files: finalised design files that are well-organised, with layers properly named and grouped. All components, screens, and elements are clearly labeled for easy reference by developers.
Each component is built using predefined design tokens, which are referenced throughout the design files. These tokens dictate key properties such as colour, typography, spacing, and more. State variants (e.g., hover, active, disabled) are also specified with their corresponding tokens, allowing developers to replicate these behaviours in code.
Documentation: detailed documentation on how to implement and use the components, patterns, and styles. The documentation includes component usage guidelines and design rationale.
Responsive design: guidelines on how the design should adapt across different screen sizes. These guidelines include specified breakpoints and descriptions of how the layout and components should adjust at each breakpoint (e.g., mobile, tablet, desktop).
Prototypes: interactive prototypes are included to demonstrate the intended user flows.
User flow diagrams: diagrams that map out the entire user journey, including the happy path, unhappy path, edge cases, fallback paths, abandoned paths, and more.