Handoff without acceptance only delays the argument to QA
“Design is done” and “dev matched design” often hide a round of pixel debates, missing states, and broken breakpoints. Acceptance criteria turn a Figma link into a checkbox Definition of Done: which frames are source of truth, which tokens map to code, which interactions must be clickable, what is explicitly out of scope. At KSX Studio, discover→design→build→launch requires a versioned design freeze, a staging checklist, and a named visual QA signer. Whether a Weaverine-class brand site or a marketing-plus-app hybrid, weak handoff only moves cost into QA and launch week. Below: shared acceptance dimensions and a writing template.
Freeze scope: page list and out-of-scope
Line one of acceptance: URL/route list for this iteration, locales, auth state, CMS-editable regions. A separate “explicitly out of scope” column: motion phase two, dark theme, a browser, an edge business flow. Scope creeps hardest via “while we’re here, tweak global nav.” Bind page priority to business outcomes in discovery; the design freeze meeting outputs a dated page list pinned in the project channel. Without a scope table, no acceptance debate has a referee.
Source of truth: file, version, naming
Name one source file (or library) and a version tag such as `brand-site@1.4-freeze`. Ban archaeology via chat (“the version I sent”). Align component names with engineering (Button/Primary, not “big blue button”). Archive dead frames so dev never opens an old Page. Document who can edit and how change requests work (new branch/version—not silent edits on freeze). For remote clients, share read-only links; edit rights stay with the design lead.
Components and tokens: mappable to code
Acceptance is not only “looks close”—tokens and components must map to code: color/type/space/radius/shadow from one token set; variants (size/state/tone) cover combinations used this iteration. If eng already uses shadcn or an internal kit, mark reuse / extend / new for each decision to avoid parallel components. Icon and illustration export rules (SVG, 2x raster) go on the checklist. Cross-link design-system handoff docs so marketing and product UI do not invent two spacing systems.
State coverage: empty, error, loading, auth
Each critical flow needs at least: default, loading, empty, validation error, server error, success, unauthorized/logged-out. Forms also need disabled and submitting. Missing states are the main QA bomb. Checkbox “designed / built / tested” in a table—never “dev will figure it out.” For B2B lead forms and Web3 wallet connect, error copy must be product- and legal-readable, not only a red border. Prefer clickable prototypes on the happy path; static frames need interaction notes.
Responsive and breakpoint acceptance
Document the breakpoint set and the source of truth: if eng uses default Tailwind breakpoints, design frames to that set—not arbitrary 1280/1440. Mobile acceptance includes nav collapse, table strategy, touch targets, and form position when the keyboard rises. Do not only stretch a centered container on large screens. Mark crop-safe areas for image/video on small screens. Stage-test on real devices and browser device mode; record minimum devices and browsers on the checklist to match contract scope.
Accessibility and realistic content
Contrast, focus order, alt-text policy, skip link, and form labels belong in design notes. Stress-test with real-length copy (zh/en), not “title title” placeholders—Chinese wrapping and English length change hierarchy. Case and stats modules need CMS max lengths so ops cannot break layout post-launch. Immersive pages (Taiji Zen-class) need a reduced-motion static fallback. Accessibility baseline is acceptance, not “if we have time.”
Specs, redlines, and eng question log
Auto-specs do not replace human redlines on critical spacing and alignment. Complex stacking (sticky headers, layered modals, scroll-linked motion) needs written intent and z-index notes. Keep an eng question log: design answers in 24–48h; after that, eng implements per notes and logs assumptions. Changes use a light change ticket: pages hit, token impact, whether visual QA re-runs. Emoji reactions in chat are not acceptance.
Staging compare and sign-off ritual
On staging, open freeze frames beside implementation: walk happy and error paths per the page list. Severity: P0 ship-blocker, P1 within 48h of launch, P2 next iteration. Design lead signs visual QA; product signs copy/flow; eng signs performance and APIs. KSX uses preview deploy links for client review so screenshots do not lie. Post-sign-off edits default to a change ticket. To embed design acceptance in a fixed delivery cadence, write Definition of Done and weekly checks in discovery so launch-night debates shrink.
Checklist
- 1Dated page/route list with an explicit out-of-scope column
- 2Source file version tag frozen; obsolete frames archived
- 3Empty/error/loading/auth states designed and checkbox-tracked for critical flows
- 4Breakpoints match eng framework; real-device staging spot-check done
- 5Staging visual QA done with design/product/eng notes on record
Key takeaways
- Acceptance criteria are Definition of Done—not a post-hoc taste debate
- State and breakpoint coverage predict ship quality better than a pretty homepage match
- Changes must be versioned; editing freeze in place voids acceptance
FAQ
- Can we write acceptance without a full design system?
- Yes. Freeze the subset of color/type/component variants used this iteration, mark temporary tokens, and schedule promotion into the system later. Acceptance targets shipped pages—not a complete system in one pass.
- What if the client keeps asking for “one more tweak”?
- Point to the signed freeze and change tickets: polish goes to P2 or a paid scope add. Separate defects (failed acceptance) from preference changes (new scope). Report open change count weekly so rework stays bounded.
- How do we settle “fidelity” disputes between design and eng?
- Agree tolerances up front: 2–4px spacing, token colors, final web-font rendering. Raise the bar on brand-critical zones (hero, pricing, nav); allow eng optimization on long lists. Escalate to the project lead against the checklist—not a chat vote.