Answer in brief
A design handoff leaves no guesswork when it states seven things besides the screens: which frames are final and in what version, every state of every component including errors and empty screens, the design tokens behind the values, how layouts behave between sizes, the rules for real content, the assets with their licences, and the acceptance criteria for each screen. Questions then go through one channel, and each answer is written back into the file.
Every gap in a handoff becomes a decision made by the wrong person
A design file answers the questions its author thought of. Production asks the rest: what does this button look like while the payment is processing, what happens to the card when the name is forty characters long, which grey is this. If the file is silent, the developer decides, alone and with a deadline, and that decision ships.
None of this is carelessness on either side. A mock-up shows one moment of an interface with ideal content, and an interface is hundreds of moments with real content. The gap between the two is the handoff, and it is filled either by a written rule or by a guess. Guesses are cheap to make and expensive to find later.
A design handoff to developers that leaves no guesswork contains seven things besides the screens: a status for every frame, all states and edge cases, tokens, responsive rules, content rules, assets with their licences, and acceptance criteria. An eighth holds them together: one place where questions are asked and answered.
Mark what is finished and which version it is
The first guess a developer makes is whether a frame is final. Files carry explorations, rejected variants and half-finished ideas next to approved work, and they all look equally real. State the scope in words: a list of the screens and components in this release, and a visible status on each.
Design tools now support this directly. Figma’s documentation describes Dev Mode as a workspace for inspecting designs, comparing changes and managing design handoff; frames, components and sections can be marked “Ready for dev”, and the current version of a frame can be compared with earlier ones. Whatever tool you use, the principle is the same.
A status is a promise, so treat whatever changes after it as a change. If an approved frame is edited, leave a short dated note beside it saying what changed and why, and tell the people building it. A silent correction to a “ready” screen is how two versions of the same component reach production.
Draw every state, then the awkward cases
A component is not one picture. Material Design’s specifications group component tokens first by state, “enabled, disabled, hover, etc”, and only then by element, which is a fair model for a handoff. For each interactive component show the default, hover, keyboard focus, pressed and disabled states, and for anything that waits on data, the loading, success and error states too.
Then design the cases nobody puts in a presentation. The empty list before the first item exists. The search with no results. The name three times longer than the sample, the photo that failed to load, the table with one row and with a thousand. The user who lacks permission, and the one on a slow connection.
A state table keeps this manageable: components down the side, states across the top, a link or a note in every cell. An empty cell is a question that will be asked in the middle of a sprint. “Same as default” is a legitimate answer; it simply has to be written down by the designer and not assumed by the developer.
Tokens turn copied values into named decisions
Material Design defines design tokens as small, reusable design decisions that make up a design system’s visual style, replacing static values with self-explanatory names. Its documentation makes the handoff argument itself: when a designer’s mock-up and an engineer’s implementation reference the same token, both can be confident the same colour is used, even if its hex value is updated later.
There is now a common file format for them. The Design Tokens Community Group published the Design Tokens Format Module 2025.10 as a stable report in October 2025; the document notes that it is not a W3C Standard. Tokens are stored as JSON, each with a value and a type and, optionally, a description of its purpose, and a token may be an alias that points to another token.
For a handoff the practical minimum is a table or a tokens file covering colour, typography, spacing, radius, shadow and motion, with names that say what a value is for and not what it looks like. Material’s three classes are a useful pattern: reference tokens for the available raw values, system tokens for roles, component tokens for the parts of a component. Anything in the file that uses no token should be marked as a deliberate one-off.
Responsive behaviour is a set of rules, not three screenshots
Three artboards, for phone, tablet and desktop, describe three widths out of thousands. What production needs is the behaviour between them: which elements stretch, which keep a fixed size, which wrap onto a new line, which stack, which disappear, and in what order. Write these as rules attached to the layout, with minimum and maximum widths where they exist.
State where the layout changes and why. A breakpoint is useful when it is tied to the content, for instance the width at which the navigation no longer fits on one line, and arbitrary when it is copied from a device list. Say also what stays constant: the reading width of text, the size of touch targets, the spacing scale.
Width is only one condition. Material Design’s token documentation lists others under the name of contexts: device form factors, dark theme, dense layouts and right-to-left writing systems. A handoff should say which of these the product supports in this release and show at least one key screen in each, so that the rest can be derived from tokens and rules.
Content rules: real text, limits and what happens beyond them
Placeholder text hides most layout problems. Hand over real copy for every screen, including button labels, error messages, empty states and confirmation emails, written or approved by whoever owns the words. A developer who has to invent an error message will write one, and it will reach users.
For every text element that is filled from data, give the rule: the expected length, the maximum, and what happens beyond it, whether the text wraps, is truncated with a way to see the rest, or shrinks. Do the same for images: the aspect ratio, how they are cropped, and what is shown when there is none.
Add the formats that differ by language and region: dates, times, numbers, currency, plurals. If the product will be translated, test the layout with the longest language you plan to support, and with a right-to-left one if relevant. And give every meaningful image its text alternative in the handoff, because that too is content somebody has to write.
Assets and licences travel with the file
How to export assets is not for the developer to guess either. List what is needed and in which format: vector files for icons and logos, raster images at the sizes and densities the product uses, video and animation files with their settings. Figma’s Dev Mode, for example, lets developers download assets and export layers as PNG, JPG, SVG or PDF; someone still has to say which.
Names matter more than they seem. A consistent naming pattern that matches the names in code spares everyone a mapping table, and one agreed folder or library spares the question of which logo is current. Keep the original, full-resolution sources with the handoff, not only the compressed exports.
Then the licences. For each font, state which licence covers its use on the web or in an app and in whose name it is held. Do the same for stock photographs, illustrations, icon sets and music. A mock-up may be built with a trial font or a watermarked preview; the shipped product needs the real licence, and the developer cannot know which is which unless the handoff says so.
Acceptance criteria and one channel for questions
The UK government’s Service Manual describes acceptance criteria as a list of outcomes used as a checklist to confirm that a service has done its job and meets the user need, often written as a list that begins “it’s done when…”. The same device works for a screen: it is done when every state in the table is built, the tokens match, the layout rules hold at any width and real content fits.
Write the criteria before development starts and review the build against them, on real devices, with the designer present. Design review then stops being a matter of taste and becomes a comparison with a list, and the developer has something to check before asking for the review.
Finally, choose one channel for questions and name it in the handoff. A question asked in a chat, settled in a call and remembered by two people is lost to everyone else. Keep questions next to the design, as comments or annotations on the frame, name the person who answers and how quickly, and write every answer back into the file as a rule. The next project then starts with fewer gaps.
Practical checklist
- Mark every frame in scope with a status and note each change made after it was declared ready.
- Fill in a state table for each component, including loading, error, empty and no-permission cases.
- Hand over tokens as a file or table with purpose-based names, and flag every value that uses none.
- Write the responsive, content and image rules in words, and test the layout with the longest real text.
- List assets with formats and licences, write acceptance criteria per screen and name one channel for questions.
Questions and answers
What should a design handoff include?
Besides the screens: a status showing which frames are final, every state of every component, the edge cases, design tokens, the rules for responsive behaviour, real content with its limits, assets with their licences, and acceptance criteria for each screen. Add one named channel for questions. If a developer can build a screen without asking what happens when the data is missing or too long, the handoff is complete.
What are design tokens, and do small projects need them?
Design tokens are named design decisions, such as a colour, a spacing step or a type size, stored once and referenced everywhere. Material Design’s documentation says they are most helpful when a product will be updated, spans several platforms or has a design system, and less helpful for an existing app with hard-coded values that is unlikely to change. A small project can start with a short table of named colours, sizes and spacings.
Is the design tokens format an official W3C standard?
No. The Design Tokens Format Module 2025.10 was published by the Design Tokens Community Group, which works under the W3C community group process, and the document states that it is not a W3C Standard and is not on the W3C Standards Track. The group describes the specification as stable and intended for implementation. Check the group’s site for the current version before building tooling on it.
Which states should every interface component have?
It depends on the component, but the usual set for an interactive element is default, hover, keyboard focus, pressed and disabled. Elements that depend on data also need loading, success, error and empty states. Material Design’s specifications organise component values by state for the same reason. List the states in a table and write “same as default” where that is the answer, so nothing is left to assumption.
How do you write acceptance criteria for a design?
Write a short list of observable outcomes for each screen, in the form the UK government’s Service Manual suggests: “it’s done when…”. For example: it is done when all listed states are built, when the layout holds at any width between the stated minimum and maximum, when real content of maximum length fits, and when the tokens in code match the tokens in the file. Agree the list before development and review the build against it.