"Dev-ready" is a phrase every design studio uses. It is also a phrase that can mean almost nothing. For some, it means a Figma link and good luck.
When we say it, we mean a defined set of things that an engineer can open and build from, without sending us twenty questions. Our MVP design sprint ends with a handoff like this. This article lists what is in it, so you can check any handoff, ours or someone else's, against the same list.
Why handoff matters
A design is only useful when it becomes a product. Between the two sits a handoff, and it is where time and quality quietly leak.
If the handoff is thin, engineers fill gaps with guesses. Some guesses are fine. Some are wrong, and you only find out when the feature is built and the founder says "that is not what I meant". Fixing it then costs far more than a clear handoff would have.
A good handoff does the opposite. It answers the questions before they are asked. The engineer reads, builds and checks. Fewer meetings, fewer surprises.
Flows and screens
The first piece is the map: how the screens connect.
- User flows. A diagram for each main task, from the first step to the result. Sign-up, create a project, invite a teammate, pay. Each box is a screen or a decision.
- Screen list. Every screen named and numbered, in the order a user meets them. A sprint usually covers 15 to 25 core screens, and the list says which ones.
- Clean Figma pages. Pages are named by area, such as Onboarding or Settings. Old versions and experiments are moved to an archive page. Nobody should wonder which frame is the real one.
- A clickable prototype. It shows how the flow feels, which a static frame cannot.
The flows matter as much as the screens. Screens show what things look like. Flows show what happens next, and engineers need both.
States and edge cases
This is the part most often missing from a weak handoff, and the part engineers ask about most.
For every screen that loads data or takes input, the handoff should show:
- The loading state
- The empty state, for a brand-new user
- The error state, with the message
- The filled state with realistic data, including a very long name or a very long list
- Any disabled or read-only version
- Form validation, with the rule and the wording for each error
We also mark the less common cases that come up in real use: what happens when a user loses connection halfway, or tries to leave a form with unsaved changes, or has no permission to see a page.
We do not draw every possible case at full detail. We draw the important ones and add short notes for the rest. The aim is that no engineer reaches a blank spot where the design simply stops.
Components and tokens
Engineers do not build screens. They build components, and then compose screens from them. A handoff should be organized the same way.
A design-system starter. In a sprint, this is a small, careful set: colors, type styles, spacing and the key components, such as buttons, inputs, tables, modals and navigation. Each component has its variants and states: default, hover, focus, disabled, error.
Tokens. Colors, type sizes, spacing, radius and shadow are stored as named variables in Figma, not as loose values. That makes it simple to match them in code. We covered the idea in our article on design tokens for product teams.
Names that match the code. If your team already has a component library, we use its names where we can. If not, we choose names an engineer would pick, and agree them with you at the start.
Reuse, not copies. Screens use the component instances, so a change to a button updates everywhere. If you find a detached, hand-edited copy in the file, that is a bug in the handoff.
Specs and notes
Engineers can read spacing and sizes from Figma's inspect panel. The handoff adds the things the panel cannot say:
- Behavior notes. What happens on click, on submit, on a failed request. Is it saved automatically? Does it need a confirmation?
- Responsive rules. How a layout changes at a narrower width. Which parts stack, hide or scroll.
- Content rules. Character limits, truncation, how dates and numbers are written.
- Motion. Where animation is used, how long it lasts and what it should feel like. We keep it light, and we say where it should be turned off for people who prefer reduced motion.
- Accessibility notes. Focus order, labels for icon-only buttons, and contrast checks on the colors we chose.
- Assets. Icons, logos and images exported in the right formats and sizes, named clearly. Our own Figma plugin, UIXport, exists for this job, because we got tired of exporting by hand.
Notes live next to the frame they describe, not in a separate document that goes stale. A short note beside the right screen is read. A 30-page document is not.
We also write down what is not decided. If the content for a screen depends on a decision your team has not made, the handoff says so, so nobody mistakes a placeholder for a final choice.
The walkthrough call
The last piece is a person. At the end of a sprint, we hold a walkthrough call with your team, and your engineers should be there.
We open the Figma file and go through it in the order a developer would build it: the flows first, then the system, then the screens. We point out the tricky spots and the places where we made a trade-off. Engineers ask questions, and we answer them while the context is fresh.
The call is also when a developer says "this will be hard to build as drawn". That is useful to hear on day one of the build, and we would rather adjust the design than leave a problem for later.
Afterwards, we stay reachable for questions as the first screens get built. The details of that depend on the plan you choose, so ask us when you scope the work.
A quick check you can run
Whatever studio you work with, ask these questions about a handoff:
- Can an engineer see how every screen connects, without asking?
- Are loading, empty and error states drawn?
- Is there a component set with variants, and do screens use it?
- Are colors, type and spacing stored as tokens?
- Are behavior and responsive rules written down?
- Did the engineers who will build it hear it explained?
If the answer to most is yes, it is probably dev-ready. If not, expect questions later.
You can see how we run each step on our process page. If you want us to check an existing handoff, or a Figma file you plan to send to your developers, ask for a free design review at /contact.
