Figma for interface design and handoff
Three problems bring people to this page: files that never became the product, a handoff engineers keep having to guess at, and a library somebody has started calling a design system. This page sorts out which one you have.
01Overview
Where the file ends and the product begins
Figma is a browser-based interface design tool. Several people edit one file at once, and it holds components, layout rules, variables and clickable prototypes. Dev Mode gives engineers measurements and values. It is a design tool, not a build tool: nothing in a file runs in production, and the catalogue engineers build against lives in Storybook.
02Capabilities
Three moments a file has to survive
Three points where the file meets the build. In all three it records a decision rather than proving one, which is the distinction the rest of this page turns on.
- Before
Settling the interface before code exists
Flows, states and layout decided while they are still cheap to change, as part of product design. In dense products, such as the clinical and admin screens in healthcare software, the decisions worth making here are information density, error prevention and what happens on the unhappy path.
- Handoff
A handoff an engineer can build from
The empty, loading, error and overflow states, spacing rules, breakpoint behaviour and interactive states, written down so they are not invented later by whoever picks up the ticket. Once components exist in code the catalogue moves to Storybook, and the file stops being the source of truth.
- After
Reading a live product against its own design
When a product has drifted from its design, a side-by-side pass is the fastest way to see how far and where. That usually feeds a UX review or a design system rebuild rather than a redraw.
03Fit
Where Figma settles it, and what settles the rest
Almost every Figma problem is the same problem: a decision looks settled because it exists in a file, when the thing that settles it lives somewhere else. Row one is the job the tool is genuinely best at. Three of the other five name the page that settles them, one settles in the browser, and one starts with reading the product.
| What you are trying to settle | Where it actually gets settled |
|---|---|
| Flows, screen states and layout, before anybody writes code | Use FigmaThe one job it is best at, and the spine of how we run product design. Deciding here is cheap. Deciding in a pull request is not. |
| Whether the layout survives real content | Test with real dataIn the browser, with real data. A frame carries the content the designer typed, which is always the flattering length. |
| What a component is called and what it accepts | Different pageIn code, catalogued in Storybook. A drawn component and a built one drift apart within weeks unless somebody owns the mapping. |
| Whether the interface is actually usable | Different pageWith users, or against a structured review such as Nielsen's usability heuristics. Visual polish answers a different question. |
| Whether you have a design system | Different pageIn the token and component layer, which is design system work. A file page labelled Design System is a library. |
| Redrawing screens nobody has diagnosed yet | Review firstRead the product first. A redraw that starts before the UX review reprices the same defects in a new colour. |
Scope
What we own is the part after the file. If an engineer cannot build a screen from what we handed over without guessing, that is our defect, and the fix is a clearer specification rather than more pixels. unicrew has been designing and shipping product interfaces since 2012, with 100+ senior in-house engineers across six countries, under an ISO 27001:2022 certified information-security management system. We build to WCAG 2.2 AA.
04Stack
What the handoff touches on either side
The five decisions on either side of the file, each with a page of its own.
05Questions
Questions from teams whose designs never shipped
Answered the way we would answer them live. If yours is not here, it is a good first message.
Yours, if you have one. Inheriting a file is also a useful diagnostic: how components, variables and naming are organised tells us quickly whether the product has a design system or just a lot of rectangles. Where a file is genuinely unusable, we agree with you what to rebuild, rather than quietly starting again in a parallel file nobody else can find.
Figma, for anything new. Adobe XD is no longer where Adobe puts its development effort, so starting a product design there means building on a tool that will not gain the features your team ends up needing. If you already have XD files we can work from them, but that is a migration decision rather than a reason to stay. The rest of the Adobe toolchain is a separate question and still very much in use.
No, and treating it as one is a common way design systems fail. A library is a set of reusable drawings. A system is the decisions underneath (tokens, naming, composition rules, accessibility requirements) plus the same components implemented in code and documented where engineers work. The library is one artifact of the system. Building the rest is design system work.
For simple screens, often yes. Dev Mode gives real measurements and variable values, which removes a lot of guesswork. What it cannot give is intent: which states exist, what happens when the list is empty or the request fails, what is fixed versus fluid, and which of two similar components is the right one. Those are decisions, and they need to be written down somewhere an engineer will actually read.
Three shapes, and which fits depends on how settled the scope is. Time and materials is billed hourly and quoted per project, which suits work still moving. Fixed price is outcome based, and only after the first read, because a fixed number on a product nobody has opened is a guess with a contract around it. Team extension is billed monthly per engineer. The rate depends on the seniority mix the work needs, so it is quoted rather than listed.
Have designs that never reached production?
That gap is usually specification and ownership rather than tooling. Tell us what is stuck, and we will say whether it is a product design job, a design system job, or a shorter conversation.