...
Name of the project | Clearly state the project’s name for easy identification. This should align with our /wiki/spaces/DT/pages/1759019078 (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.
Include all user flows and scenarios
...