Handoffs break because a design file shows a few states at two widths, and a live site has many states at every width. A developer under deadline usually fills the gap. Below: where drift starts, the eight states we settle before a build, and CFH Design’s site, designed and built by one team.
Where the drift starts
The gap is not one failure but four, and they compound.
| Gap | What happens | What closes it |
|---|---|---|
| States nobody drew | Hover, focus, loading, error and empty states are invented during the build | Every state decided in writing before code |
| Widths between the drawn ones | The tablet and wide-screen layouts get whatever the developer judges in the moment | Behaviour between breakpoints agreed with the designer |
| Interactions described elsewhere | A transition explained on a call never reaches the person building it | Interaction notes kept in the file and the build brief |
| No shared tokens | Each developer picks the nearest-looking colour and spacing; across a hundred components it looks visibly off | Colour, spacing and type defined once and used as variables in the code |
Most pre-launch testing checks that the site works: forms submit, links go where they should. Few teams check that it matches the approved file, so drift is usually found by the client after launch, when fixing it means reopening work already marked done.
The eight states we decide before a build
A design file typically shows one or two states of an interactive component. A shipped component has eight. The six that are not drawn still get built; the only question is who decides them. We would rather the client did, in writing, before the build.
| State | Usually in the file? | What to decide |
|---|---|---|
| Default | Yes | The source for spacing, type and colour tokens |
| Hover | Usually, sometimes only as a comment | How it looks, and that it is switched off on touch screens |
| Focus | Almost never | A visible outline with enough contrast, kept even if someone later finds it untidy |
| Active or pressed | Rarely | What confirms the tap or click landed |
| Disabled | Rarely | How it looks, and whether it explains why it is unavailable |
| Loading | Rarely | What the user sees while waiting |
| Error | Rarely | The message, where it appears and how to recover |
| Empty | Rarely | What shows when there is nothing to list yet |
Our design-to-code work starts with a feasibility audit of the file that flags missing states in writing, and ends with a documented parity review of the built pages against the artboards.
CFH Design: one team from design to launch
CFH Design is a UK creative agency with more than 40 years behind it, offering around twenty services from branding and digital marketing to exhibitions and interiors. It needed a website that presented all of that as one offer, showed its client list without clutter, and let the work lead on every device.
We built it as one team, from design through build and launch. The site uses full-screen, image-led layouts with a bold headline and minimal navigation, four clear menus (What we do, Who for, About, Contact) that expand in place, and a responsive web design build for desktop, tablet and phone.
A design like that leaves exactly the decisions the tables above describe: how each menu looks open and closed, how twenty services behave on a phone, and how a full-screen image crops at widths nobody drew.
With design and build in one team, those questions can go to the people who drew the design instead of to a guess. The case record does not itemise how each one was settled, so we do not claim it here.
- Undrawn states
- Invented during the build by a developer under deadline
- Drift is caught
- By the client after launch, reopening finished work
- Undrawn states
- Found in an audit of the file before quoting
- Drift is caught
- In a parity review before launch
- Undrawn states
- Questions go to the people who drew the design
- Drift is caught
- In a documented parity review against the artboards
The client’s own summary: “The site is visually strong, easy to navigate and does a much better job of showcasing our work and capabilities.” The full record is in the CFH Design case study.
Why two separate suppliers rarely close the gap
A design studio is paid to deliver an approved file, and a development team is paid to ship working software against a brief. Neither is paid to police the seam between them, so “match the file” is nobody’s deliverable. Both can do competent work and the site can still drift.
One team is not the only fix, and it is not always the right one:
- You have a mature design system in code. Tokens and components already exist, so a separate build partner works from the same source and drift has little room.
- You already have a signed-off file and a trusted designer. Hire a build partner who audits the file for missing states before quoting and runs a parity review before launch.
- Separate suppliers will not change. Put a written visual review against the artboards into the build contract, with a named owner for each deviation.
Before hiring anyone, we recommend asking to see how a colour value moves from the file into the code, how an undrawn error state gets decided, and what happens between code-complete and launch. A team with a real process answers in specifics.
