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
The design brief serves as the foundational overview for the project, outlining the key objectives, constraints, and deliverables. This section 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 /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. |
Align with user stories and acceptance criteria
Ensure that all designs correspond directly to the user stories and acceptance criteria.
Include all user flows and scenarios
Document all user flows, including both happy paths and unhappy paths (errors and exceptions). Provide detailed designs for each flow to prevent ambiguity during development.
Design for all platforms and screen resolutions
Create designs for every platform the product will be used on (e.g., mobile, web) and for all relevant screen resolutions.
We are aiming for consistency and optimisation. This should not be left to engineers to have to work out during the build.
Use clear and consistent visual elements
Maintain consistency in the use of colours, typography, icons, and other visual elements. Adhere to Moniepoint's design system to ensure a cohesive look and feel.
Design UX
Intentionally design UX flows. Again, these should not be left to engineering to have to work out.
Include annotations that explain interactive behaviours, transitions, and any dynamic elements.
Collaborate with developers
Engage with the development team during the design process to validate the feasibility of design decisions.
Collaborating helps identify technical constraints early, and allows for smoother implementation.
Organise the document logically
Structure the design document in a logical order, grouping related screens and flows together. Use clear headings and labels to make navigation and understanding easy for engineers.
Include necessary metadata
Provide essential metadata such as version numbers, dates, and the names of contributors.
0 Comments