Working with engineering
A shared language
How I hand off designs so any stakeholder can build from them.
Topic
Working with engineering
Reading time
3 minutes
Covers
Handoff, naming, design QA
Visuals
Original illustrations
Specs
Button
1
Padding
space-20 sides, space-12 top and bottom
2
Radius
radius-8
3
Text and fill
Type/15 Medium on surface/inverse
States
Button
Default
Button
Hover
Button
Disabled
Button
Default
Button
Hover
Button
Disabled
Each state is its own variant, named the same way every time.
Handoff notes
Behavior
Disabled until the form is valid
Edge cases
Long labels truncate after 2 lines
Accessibility
Focus ring is visible on keyboard navigation
Layers
Button
Style=Primary, State=Default
Style=Primary, State=Hover
Style=Primary, State=Disabled
Style=Secondary, State=Default
One component with its specs, states, and notes.
Bring engineers in early
I involve engineers before design starts, not after. Early conversations surface constraints and prevent rework, and reviews during design keep feasibility and quality aligned. By the time a design reaches handoff, there should be no surprises.
Organize the file for the next person
A good file explains itself. I keep pages in a predictable order, name layers and components with one pattern, and separate finished work from experiments. Anyone, from a designer to a product partner, can open the file and find what they need without asking.
A file that explains itself
Handoff-ready
Pages, in order
00 Cover
01 Foundations
02 Components
03 Patterns
04 Screens
05 Handoff
99 Archive
Frames
Page / Section / Element / State
e.g.
Screens / Orders / Table / Default
Components
category / name / variant
e.g.
button / primary / hover
Tokens
type-size, space-n, radius-n
e.g.
space-16, radius-8, Type/15 Medium
Pages in a fixed order, and one naming pattern for everything.
Make progress visible
A shared status view shows where every component stands in design, code, and documentation. It turns a question in chat into something anyone can check, and it makes gaps easy to spot before they slow a release.
Everyone sees where a component stands
Sample status
Component
Design
Code
Docs
Button
Done
Done
Done
Input
Done
Done
In review
Select
Done
In review
Planned
Card
Done
Done
Done
Data table
In review
Planned
Planned
Toast
Planned
Planned
Planned
A sample status view for design, code, and docs.
Check the build against the design
After engineers build, I review the result with them, side by side with the design. We log differences with the token or spec that should have applied, fix them together, and treat each one as a chance to improve the spec, not as a mistake.
Spec versus staging
Design QA
Design
Spec
Order summary
3 items · Ships Thursday
Place order
Build
Staging
Order summary
3 items · Ships Thursday
Place order
1
2
1
Padding is 16, spec says 24 (space-24).
Open
2
Corner radius is 6, spec says 12 (radius-12).
Open
Design QA: findings tied to the spec they came from.
Review after launch, too
Once something ships, I look at how it behaves with real use and bring what I learn back to the team. When naming, structure, and components stay consistent, a conversation about a button means the same thing to everyone.
A shared language makes the work easier to build and easier to trust
Next article
Using AI wisely →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
Working with engineering
A shared language
How I hand off designs so any stakeholder can build from them.
Topic
Working with engineering
Reading time
3 minutes
Covers
Handoff, naming, design QA
Visuals
Original illustrations
Specs
Button
1
Padding
space-20 sides, space-12 top and bottom
2
Radius
radius-8
3
Text and fill
Type/15 Medium on surface/inverse
States
Button
Default
Button
Hover
Button
Disabled
Button
Default
Button
Hover
Button
Disabled
Each state is its own variant, named the same way every time.
Handoff notes
Behavior
Disabled until the form is valid
Edge cases
Long labels truncate after 2 lines
Accessibility
Focus ring is visible on keyboard navigation
Layers
Button
Style=Primary, State=Default
Style=Primary, State=Hover
Style=Primary, State=Disabled
Style=Secondary, State=Default
One component with its specs, states, and notes.
Bring engineers in early
I involve engineers before design starts, not after. Early conversations surface constraints and prevent rework, and reviews during design keep feasibility and quality aligned. By the time a design reaches handoff, there should be no surprises.
Organize the file for the next person
A good file explains itself. I keep pages in a predictable order, name layers and components with one pattern, and separate finished work from experiments. Anyone, from a designer to a product partner, can open the file and find what they need without asking.
A file that explains itself
Handoff-ready
Pages, in order
00 Cover
01 Foundations
02 Components
03 Patterns
04 Screens
05 Handoff
99 Archive
Frames
Page / Section / Element / State
e.g.
Screens / Orders / Table / Default
Components
category / name / variant
e.g.
button / primary / hover
Tokens
type-size, space-n, radius-n
e.g.
space-16, radius-8, Type/15 Medium
Pages in a fixed order, and one naming pattern for everything.
Make progress visible
A shared status view shows where every component stands in design, code, and documentation. It turns a question in chat into something anyone can check, and it makes gaps easy to spot before they slow a release.
Everyone sees where a component stands
Sample status
Component
Design
Code
Docs
Button
Done
Done
Done
Input
Done
Done
In review
Select
Done
In review
Planned
Card
Done
Done
Done
Data table
In review
Planned
Planned
Toast
Planned
Planned
Planned
A sample status view for design, code, and docs.
Check the build against the design
After engineers build, I review the result with them, side by side with the design. We log differences with the token or spec that should have applied, fix them together, and treat each one as a chance to improve the spec, not as a mistake.
Spec versus staging
Design QA
Design
Spec
Order summary
3 items · Ships Thursday
Place order
Build
Staging
Order summary
3 items · Ships Thursday
Place order
1
2
1
Padding is 16, spec says 24 (space-24).
Open
2
Corner radius is 6, spec says 12 (radius-12).
Open
Design QA: findings tied to the spec they came from.
Review after launch, too
Once something ships, I look at how it behaves with real use and bring what I learn back to the team. When naming, structure, and components stay consistent, a conversation about a button means the same thing to everyone.
A shared language makes the work easier to build and easier to trust
Next article
Using AI wisely →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.
Working with engineering
A shared language
How I hand off designs so any stakeholder can build from them.
Topic
Working with engineering
Reading time
3 minutes
Covers
Handoff, naming, design QA
Visuals
Original illustrations
Specs
Button
1
Padding
space-20 sides, space-12 top and bottom
2
Radius
radius-8
3
Text and fill
Type/15 Medium on surface/inverse
States
Button
Default
Button
Hover
Button
Disabled
Button
Default
Button
Hover
Button
Disabled
Each state is its own variant, named the same way every time.
Handoff notes
Behavior
Disabled until the form is valid
Edge cases
Long labels truncate after 2 lines
Accessibility
Focus ring is visible on keyboard navigation
Layers
Button
Style=Primary, State=Default
Style=Primary, State=Hover
Style=Primary, State=Disabled
Style=Secondary, State=Default
One component with its specs, states, and notes.
Bring engineers in early
I involve engineers before design starts, not after. Early conversations surface constraints and prevent rework, and reviews during design keep feasibility and quality aligned. By the time a design reaches handoff, there should be no surprises.
Organize the file for the next person
A good file explains itself. I keep pages in a predictable order, name layers and components with one pattern, and separate finished work from experiments. Anyone, from a designer to a product partner, can open the file and find what they need without asking.
A file that explains itself
Handoff-ready
Pages, in order
00 Cover
01 Foundations
02 Components
03 Patterns
04 Screens
05 Handoff
99 Archive
Frames
Page / Section / Element / State
e.g.
Screens / Orders / Table / Default
Components
category / name / variant
e.g.
button / primary / hover
Tokens
type-size, space-n, radius-n
e.g.
space-16, radius-8, Type/15 Medium
Pages in a fixed order, and one naming pattern for everything.
Make progress visible
A shared status view shows where every component stands in design, code, and documentation. It turns a question in chat into something anyone can check, and it makes gaps easy to spot before they slow a release.
Everyone sees where a component stands
Sample status
Component
Design
Code
Docs
Button
Done
Done
Done
Input
Done
Done
In review
Select
Done
In review
Planned
Card
Done
Done
Done
Data table
In review
Planned
Planned
Toast
Planned
Planned
Planned
A sample status view for design, code, and docs.
Check the build against the design
After engineers build, I review the result with them, side by side with the design. We log differences with the token or spec that should have applied, fix them together, and treat each one as a chance to improve the spec, not as a mistake.
Spec versus staging
Design QA
Design
Spec
Order summary
3 items · Ships Thursday
Place order
Build
Staging
Order summary
3 items · Ships Thursday
Place order
1
2
1
Padding is 16, spec says 24 (space-24).
Open
2
Corner radius is 6, spec says 12 (radius-12).
Open
Design QA: findings tied to the spec they came from.
Review after launch, too
Once something ships, I look at how it behaves with real use and bring what I learn back to the team. When naming, structure, and components stay consistent, a conversation about a button means the same thing to everyone.
A shared language makes the work easier to build and easier to trust
Next article
Using AI wisely →
Product design leader. Design functions,
systems, and products for complex SaaS.
Case Studies
Web design system
Native design system
Unified Inbox
AI capability
About
About
How I Work
Résumé
Contact
aln.dohotaru@gmail.com
© 2026 Alina Dohotaru
Visuals are original illustrations and do not depict proprietary product screens.