The classic workflow separated thinking from execution. A designer produced screens. An engineer translated them. Product intent passed through tickets, annotations, meetings, and memory until a working interface appeared.
The screen can look right after the intent is already gone. How does the component behave while loading, blocked, or wrong? What must stay stable? Who decides when nobody wrote it down? Faster implementation is making that loss harder to hide.
The handoff model is breaking
Code agents can now turn design artifacts into components quickly. If the artifacts contain only pixels, the agent has to guess the logic, state model, accessibility behavior, copy, edge cases, instrumentation, and extension rules. Those guesses compound into drift.
The question is no longer whether design can reach production. It’s whether the reasoning survives the trip.
Frontend choices are product choices
Loading behavior changes perceived reliability. Navigation changes discovery. Empty states affect onboarding. Error recovery changes trust. State preservation affects retention. Motion can clarify causality or create confusion. Microcopy decides whether an uncertain AI feels honest or evasive.
These aren’t implementation details added after the “real” design. They’re the product experience. Even “AI safety” moves from a backend engineering concern to a frontend experience concern. Safety isn’t only about preventing the model from generating harmful outputs. It’s about preventing the user from feeling surprised, betrayed, or disempowered by autonomous behavior.
A Front-End Design Engineer holds interface, code, and system at once. The role connects visual decisions to activation, conversion, retention, performance, accessibility, and maintainability.
The guiding question isn’t “Does it match the mockup?” It’s “Does this earn trust, teach itself, and stay coherent as the product grows?”
Strong handoffs explain intent, not just what to build
Most handoffs describe what to build. Strong ones also explain the reasoning, so a person or an agent can build it without guessing.
A contract card is a short handoff that says what a component promises to do.
Fill-in card
Deliver intent, not output
Explain each of these in the handoff, along with what to build.
- Why
- why this behavior exists.
- When
- when to use it and when not to.
- What can vary
- what can vary and what must stay stable.
- How it behaves
- how it behaves while loading, empty, blocked, wrong, or complete.
- What happens
- what happens with long content, reduced motion, keyboard use, localization, or weak connectivity.
- Which event
- which event shows that the product created the intended shift.
- How it extends
- how another human or agent can extend it without forking the logic.
In Figma, that means structured components, tokens, states, examples, and annotations. In code, it means architecture decisions, constrained APIs, extension patterns, tests, and ownership.
Both halves should describe the same source of truth.
The action preview and consent pattern shows a proposed change before the agent commits it.
Example
Deliver intent, not output: action preview and consent
An agent is about to change or send something. The user needs a preview and a deliberate way to consent before the change is committed.
- Why: a preview gives the user a chance to catch the mistake before it is committed.
- When: any AI action that modifies user data, sends external communications, or has consequences that can’t be easily reversed. Not for low-stakes, high-frequency actions where the preview would create more friction than value.
- What can vary: consent can be a button click, a keyboard shortcut, or a voice command—but it must be deliberate and reversible. The preview must stay exactly what will happen upon execution.
- How it behaves: preview, then explicit consent, then visible execution. The user sees the result immediately and can undo it if it doesn’t match the preview.
- What happens: Not known yet: How should the preview and consent work with long content, reduced motion, keyboard use, localization, or weak connectivity?
- Which event: Not known yet: Which event would show that the preview and consent created the intended shift?
- How it extends: Not known yet: How can another human or agent extend the preview and consent without forking the logic?
Stickiness is a system property
Trust begins before signup, changes during first use, deepens through recovery, and either compounds or erodes with repeated interaction. A sequence of individually attractive screens can still produce a disjointed arc. If the same risk uses different patterns across features, the product lacks a system.
Front-End Design Engineering maps the experience across touchpoints.
Fill-in card
Design the arc, not isolated screens
Ask each question of the arc, not of isolated screens.
- Value
- where the user recognizes the value.
- Relief
- where relief first appears.
- Effort
- where effort spikes.
- Explanation
- where the system needs to explain itself.
- Re-entry
- how the user re-enters later.
Instrumentation belongs beside the UI decision
If the team can’t measure the behavior it designed, it won’t know whether the interface worked.
Define the event taxonomy, funnel, error signal, and acceptance criteria while designing the flow. Measure time to first relief, repeated correction, recovery, feature discovery, and accepted results—not only clicks.
A production-ready design test
Before calling a feature ready:
0 of 8 done
