Refspan project guide
Design to development handover checklist for agencies
A design to development handover should explain how the site behaves, what content can change and how the agency will approve the build. Design files are the starting point. Responsive rules, component states and editing requirements turn those files into a brief a developer can implement and review.
Identify the approved source of truth
Share the current design file and identify the frames approved for development. Separate final decisions from experiments. Include the page list, brand assets and a named contact who can resolve questions.
If the client is still changing the design, agree which sections can begin and which should wait. A dated handover note makes it easier to distinguish the agreed version from later requests.
- Approved desktop and mobile frames, where available.
- Logo and image assets with usage permission.
- Typography, colour and spacing rules.
- Page list, reusable templates and outstanding decisions.
Specify behaviour as well as appearance
Document the states that a static screenshot cannot show. A form needs labels, validation, success and failure messages. Navigation needs an agreed mobile behaviour. Cards and buttons need hover and keyboard focus states.
Where a layout has no mobile design, write down the expected reading order, which elements stack and any content that should remain visible. Ask the developer to raise unclear behaviour before it becomes an implementation assumption.
- Navigation: open, closed, current page and keyboard behaviour.
- Forms: required fields, validation, delivery and error recovery.
- Components: empty, loading, disabled and selected states where relevant.
- Motion: purpose, trigger and reduced-motion behaviour.
- Responsive layout: content order, wrapping and image cropping.
Define the editing model and integrations
List what the client should edit in the CMS and what remains part of the code. A reusable service template may need fields for a title, introduction, features and enquiry link. Agree whether editors can add sections or only change content in fixed layouts.
For each integration, identify the service owner and the expected data flow. Use a secure access-sharing process rather than placing passwords in a brief. Confirm who supplies test accounts and who approves the production connection.
- Editable pages, fields, collections and reusable sections.
- Content limits and behaviour when a field is empty.
- Form recipient and expected notification content.
- Integration owner, test environment and failure behaviour.
Write observable acceptance checks
An acceptance check describes something the reviewer can verify. “The site feels smooth” is subjective. “The menu can be opened and closed with a keyboard, and its links remain usable at mobile widths” gives the team a concrete review task.
Group checks by template and shared component. Include real content lengths so a long heading or email address does not first appear during client approval. Consolidate feedback through one agency contact and agree how new requirements are estimated.
- Check the agreed pages at mobile, tablet and desktop widths.
- Test navigation and forms using a keyboard.
- Test an actual successful enquiry and a controlled failure.
- Confirm links, page titles and any required redirects.
- Check that a client editor can make the agreed content changes.
Agree what transfers at launch
Record who holds domain, hosting, repository and CMS access. State which documentation, editing guidance and source files will be supplied, and who maintains the site after launch.
Refspan can work from agency designs under an agreed white-label scope. Send the handover materials and any open decisions so responsibilities can be settled before development starts.
- Repository and build instructions.
- CMS access and editing guidance.
- Hosting and domain responsibilities.
- Licence ownership and renewal responsibilities.
- Process for fixes, maintenance and new requests.