A design handoff checklist for the screens nobody remembers to draw

Start with the shared task

Write a short description of the user, goal, starting condition, and completion state. Include known constraints and the evidence behind the flow. A collection of polished screens without that context makes it harder for engineers to resolve the gaps responsibly. Agree on the key behavior before spending time documenting every pixel.

List the states before exporting assets

For each important component or screen, consider loading, empty, error, partial, success, disabled, and permission-restricted states. Decide which are relevant instead of drawing every possible permutation automatically. Specify whether work is preserved after an error and what retry means. Explain whether a disabled action needs an accompanying reason or whether it should be absent entirely.

Describe real content conditions

Test long names, multiple languages where applicable, missing images, zero results, many results, and unexpected data. Mark truncation rules and places where text can wrap. Use believable sample content that is clearly fictional. Do not rely on identical short labels to conceal a layout that breaks with realistic values. Include who owns the final copy and how it will be reviewed.

Make interaction and accessibility requirements visible

Document keyboard order, focus movement after dialogs or errors, labels, status messages, and expected reading order. Link to authoritative guidance where relevant. A visual annotation alone cannot prove accessibility; implementation and testing matter. Review the plan with engineers and people who understand the assistive technologies relevant to the product, rather than handing over a generic checklist at the last minute.

Turn consequential behavior into acceptance criteria

Example: “When saving fails, the form preserves entered values, identifies the issue in text, and offers a retry.” Another: “After successful creation, the confirmation identifies the item and provides a route to view it.” These are example requirements, not claims about a specific system. Agree on edge cases such as duplicate submissions, expired sessions, and unavailable dependencies before estimating completion.

Review the implementation together

Schedule a short design and engineering walkthrough against the actual behavior. Record differences as bugs, acceptable tradeoffs, or follow-up work. Do not treat every deviation as a failure; constraints can change, and an alternative may serve the task better. Update the design or decision log so the documentation describes the agreed product instead of an abandoned ideal.

Make a one-page handoff brief

Include task, scope, states, content rules, accessibility considerations, acceptance criteria, dependencies, and open questions. Assign an owner to each unknown. Use the free product decision log to preserve the rationale. If a flow needs improvement before engineering begins, the Prototype Improvement Sprint can produce a bounded prototype and handoff; production development and user recruitment are separately scoped.

Further reading

W3C WAI: forms, labels, instructions, and feedback. Use this guidance alongside implementation testing; this article is not a conformance audit.

Keep exploring

A better-looking redesign is a hypothesis. Here is how to test it.

How to prioritize UX friction without giving your product a made-up score