What a website handoff document should include: a checklist

A project isn't finished when the final design is approved. It's finished when the people who build and maintain the website have everything they need, and know where to find it. A handoff document puts all of that in one place.

A good handoff saves you from the same questions arriving weeks later. It also leaves the client with a clear record of what they received. Here's what to include.

Who the handoff is for

Usually there are two readers:

• The client, who wants to know what they've received and where it is.
• The developer or team building the site, who needs the details: files, specs, assets and decisions.

Write the opening for the client and the details for the developer. A short introduction followed by clearly labelled sections works for both.

The handoff checklist

Delivered files

List every file with a short name, a description and a working link. Typical items for a website project:

• final design file
• interactive prototype
• component library or style guide
• exported assets, such as icons, images and social sharing images
• the final copy, if it's held separately

Check every link before you send the handoff, and make sure the client has the right access. A link that asks for permission is a question waiting to happen.

Fonts and licences

For each typeface, note the name, where it comes from, and how it's licensed. Some fonts are free for commercial use. Others need a licence for web use that the client has to buy in their own name.

You don't need to interpret licence terms for the client, and you shouldn't promise they're covered. Point them to the licence and make it clear who is responsible for buying it. If in doubt, they should check the foundry's licence terms directly.

Colour palette

List each colour with a name the team can use in conversation and its exact values, such as HEX and RGB. Group them by role if it helps, for example primary, background, text and feedback colours. Developers will copy these values directly, so double-check them against the design file.

Design system notes

A few short paragraphs go a long way:

• the spacing scale, such as an 8px grid
• type styles and where each is used
• how components are named and built, and which variants exist
• anything the team should avoid, such as overriding styles locally instead of using shared ones

The aim isn't a full design system document. It's enough guidance that the next page added to the site looks like it belongs.

Developer notes

Write down the things that aren't obvious from the design files:

• breakpoints and how layouts change between them
• hover, focus, disabled and error states for interactive elements
• interactions and transitions, and where the prototype shows them
• how images and icons were exported, and at which sizes
• any content rules, such as maximum headline length

If you agreed to do design QA during the build, say how the developer should request a review.

Support after handoff

State clearly what support is included and for how long. For example: fixes to the delivered files and questions about the design during development, for 30 days after handoff. Also say what isn't included, such as new pages or features, and how those would be quoted. Clear support terms make it easier to say yes to small questions and to quote for larger ones.

Sign-off and thanks

End with a short thank-you and a line confirming the handoff is complete. A name and a date are enough. It gives the project a clear end and a natural point to send the final invoice.

Common mistakes

• Scattered links. Everything should be in one document, not across emails.
• Missing licence information. It's the question most likely to come back later.
• Colours copied by eye. Use exact values from the design file.
• Open-ended support. Without an end date, support quietly becomes unpaid work.

How the handoff connects to the rest of the project

The handoff closes the loop that started with the project brief: the deliverables you promised in the proposal are now listed, with links, in one document. After that, the only document left is the invoice.