The gap between design and engineering is rarely a physical distance; it is a structural divide. It is the friction that turns a “perfect snapshot” in Figma into a brittle, illogical system in the browser. Bridging this space requires moving beyond static assets and into the shared logic of orchestration.
The gap
The word “handover” implies a finished product is being delivered, but in software, a handover is usually just the delivery of a perfect snapshot.
In my ten years of navigating the gap between the canvas and the codebase, I’ve seen the traditional handover fail for three fundamental reasons:
The Perfect State
A Figma represents a singular, idealised moment in time - no loading states, no network latency, and perfectly curated data lengths. But engineers don’t live in the “perfect moment.” In fact, engineers usually start with the edge cases. The work begins with the errors, the empty states, and the boundary conditions. The “perfect snapshot” is often not even reached until the very end of the implementation cycle, if at all.
This disconnect is where projects begin to rot. When a design is built only for the ideal, the technical constraints of the edge cases start to feel like “hacks.” The layout breaks, the logic becomes strained, and the final product begins to feel illogical because the foundation was built on a static lie rather than a dynamic reality.
The Context Gap
Design is a language of intent, but code is a language of implementation. Engineers often don’t see the “why” behind a 4px margin or a specific typographic scale. Without that design context, they understandably optimise for code efficiency or component reusability over user experience. When the “why” is stripped away, the product loses its soul - the spacing becomes inconsistent, the hierarchy flattens, and the intentionality of the design evaporates.
The Lost Intent
Conversely, the “cost” of a design is often invisible until the first line of code is written. A simple hover effect might be three lines of CSS, but a complex layout shift might require a complete architectural rethink. Because the handover is treated as a one-way street, designers often spend days perfecting interactions that are technically prohibitive, while engineers miss opportunities to suggest simpler, more robust alternatives that achieve the same goal.
This list of failures could continue indefinitely, but the root cause is singular: a legacy of extreme domain isolation. In the early stages of a career, this hyper-focus is a virtue. It is exactly what makes us deep specialists and likely what got us to where we are today.
How do we move from “delivering assets” to “building systems”?
The Orchestrator’s Approach
Instead of a handover, I advocate for Co-authoring.
The “Orchestrator” isn’t just a bridge; they are a Systems Analyst who sits at the intersection of possibility and constraint. Co-authoring means the engineer is involved when the canvas is still blank - not to say “no,” but to define the parameters of the system. And designers need to be involved when the first line of code is written - not to say “yes,” but to ensure that the intent is preserved as the system takes shape.
Fig. 1: Transitioning from domain isolation to the Co-Authoring Zone, where system logic is defined before pixel execution.
- State-First Design: Moving from “How does this look?” to “How does this behave when the API returns a 404, or when the user has 500 items in a list meant for five?”
- The Component Contract: Co-authoring establishes a shared contract between visual intent and data structure. It ensures that the props we pass into a component aren’t just cosmetic “overrides,” but are architecturally sound representations of the underlying data. To achieve this, the barrier between the API and the Canvas must be porous. Designers need to move beyond the aesthetic and into the logic of the payload - understanding the shapes, types, and constraints of the data being returned.
The “Bridge” isn’t a metaphor; it’s a technical requirement. When a design leaves a static tool and enters a codebase, it transitions from an image to a system.
Examples:
Designing the Logic, Not Just the Look
In a static file, a “button” is a rectangle with text. In a codebase, a button is a complex state machine: loading, disabled, focused, active, hover etc.
- The Reality: Most handovers provide the “default” (happy path) state only, leaving the logic to be improvised during development.
- The Shift: The logic of the component must be established before the CSS is ever touched. If the state machine is broken, the most polished UI cannot save the user experience.
Fig. 2: Button states visual - a component is not a rectangle; it is a complex map of possibilities, transitions, and exceptions.
The Physics of the Grid
Designers often treat the grid as a playground; engineers treat it as a constraint.
- The Reality: A 12-column grid in Figma is a static arrangement. In the browser, it is a dynamic system that must adapt to content of varying lengths, screen sizes, and user interactions.
- The Shift: The goal is the construction of Resilient Layouts. This moves beyond “matching the mockup” to building a layout system that can shrink, grow, and fail gracefully without compromising the intended visual hierarchy.
Fig. 3: A static 12-column idealization (top) contrasted with engineered, fluid reality (bottom), where logic handles layout shift and dynamic content without compromising the layout contract.
The Architecture of Elegance
In my ten years of building, I’ve realized that hard-to-develop code is usually a symptom of bad UX. Engineers often blame “spaghetti code” on poor engineering, but technical debt is frequently born from Logical Debt in the design. If it feels like you are fighting the framework to implement a specific interaction, there is a fundamental misalignment between the User Intent and the System Architecture.
1. The Physics of the Framework
True elegance happens when the design respects the “physics” of the framework. When a layout aligns with the natural flow of CSS Grid or the state-management patterns of the framework, the code becomes clean. If the design is “unnatural” to the web, the code becomes a series of imperative workarounds.
2. Technical Empathy
Elegance is the result of Technical Empathy - designing with an understanding of how data flows through a system. When a designer understands that a layout shift has a performance cost, or that a specific font weight impacts CLS (Cumulative Layout Shift), the resulting UX is built with skill and mind.
3. The Smoothness of Logic
You know when a UX has been made with skill because the transition from one state to another feels smooth - not just for the user, but for the developer. When the information architecture matches the data structure, the components practically write themselves.
Elegance in code is the direct result of clarity in design.
The Learning Manifesto
Ten years in, and I am still a student of the gap.
The industry wants us to pick a side - to be the “Pixel Whisperer” or the “System Architect.” But the most interesting work doesn’t happen at the poles; it happens in the friction between them. It happens when we stop treating the handover as a finish line and start treating the codebase as the final, living canvas, when we start to treat the friction between Engineering and Design as a creative tool rather than a barrier. The hard part is to keep both sides engaged.
This blog isn’t a collection of best practices or a gallery of “solved” problems (at least not yet). It’s a public notebook for a perpetual learner. It’s where I’ll be documenting the struggle to find elegance in the architecture and logic in the design.
I am still figuring out where the boundaries are.