Make the design source inspectable
A polished frame is not ready for implementation until its system can be read without guessing. The useful unit of analysis is tokens, type scale, spacing, component anatomy, states, content, icon rules, media treatment, responsive behavior, and motion. Engineers need explicit relationships and representative states, not only ideal desktop screenshots. That distinction matters because a polished interface or familiar brand can hide the operating condition that determines whether the route works. Treat unresolved behavior as a product question and answer it before handoff. The review should leave an attributable record rather than a memory of what the page or demo appeared to say. Publish a small design inventory beside the accepted frames. This sequence keeps the decision testable by another person and makes later changes easier to audit.
- Include loading, empty, error, focus, and reduced-motion states.
- Use real copy at realistic lengths.
- Identify which assets are final and who owns their rights.
Choose the implementation route by ownership
A visual site builder and a coded application solve different maintenance and behavior problems. Start by examining content ownership, interaction complexity, data, authentication, accessibility, localization, release frequency, engineering capacity, and rollback. The relevant Webflow, Framer, or coded route depends on who must safely change the product after launch. The purpose is not to reward the product with the longest feature list; it is to see whether a specific team can complete a specific job while preserving evidence, access, and recovery. Choose the simplest route that preserves required behavior and accountable long-term ownership. Write the boundary before the trial so a convenient success cannot erase a serious failure. Prototype one representative complex component in the candidate route before committing. Keep the observed result, source date, owner, and unresolved questions together.
- Do not choose from screenshot similarity alone.
- Test content editing and permissions with the future operator.
- Include export, integration, and migration boundaries.
Translate frames into components
Production should encode repeated relationships rather than reproduce every frame as a one-off composition. In practice, the review covers semantic structure, reusable primitives, explicit variants, data boundaries, stable dimensions, keyboard behavior, and accessible names. Shared components reduce drift only when their variants reflect the accepted design instead of forcing unrelated surfaces into one card. These details turn a general product claim into an operating test with a clear input and output. Create a component when a relationship repeats; keep unique editorial moments deliberately unique. Unknown conditions should remain visible instead of being converted into confident prose or a synthetic score. Review each component against the source frame before building the next section. A second reviewer should be able to reconstruct why the team accepted, restricted, postponed, or rejected the route.
- Keep UI text and controls code-native.
- Do not ship screenshots as working interfaces.
- Avoid generic components that erase the approved container model.
Verify behavior across viewports
Responsive design is a set of decisions about priority and flow, not a command to shrink the desktop canvas. The control surface here is first viewport, reading order, local scrolling, line length, image crop, navigation, tables, focus movement, touch targets, and 200-percent layout. Breakage often appears between familiar device presets or when translated copy and browser zoom increase density. Procurement and workflow design meet at this point: commercial access is valuable only when the required behavior and responsibility exist in the purchased plan. Reflow secondary regions before primary work clips and keep horizontal scrolling local to true tables or navigation rails. Document exceptions because they become the hidden source of extra tools and unsafe workarounds. Capture desktop, narrow desktop, mobile, and enlarged-layout evidence during implementation. The result should describe both the normal path and what happens when the service, network, data, or responsible person is unavailable.
- Check document-level overflow after every major section.
- Test real long titles and localized labels.
- Verify touch, keyboard, and reduced motion separately.
Release through evidence gates
A successful build proves that artifacts were created; it does not prove that the accepted experience reached production. A credible comparison therefore measures focused tests, full verification, asset integrity, accessibility, performance, browser evidence, immutable release identity, candidate health, and rollback. Each gate answers a different question and must be recorded against the same candidate revision. List price or output appearance cannot carry the entire decision because change work, permissions, rights, and review obligations remain part of the system. Do not switch traffic when a required gate is missing, ambiguous, or measured against another build. Keep known values separate from unknown values and do not use invented precision to make uncertainty look resolved. Deploy to the inactive slot, run smoke checks, then switch and recheck the public edge. Review the result against the same acceptance criteria used at the start.
- Record the revision and asset digest.
- Keep the old slot available during acceptance.
- Automatically restore routing when a cutover check fails.
Close the design-production loop
The final comparison should use the accepted concept and the actual browser render at matching dimensions. The release decision brings together copy, hierarchy, typography, palette, spacing, asset treatment, icons, interaction, responsive behavior, console health, and the core workflow. Automated tests catch contracts while direct visual inspection catches the drift that users actually see. This is where a research note becomes an accountable operating choice rather than a recommendation that nobody owns. Fix every agency-review issue that is still actionable and document only genuine intentional deviations. Preserve the source snapshot and local test so future reviewers can distinguish vendor change from an internal workflow change. Archive a fidelity ledger, implementation screenshots, release identity, and post-cutover observation. Set a fresh evidence date and a rollback trigger; a decision that cannot be revisited safely is incomplete.
- Compare at the concept's native viewport when practical.
- Inspect generated assets for cropping and broken paths.
- Reopen the primary interaction after deployment.