The useful starting point
A design handoff needs more than desktop frames. Give production the states, assets, content, and decisions that define a finished website.
Start with a source of truth
Name the design file, approved version, page inventory, and person responsible for clarifying decisions. If feedback is still arriving, distinguish approved screens from work in progress. A developer should be able to tell which version to build without searching across messages. Add a short explanation of the website’s primary audience and journeys so the team can recognise which interactions matter most.
Describe responsive behaviour, not only widths
Supply mobile states for important templates and explain how content should rearrange between desktop and mobile. Note navigation behaviour, column order, image crops, long headings, overflow, and whether a table needs an alternative presentation. If an intermediate layout is not designed, identify who approves the proposed interpretation. Test real content lengths instead of relying on the neatest sample heading.
Identify components and their states
Mark repeated elements such as headers, buttons, cards, forms, and calls to action. Include active navigation, expanded menus, focus, hover, errors, and empty states where applicable. Explain which variations are intentional. A visual difference between two cards might be a real variant or an accidental inconsistency; leaving that distinction unresolved creates unnecessary production decisions.
Write down interactions and functionality
For each interactive element, explain the trigger, result, and fallback. A play icon needs a video source and accessible playback expectations. A form needs field rules, recipients, confirmation copy, error handling, and integration requirements. A filter needs a content source and a clear rule for no results. Keep essential actions usable by keyboard and touch rather than defining them only through hover.
Prepare assets and real content
Provide original images, logos, icons, font files or licensed download sources, and any usage restrictions. Identify decorative images separately from images that communicate information. Confirm who writes alternative text. Final content can change the design: long labels, missing images, and additional paragraphs should be tested before the layout is accepted. If content is pending, record the owner and the date needed for review rather than presenting placeholders as finished inputs.
Define editing and acceptance
Agree what the agency should be able to change in WordPress and what should remain a reusable template. Include representative acceptance checks: page hierarchy, responsive behaviour, keyboard navigation, links, form submission, and editing without breaking the layout. Visual matching is one part of acceptance, not the whole website. W3C’s page structure guidance is a useful reference for meaningful headings and regions.
Practical handoff checklist
Use this list as a review before scheduling production. A missing item does not always block the build, but it needs an owner and a decision about its effect on scope.
- Approved file version and page/template inventory
- Responsive rules and component variations
- Interactions, form routing, and failure states
- Licensed assets and content status
- WordPress editing requirements
- Acceptance criteria and review owner
Reference consulted
This guide provides a practical planning framework. The project’s requirements and agreed responsibilities determine the final approach.
