Design-to-Code Handoff and QA Checklist

A design-to-code handoff is the transfer of decisions, not the transfer of screens. Production teams need to understand the system behind the approved design: responsive rules, content variance, component states, accessibility behaviour, performance priorities, and the exact standard used to accept the build. A complete handoff reduces interpretation without pretending every edge case can be designed in advance.

Use this checklist before production starts and again before the agency accepts the final candidate.

1. Confirm the source of truth

Name one approved design source, one scope source, and one feedback channel. If files are duplicated across tools or messages, record which version wins.

The handoff record should identify:

• approved design file and version;
• sitemap or route list;
• component inventory;
• final or representative content source;
• integration specification;
• issue tracker or review board;
• agency approver and production owner.

Archive exploratory pages or label them clearly. Production should not have to infer whether an old frame is an alternative, a rejected direction, or an unrecorded requirement.

2. Describe responsive intent

Desktop and mobile screens do not explain what happens between them. For every major component, describe which properties are fixed, fluid, wrapped, reordered, hidden, or replaced.

Ask these questions:

• What is the minimum useful width?
• When does a horizontal group stack?
• Can labels wrap to two or three lines?
• What happens with a very long name or translated CTA?
• Is media cropped, contained, or art-directed at each range?
• Does the reading order remain logical after visual reordering?
• Which elements disappear, and is their information available elsewhere?

Use real extremes: the shortest and longest navigation labels, an empty CMS field, a portrait image where landscape was expected, and a heading twice the approved length. A robust component should fail visibly during staging, not quietly after launch.

3. Inventory every interactive state

A default screen is only one state. Include hover, focus, active, disabled, loading, empty, error, success, expanded, collapsed, and validation states where relevant.

For forms, specify:

• required and optional fields;
• input types and autocomplete intent;
• inline validation timing;
• server-error behaviour;
• success confirmation;
• duplicate-submission protection;
• keyboard focus after an error or success;
• consent and privacy copy;
• destination and owner of submitted data.

For navigation, document current-page treatment, keyboard order, mobile opening and closing, escape behaviour where applicable, and focus visibility.

4. Translate the visual system into tokens

Before building pages, align on reusable decisions:

• type families, sizes, weights, line heights, and letter spacing;
• spacing scale and section rhythm;
• colour roles, not only colour values;
• border, radius, and shadow rules;
• layout widths and gutters;
• motion duration, easing, reduced-motion behaviour;
• icon source and sizing;
• image aspect ratios and focal-point rules.

Tokens should express intent. text-muted is more maintainable than a collection of unrelated grey values. space-section is easier to adjust than page-specific margins. The naming does not need to be elaborate; it needs to prevent accidental variants.

5. Define the content model before templates

If the site uses a CMS, approve the content model before multiplying templates. List each content type, its fields, validation, relationships, localization behaviour, and editorial ownership.

Avoid a single unrestricted rich-text field when content must appear consistently in cards, search results, schema, social previews, or multiple layouts. Conversely, do not fragment simple editorial content into dozens of fields that make publishing painful.

Test the model with real examples and edge cases. The right question is not “Can the CMS store this?” but “Can an editor publish this safely without a developer?”

6. Establish accessibility acceptance

Accessibility is a production requirement, not a final plugin scan. The W3C organizes WCAG around content being perceivable, operable, understandable, and robust. Its WCAG 2.2 overview is a useful shared reference, while the normative standard remains the authority for conformance.

At minimum, verify:

• semantic landmarks and heading order;
• meaningful alternative text and decorative-image handling;
• keyboard access to all functionality;
• visible focus states;
• logical focus order;
• labels, instructions, and error identification;
• colour contrast in every state;
• zoom and reflow at narrow widths;
• reduced-motion preferences;
• names and states exposed correctly to assistive technology.

Automated tools catch only part of this. Include manual keyboard testing and at least one screen-reader pass on critical flows.

7. Set a performance budget

Performance becomes manageable when it is an acceptance condition. Record budgets for images, fonts, third-party scripts, and JavaScript where the project warrants them.

Core Web Vitals measure loading, responsiveness, and visual stability through LCP, INP, and CLS. The official web.dev thresholds define “good” as LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1, evaluated at the 75th percentile of visits.

Treat laboratory tests as diagnostics, not proof of field performance. Test representative pages on mobile conditions, then monitor real-user data after launch when sufficient traffic exists.

Check:

• hero and content image dimensions, formats, and loading priority;
• font files, weights, subsets, and fallback behaviour;
• third-party scripts and consent behaviour;
• route-level JavaScript and long tasks;
• layout space reserved for asynchronous content;
• caching and rendering strategy;
• behaviour on slower devices and networks.

8. Build one representative vertical slice

Do not wait for the entire site to test the system. Build one route that includes the hardest typography, media, CMS content, interaction, and responsive behaviour.

Review this slice for fidelity and architecture. If every section needs an exception, the component model is wrong. If the build matches one viewport but breaks with real content, the responsive rules are incomplete. Correct the system before scaling it.

9. Consolidate review feedback

The agency should return one prioritized review set per gate. Each item needs a location, expected result, evidence, and classification.

Use four classes:

• blocker: prevents acceptance or launch;
• defect: fails an agreed requirement;
• change: alters the agreed requirement;
• observation: worth recording but not required for this release.

Screenshots help, but they should not replace a written expected result. “Looks wrong” creates another interpretation loop.

10. Run the production-candidate checks

The official Next.js production checklist is a useful technical reference even when the broader QA process covers other platforms. Adapt the following release groups to the selected stack:

Content and SEO

• final titles, descriptions, headings, canonicals, and language alternates;
• sitemap and robots directives;
• redirect map and 404 behaviour;
• social preview metadata;
• structured data validated against visible content;
• no placeholder, staging, or confidential copy.

Functional and visual QA

• agreed browsers and viewport ranges;
• forms, integrations, notifications, and error paths;
• navigation, search, filters, and dynamic states;
• CMS preview and publishing workflow;
• print or sharing behaviour where required.

Security and operations

• least-privilege access;
• secrets stored outside the repository;
• dependency and vulnerability review;
• security headers and HTTPS behaviour;
• backups, rollback, monitoring, and incident owner.

Handover

• repository and deployment access transferred;
• CMS and third-party accounts assigned;
• environment inventory documented;
• known limitations recorded;
• launch acceptance named and dated.

A handoff is complete when decisions are transferable

The goal is not to eliminate every question. It is to ensure questions reach the right owner early, and that the final system can be understood without relying on the memory of one designer or developer.

If you need a partner to execute this workflow behind your agency, send a private production brief. Promto Studio can work within your design source, review process, repository, and handover requirements.