How to hand over website designs to a developer

A design handover checklist helps an agency explain which screens to build, how they should behave and what still needs a decision. A link to the design file is a starting point, but it rarely answers all three.

Use the template below to prepare a written handover for a website project. It works whether you use Figma or another design tool. You do not need to resolve every detail before involving a developer; make the gaps visible and agree who will work through them.

For project goals, scope, budget and wider responsibilities, use the development brief for agency projects. This guide focuses on the designs and supporting material needed for the build.

Identify the version and screens to build

Point to the current file and specific pages, frames or components. Label what is approved, what is still being explored and what belongs to a later release. An old prototype or an unlabelled alternative should not quietly become the specification.

Include the shared parts as well as individual pages: navigation, footer, buttons and recurring content blocks. If two screens show different versions of the same component, identify which one takes priority.

Keep one place for agreed decisions and record changes after handover. A developer can review an early design for feasibility without treating every screen as approved for implementation.

Explain what changes as the screen gets smaller

Desktop and mobile frames show particular layouts. They do not explain every width between them.

Describe the rules: when columns stack, which content comes first, how navigation changes and whether images crop or keep their full shape. Note whether a sidebar moves below the main content or disappears, and what should happen to anything it contains.

Check longer headings, larger text and missing images too. A layout that depends on a short placeholder heading may behave differently with the client’s final copy.

You do not need a separate mock-up for every screen size. Supply representative designs and agree the behaviour between them. Let the developer flag where a proposed rule needs testing rather than forcing fixed dimensions into every layout.

Describe interactions and missing states

For anything interactive, explain the trigger, the result and how someone leaves or reverses it. An open menu design needs a closed state and opening behaviour; a form needs more than its empty appearance.

Record relevant states such as keyboard focus, expanded content, validation errors, loading and failure. Explain what a button or link actually does. A prototype animation may communicate appearance without defining submission, navigation or error handling.

Agree keyboard behaviour, visible focus and motion preferences alongside the design. These details still need checking in the built website; annotations alone do not establish accessibility.

If a state has not been designed, assign the decision. The developer can propose an approach for written approval rather than guessing or waiting for an entirely new set of screens.

Supply copy, fonts and usable assets

Link to the copy and asset sources, not just the versions pasted into a mock-up. Mark draft content and identify who approves replacements.

Include the font families, required weights and the web-use licence or approved source. Confirm that the client has the right to use the fonts and images; a file being available in a design tool does not settle that question.

For images and icons, identify the intended export or original, crop requirements and who supplies descriptions where needed. Explain which images convey information and which are decorative so the developer can implement appropriate text alternatives.

Check that the developer can inspect the relevant files and obtain the assets using appropriate permissions. Do not share passwords or grant editing access to everything by default. A particular paid inspection feature is not a prerequisite for a useful written handover.

Record open decisions and who resolves them

Keep a short decision list alongside the designs. Each item should say:

• What is missing or uncertain.
• Who proposes an answer and who approves it.
• Which part of the build depends on it.
• When it must be resolved before that work proceeds.

For example, an undecided hero image crop need not stop work on an approved navigation component. The developer should identify dependencies; the agency should make sure client decisions reach the right person.

Use clear statuses such as ready, needs a decision and outside this release. Avoid marking the whole package ready while important assumptions sit in unrelated comments.

Agree written review and design changes

Identify who gathers feedback and gives the agency’s approval. Review a shared preview against the agreed designs, behaviour and content, including layouts between the supplied frames.

Keep feedback specific: name the page or component, describe what differs and point to the agreed reference. Consolidate conflicting comments before asking for changes.

Separate an implementation that differs from the agreed behaviour from a new design request. Agree how changes affect scope before work proceeds; do not assume a change to the design file automatically updates the build agreement.

Copy this design handover checklist

Use this once for the package, then repeat the screen/component entry where needed. Deliberately blank fields are for your project, not requirements to invent an answer.

DESIGN PACKAGE
Current file and version:
Included pages and shared components:
Approved references and alternatives to ignore:
Where agreed decisions and later changes are recorded:
Agency reviewer and final approver:

SCREEN OR COMPONENT
Name and reference link:
Status: ready / needs a decision / outside this release
What it does and where it appears:
Responsive layout, content order and image behaviour:
Interactions, keyboard behaviour and relevant states:
Copy source and approval status:
Fonts, assets, licences and access required:

OPEN DECISION — REPEAT AS NEEDED
Question and affected screen/component:
Who proposes the answer:
Who approves it:
What build work depends on it:
Resolution needed before:

REVIEW
Preview and agreed checks:
Where consolidated feedback goes:
How new design requests are agreed:

Worked example: a service page and mobile navigation

This is a fictional handover, not a client project or a recommended specification for every website. The file labels, breakpoint and layout choices illustrate the level of detail; they are not links to real design files.

Package and approved references

The agency identifies “Website v3 / Service page / Desktop”, “Website v3 / Service page / Mobile” and “Website v3 / Shared navigation” as the current references. “Website v2” and the unused colour alternatives are outside the build.

The agency design lead approves layout decisions and gathers client feedback. The developer records implementation questions in the shared written decision list. Service-page copy is approved; the hero image crop is still open.

Agreed layout and navigation behaviour

In this example, service cards use two columns at widths of 48rem and above and one column below. Text wraps, card heights follow their content and the reading order stays the same. The developer also checks intermediate widths and larger text rather than testing only the supplied frames.

Below the same breakpoint, a Menu button reveals a navigation list in the page beneath the header. It is a disclosure, not a modal overlay. Opening it keeps focus on the button; the next Tab reaches the first link. The button’s expanded state follows whether the list is open.

The button can close the list. Escape also closes it and returns focus to the button. Closed links are not keyboard-focusable. At wider layouts the links appear inline; changing layout must not leave focus in hidden content. The agency reviews these behaviours in the working preview.

Open decision and review

The hero image is ready, but its mobile crop could hide the subject. The agency design lead will propose a crop for client approval before the hero-image work proceeds. The approved card and navigation work can proceed independently.

The agency reviews the service page, longer headings, image crop and keyboard navigation, then returns one consolidated feedback list. Adding another card style after approval would be a new request to discuss, not an unrecorded change to the original reference.

Need help building the designs?

Odd Little Bits builds websites and web apps for small agencies, with scope, questions and progress handled in writing.

Send the relevant designs, what is ready and where you need help. A clear outline is enough to start; please do not include passwords or confidential client information.