Versions Compared

Version Old Version 20 New Version 21
Changes made by

Astrid Decrop

Astrid Decrop

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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]."
View user stories documentation.

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:

  • High-level design considerations: ensure the design addresses essential aspects like accessibility (e.g. WCAG compliance), responsive design across devices, and user-friendly flows.

  • Constraints: incorporate typical design limitations such as platform restrictions, technical limitations, or business needs.

Deliverables & success metrics

Define the expected design outputs and how success will be measured.

  • Deliverables: provide wireframes, hi-fi prototypes, interaction documentation, and final assets.

  • Success metrics: example include an increase in transaction completion rate or improved usability scores from user testing.

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.

...