A design handover should explain the task, states, rules, content and unresolved decisions engineers need to implement the intended experience. Editable frames are useful, but they do not specify validation, authority, asynchronous behaviour or recovery by themselves. Treat handover as a reviewable working agreement between design, product and engineering.
Let’s plan your design handover.
Bring your requirements and the decisions you need to make. We’ll help you clarify the scope, explore the trade-offs and plan the next step.
Start with the journey and its purpose
Document the user, starting conditions and accepted outcome. Identify which information is real, which examples are placeholders and which dependencies remain unavailable.
Separate approved behaviour from visual exploration. Engineers should not need to infer whether an abandoned alternative or a comment thread represents the current product decision.
Assemble a handover pack
| Item | What engineers need | Question it resolves |
|---|---|---|
| Journey | Roles, transitions and outcome | What is being completed? |
| States | Loading, empty, failure and permission cases | What happens outside the default? |
| Content | Labels, instructions and realistic examples | What information is actually shown? |
| Validation | Rules, ownership and messages | Which input is accepted? |
| Components | Reuse and intentional variations | What belongs to the shared system? |
| Responsive behaviour | Layout priorities and constraints | What changes with available space? |
| Evidence | Findings and acceptance expectations | Why was the decision made? |
| Open decisions | Owner and required resolution | What must not be guessed? |
Use a format the team can maintain. The completeness of the decisions matters more than the number of exported files.
Walk through an asynchronous action
Suppose a hypothetical design includes a button to generate a report. Specify pending, completed, failed and cancelled states, including what happens if the user leaves and returns.
Identify the authoritative completion event and the record the user can reopen. A progress illustration should not require the engineer to invent a backend guarantee or imply that processing stops when the browser closes.
Include realistic content and restrictions
Use long names, large values, missing information and restricted records in examples. Define truncation, wrapping and access-related messaging deliberately.
Clarify whether unavailable actions are hidden, disabled or explained in another way. The appropriate interaction depends on the user's task and expectations; document the chosen reasoning rather than applying a visual convention without context.
Review feasibility before declaring handover complete
Bring API and platform owners into the review. Confirm that the required information exists and that proposed behaviours fit the operating process.
Where a constraint requires change, preserve the task outcome and record the revised decision. Avoid a process in which engineers quietly simplify critical states while design files continue to show the original behaviour.
Keep a clarification and acceptance loop
Name who resolves questions and how decisions are versioned. Review implemented journeys with the agreed content and environment rather than comparing only isolated screenshots.
Maintain documentation after changes. Handover is useful to future teams only if it describes the running product and explains meaningful deviations.
Questions teams ask
Does every state need a separate polished frame?
Choose a clear, maintainable specification. Some states can be documented through component behaviour and rules, provided the implementation is unambiguous.
Can developers decide all unspecified details?
Assign decision ownership. Engineering judgment is important, but business and user-experience choices should not become accidental defaults.
Prepare the handover review
Bring one complete journey and its exceptions. Use the design-system guide and UI/UX design overview to agree reusable behaviour and acceptance evidence.