CASE STUDY / DESIGN OPERATING MODEL / DESIGN SYSTEMS / DESIGN–ENGINEERING
Designing in code: from representations of products to the product itself
I introduced a design-in-code program so designers could work in the same UI language and
component architecture as the production application. The objective was not to turn
designers into engineers. It was to make the medium of design closer to the medium of the
product.
ROLE
Program Lead · Principal Designer — program design, design system direction, and
design–engineering operating model
SCOPE
Design workflow · design system as shared product language · research fidelity ·
post-development polish
DISCIPLINES
Product design · content design · UX research · frontend engineering
FRAMING
A design operating model, not a tool swap
01 / OVERVIEW
Translation introduces a gap.
Traditional product design workflows create an important separation between the product
designers evaluate and the product customers eventually use. Designers work in graphical
tools, creating representations of interfaces. Those representations are reviewed,
prototyped, tested, approved, documented, and eventually translated into code by
development teams.
A design can look complete while leaving important questions unresolved. We introduced a design-in-code program to close that gap: instead of designing representations of the product and handing them to engineering, designers increasingly worked in the same UI language and component architecture used by the production application.
A design can look complete while leaving important questions unresolved. We introduced a design-in-code program to close that gap: instead of designing representations of the product and handing them to engineering, designers increasingly worked in the same UI language and component architecture used by the production application.
QUESTIONS A FINISHED-LOOKING DESIGN CAN LEAVE UNANSWERED
01
What happens with real content?
02
What happens when there is no data?
03
What happens when there is too much data?
04
How does the interface behave at different viewport sizes?
05
Which components actually exist?
06
How should keyboard interaction work?
07
What happens while data is loading?
08
What happens when something fails?
02 / THE PROBLEM
Visually complete. Behaviourally incomplete.
Graphical design tools make it relatively inexpensive to create an ideal state. A
designer can produce a polished screen without necessarily resolving all of the
conditions required for that screen to work in production. In a graphical workflow, many
of these decisions can be deferred. In code, they become difficult to ignore.
WHAT A "SIMPLE" DATA TABLE ACTUALLY NEEDS TO ACCOUNT FOR
Loading
Empty states
Errors
Long and short content
Pagination
Filtering
Sorting
Permissions
Disabled actions
Different viewport sizes
Keyboard interaction
Accessibility
Validation
Asynchronous behaviour
THIS EXPOSED AN IMPORTANT PRINCIPLE
The constraints of implementation can improve the rigour of design.
Graphical tools make ambiguity inexpensive. Code makes ambiguity visible.
03 / THE PROGRAM
The design system became the bridge.
We created a workflow in which designers could produce functional experiences using the
same design system and frontend foundations available to engineering. Designers and
developers were no longer independently recreating the same interface from two different
representations. Both were composing experiences from a common system.
TRADITIONAL WORKFLOW
01
DESIGN
02
PROTOTYPE
03
VALIDATE
04
HANDOFF
05
INTERPRET
06
DEVELOP
07
DESIGN QA
08
PRODUCT
Handoff, interpretation, and design QA exist to bridge two different representations of the same interface.
DESIGN-IN-CODE WORKFLOW
01
EXPLORE
02
BUILD WITH PRODUCTION UI LANGUAGE
03
TEST REALISTIC BEHAVIOUR
04
REFINE
05
ENGINEER FOR PRODUCTION
06
POLISH TOGETHER
07
PRODUCT
Design and engineering compose from one system. Interpretation shrinks; the final stage becomes polish rather than compliance.
04 / DESIGNING IN THE SAME UI LANGUAGE
A button was not a rectangle with text.
The design system provided designers with the same vocabulary available to developers.
Instead of drawing a representation of a component, designers could work with its actual
behaviours and constraints. The same applied to tables, forms, dialogs, navigation,
notifications, filters, and more complex patterns.
FOUNDATIONS
COMPONENTS
PATTERNS
TEMPLATES
PRODUCT EXPERIENCES
IT WAS A BUTTON WITH
Primary
Secondary
Disabled
Defined variants
Interaction states
Accessibility behaviour
Responsive rules
Supported properties
Production styling
RATHER THAN ASKING ENGINEERING TO
Reproduce what the designer drew.
THE CONVERSATION BECAME
How should these existing product capabilities be composed to solve this problem?
05 / CODE FORCED GREATER DESIGN RIGOUR
Graphical tools make ambiguity inexpensive. Code makes ambiguity visible.
One of the unexpected benefits was that designing in code changed the quality of design
thinking. Building the experience forced questions into the design process earlier. The
prototype became a way of discovering requirements, not simply communicating a proposed
solution.
A STATIC DESIGN MIGHT CONTAIN
John Smith
A FUNCTIONING PROTOTYPE IMMEDIATELY ASKS
John Smith
EXPECTED
Alexandra Catherine Montgomery-Smith
LONG VALUE
李伟
SCRIPT AND WIDTH
No preferred name
STATE
—
MISSING VALUE
THE CARD
looks excellent with three carefully selected sentences but fails with three paragraphs of real content.
THE DASHBOARD
works perfectly at 1440px but becomes unusable at 1024px.
THE FORM
looks complete without defining validation, errors, loading, submission, or success behaviour.
06 / CONTENT BECAME PART OF DESIGN
Content became an input, not an insertion.
Traditional workflows often introduce realistic content after the structure of an
interface has already been established. Designing in code made content much harder to
treat as placeholder material. Designers could see where the interface was fighting the
content rather than supporting it. This moved content design upstream.
WE COULD QUICKLY EVALUATE
Realistic names and labels
Short and long values
Missing information
Localization
Error messages
Help content
Instructions
Large datasets
Unexpected data combinations
INSTEAD OF
Layout → Components → Content
WE INCREASINGLY WORKED TOWARD
User need + content + interaction
→ Responsive composition
→ Responsive composition
07 / RESPONSIVE DESIGN HAPPENED BY DEFAULT
Real interfaces exist across a continuum.
A graphical workflow often treats responsive layouts as additional deliverables:
desktop, then tablet, then mobile. Designing in the browser meant resizing the
experience continuously and seeing where the design naturally failed. Responsive
behaviour became part of the architecture of the solution rather than a set of screens
produced later.
THE QUESTION CHANGED FROM
What should the mobile version look like?
TO
How should this experience behave as the available space changes?
DESIGNERS BEGAN THINKING EARLIER ABOUT
Fluid layouts
Min and max widths
Wrapping
Density
Priority
Overflow
Progressive disclosure
Responsive navigation
Touch targets
Content hierarchy
360px
768px
1024px
1440px
08 / MORE REALISTIC PROTOTYPES, BETTER RESEARCH
Fidelity was not merely visual fidelity.
Traditional prototypes are effective for many research questions, but their simulated
nature can affect participant behaviour: predetermined paths, artificial data, and
interactions that only work when the test follows the expected scenario. Code-based
prototypes let us test experiences much closer to the intended product. Rather than
testing whether users understood a sequence of screens, we could observe how they
interacted with a functioning system.
PARTICIPANTS COULD
Enter unexpected information
Resize interfaces
Navigate naturally
Make mistakes
Encounter validation
Interact with realistic datasets
Use keyboard controls
Explore beyond a prescribed happy path
THE FIDELITY INCLUDED
CONTENT FIDELITY
+
INTERACTION FIDELITY
+
BEHAVIOURAL FIDELITY
+
RESPONSIVE FIDELITY
+
SYSTEM FIDELITY
Feedback that was often far more representative of the eventual production experience.
09 / FROM DESIGN QA TO PRODUCT POLISH
The product, not the design file, became the source of truth.
In a traditional workflow, designers can become inspectors of the finished
implementation, raising bugs against developers for deviations from an artifact those
developers had to interpret. Designing in code reduced the amount of interpretation
required and, more importantly, changed the purpose of post-development design
involvement. The final stage became product polish rather than design compliance.
REVIEW AGAINST THE ARTIFACT
"This spacing is incorrect."
"This component doesn't match."
"This breakpoint isn't what was designed."
"This state is missing."
INSTEAD OF PRIMARILY ASKING
Did engineering reproduce the design correctly?
DESIGNERS COULD ASK
Now that this is working with real data and real behaviour, how do we make it
better?
DESIGNERS AND ENGINEERS COULD IMPROVE TOGETHER
Transitions
Hierarchy
Density
Content
Edge cases
Responsiveness
Accessibility
Interaction feedback
Perceived performance
Overall coherence
10 / CHANGING THE ROLE OF THE DESIGN SYSTEM
From consistency layer to shared product language.
Previously, the design system primarily helped maintain consistency between design and
development. Now it became a shared product language. Improvements made by one
discipline could propagate through the system. The design system therefore became
infrastructure for collaboration, not merely consistency.
DESIGN SYSTEM
DESIGN
RESEARCH
ENGINEERING
PRODUCT
FROM DESIGN
If designers repeatedly needed a capability that did not exist, that was evidence of a potential addition to the design system.
FROM ENGINEERING
If developers identified technical limitations in an existing pattern, those constraints became visible during design rather than after handoff.
THE OUTCOME
The design system became infrastructure for collaboration, not merely consistency.
11 / A NEW DESIGN–ENGINEERING RELATIONSHIP
Specialization stayed. The boundary moved.
Designing in code did not eliminate specialization. Designers remained responsible for
understanding users, framing problems, information architecture, interaction design,
content, accessibility, research, visual hierarchy, experimentation, and experience
quality. Engineers remained responsible for production architecture, reliability,
performance, maintainability, security, and technical implementation. What changed was
the boundary between them.
INSTEAD OF
DESIGN
PROBLEM
RESEARCH
DESIGN
PROTOTYPE
ENGINEERING
INTERPRET
IMPLEMENT
TEST
DEPLOY
HANDOFF — A PHASE BOUNDARY, THEN INTERPRETATION
WE MOVED TOWARD SHARED PRODUCT DEVELOPMENT
UNDERSTAND
EXPLORE
PROTOTYPE IN PRODUCT LANGUAGE
VALIDATE
ENGINEER
POLISH
MEASURE
IMPROVE
Design became less of a phase that happened before development and more of a capability embedded throughout product development.
12 / WHAT CHANGED
Changes across the whole development lifecycle.
The program changed how designs were expressed, how edge cases surfaced, where content
and responsive behaviour entered the process, what research could test, how teams built,
and what design did after development.
BEFORE
DESIGNING IN CODE
Designs represented components
Designs used the product's UI language
Happy paths were inexpensive
Edge cases surfaced naturally
Content followed layout
Content shaped the solution
Responsive states were separate artifacts
Responsive behaviour was inherent
Prototypes simulated behaviour
Prototypes increasingly behaved like products
Research tested representations
Research tested realistic interactions
Developers translated designs
Teams composed from shared foundations
Design QA identified deviations
Designers helped polish working software
Design file was the reference
The product became the source of truth
13 / THE RESULT
Not a faster handoff. The removal of much of the handoff itself.
Design decisions were being made closer to the environment in which those decisions
ultimately had to survive. That produced a tighter feedback loop, and after development,
design effort could be spent improving the actual experience rather than auditing
whether engineering had reproduced a picture.
RATHER THAN
THINK
REPRESENT
DOCUMENT
HANDOFF
INTERPRET
BUILD
COMPARE
A TIGHTER FEEDBACK LOOP
THINK
BUILD
EXPERIENCE
TEST
LEARN
REFINE
DESIGNERS
encountered implementation realities earlier.
DEVELOPERS
received solutions with more behavioural thinking already resolved.
RESEARCHERS
could evaluate more realistic experiences.
CONTENT & RESPONSIVE
became first-class design inputs.
[ADD VERIFIED METRICS — e.g. design QA defects per release, time from concept to working
prototype, research sessions run on functioning prototypes, design system contributions
by discipline]
14 / THE BROADER LESSON
Design tools fundamentally influence how designers think.
Graphical tools make it possible to explore ideas rapidly and remain invaluable for
early exploration. But their freedom can also allow important product constraints to
remain unresolved. Code introduces constraints, but those constraints can be productive:
they force the design to confront content, behaviour, responsiveness, accessibility,
state, and variability much earlier.
THE GOAL WAS NOT
"Designers should code."
IT WAS
Design should happen as close as practical to the material from which the final
product is made.
By giving designers access to the same UI language used in production, we moved from designing pictures of software toward designing software itself. That shifted the measure of design quality from how accurately development reproduced the design to how effectively the final product worked for its users.
NEXT / 03 ORGANIZATIONAL DESIGN
From urgent requests to value-aligned design workstreams
Discuss a design operating model or design-in-code program
Start a conversation