Implementation Review

The product users get is the code, not the design file. This review runs on the shipped interface, in a real browser, with hostile inputs. It exists because design intent degrades at implementation time in predictable places; the checklist below is those places. Design-review judged the proposal; this judges reality.

Setup

Run the real app, not a storybook. Use the app's real data path (seeded database, staging API), because most of what follows only breaks with real asynchrony and real content.

The passes

Real content. Replace demo data with hostile data: a 120-character name, an amount of 1 234 567,89, zero items, one item, 10 000 items. Truncation, wrapping, overflow, and alignment failures live here. If the design only holds with the demo dataset, it isn't implemented; it's staged.

Localization stress. German labels run 30-50% longer than English: inject them into every button, tab, and table header. Then: RTL direction if the product ships it, non-Latin scripts in user-generated fields, local date/number/currency formats, plural forms beyond singular/plural. A layout that only survives in English is an English prototype, not a shipped interface.

Real viewport. Actual devices or DevTools device mode at 320px, 375px, 768px, plus the awkward in-between widths. Horizontal scroll anywhere is a failure. Then browser zoom at 200%: text must reflow, nothing may clip or overlap. 100dvh behavior with mobile browser chrome, keyboard-open resize on forms.

Real network. DevTools throttled to slow 3G and offline. Does every loading state actually appear, or does the UI blank? Does a failed request show the designed error with its recovery action, or a console stack trace and a spinner forever? Double-submit while the first request is in flight: what happens?

The state matrix, live. Take the feature's declared matrix from interaction-design and trigger each state for real: empty account, revoked permission, expired session, stale cache, partial load. Every declared state must be reachable and match what was designed. A state that can't be triggered can't have been tested.

Keyboard and assistive tech. The full pass from the accessibility skill, on the shipped code: Tab order, focus visibility, Escape behavior, focus return, one VoiceOver run of the changed flow, prefers-reduced-motion actually honored.

Perceived performance. Layout shift on load (skeletons hold the space or they don't), input latency on typing, animation frame drops on a mid-range device. Interaction to visual feedback over 100ms feels broken regardless of what the profiler says.

Design/code drift. Diff the shipped screen against the proposal: spacing values, type sizes, colors, radii. Drift is either a bug to fix or a decision to write back into the design and tokens. Silent drift is how the system stops being true.

Reporting

Each finding: where, the trigger to reproduce, what was designed, what shipped, severity. Blockers are anything that loses user data, dead-ends a flow, or fails an accessibility gate. Everything else ships behind a written follow-up. "Works on my machine with the demo data" is not a pass condition; it's the null result.