Design and engineering belong in the same room

When design 'hands off' to engineering, every gap in the spec becomes a guess. Edge cases, error states, empty states, loading behavior, focus order, and responsive rules get decided ad hoc under deadline pressure.

The result looks roughly like the mockup and feels nothing like it, because the details that make an interface feel right, the 150ms of easing, the way a form recovers from an error, the skeleton that holds layout while data loads, were never the ones in the static frame.

A static mockup is maybe 60 percent of the information needed to build the screen well. The rest is a conversation.

We treat design and engineering as a single ongoing conversation. Designers work within real technical constraints, and engineers weigh in early, while changes are still cheap.

The rituals that make this concrete:

• Kickoff together: designer and engineer scope the feature in the same session, before high-fidelity design starts, so constraints and edge cases are named up front.
• Design review with engineering present: not a sign-off, a working session where the engineer flags what is expensive and proposes cheaper equivalents.
• Build-along: the engineer starts implementing the happy path while design is still refining secondary states, so feedback is immediate.
• Shared definition of done that includes error, empty, loading, and responsive states, not just the default view.

A shared component library turns design decisions into reusable, coded building blocks. Designers compose from the same parts engineers build from, so what is designed is genuinely what ships.

The connective tissue is design tokens: colour, spacing, typography, radius, and motion values defined once and consumed by both the design tool and the codebase. When the palette changes, it changes in one place and flows to both sides. This is what stops the slow drift where the built product is 'close enough' but subtly off-brand a year later.

It also speeds everything up: the tenth screen is far faster than the first because most of it already exists, tested, accessible, and consistent.

When engineering builds a component, its props are an interface that shapes what design can express. A button that only supports two variants quietly rules out a third. Designing the component API together, which variants, sizes, and states exist and what they are called, keeps the system expressive enough without becoming a mess of one-off props.

The rule we use: a new variant is added to the system deliberately, with a name and a use case, or it is not built at all. Ad hoc overrides are where design systems rot.

Accessibility lives here too. Focus management, keyboard behavior, and ARIA semantics are built into the component once, so every screen that uses it inherits them.

Builds get faster, handoff friction disappears, and the product reaches users looking and behaving the way it was meant to. Rework, the second and third pass because the first build missed the intent, drops sharply.

Just as importantly, the team stops pointing fingers across a wall, because there is no wall. Designers understand why something was expensive; engineers understand why a detail mattered.

Measure it by the gap between the design and the shipped screen, and by how often a feature needs a follow-up polish pass. Both should trend toward zero.

For anything with meaningful interaction, motion, drag, real-time updates, dense data, a static design tool stops being enough. The fastest way to get it right is to prototype in code, in the actual framework, early and roughly.

A scrappy coded prototype answers questions a mockup cannot: does this animation feel good at 60fps on a mid-range phone, does the layout hold with real content lengths, is the interaction actually discoverable. It costs a day and saves a week of build-then-redo.

Designers do not have to write the prototype, but they should be in the loop tightly enough to react to it while it is still cheap to change.

Even with a shared system, the built screen and the design slowly diverge under deadline pressure. A short review at the end of each feature, design and engineering looking at the real thing side by side with the mockup, catches it while it is a five-minute fix.

Visual regression tests help for the component library: a screenshot diff on every pull request flags an unintended change to a shared button or input before it spreads.

The metric to watch is the follow-up polish pass. If most features need one, the conversation is happening too late.