Design systems
Built to scale
How I build design systems that stay consistent as products and teams grow.
Topic
Design systems
Reading time
3 minutes
Covers
Foundations, tokens, components
Visuals
Original illustrations
Foundations
Scales, roles, type, space, radius
Color
Four brand scales and four status colors. Each scale has 11 steps, so every role has room to move.
Primary
Brand and actions
50
100
200
300
400
500
600
700
800
900
950
Neutral
Text, surfaces, borders
50
100
200
300
400
500
600
700
800
900
950
Secondary
Warm emphasis
50
100
200
300
400
500
600
700
800
900
950
Accent
Highlights and delight
50
100
200
300
400
500
600
700
800
900
950
Status
Feedback and alerts
Success 50 · 500 · 700
Warning 50 · 500 · 700
Danger 50 · 500 · 700
Info 50 · 500 · 700
Roles
Action
primary/600
Action hover
primary/700
Focus ring
primary/300
Text
neutral/900
Secondary text
neutral/600
Border
neutral/200
Surface
neutral/50
Emphasis
secondary/500
Highlight
accent/300
Type
Clear headings
Type/24 Semi Bold
Body text that stays easy to read
Type/17 Regular
Labels and captions
Type/13 Medium
Space
8
16
24
32
40
56
Radius
6
8
12
24
Foundations: color scales, roles, type, space, and radius.
Start with a few foundations
A system is only as good as what it is built on, so I start small: color, type, spacing, and radius. Each is a short, deliberate scale rather than a long menu of options. Fewer choices mean faster decisions, fewer one-offs, and screens that look related without looking identical.
Name things so anyone can read them
I name every value by what it is or what it does, never by where it was first used. Raw values sit at the bottom, purpose-based names sit above them, and components only ever read from the purpose layer. When a color changes, I change it once, and every screen that reads from it follows. A designer, an engineer, and a product partner can all open the file and find what they need without asking.
Three layers, one source of truth
Tokens
Primitives
Raw values, named by number
neutral/900
neutral/600
primary/600
→
Semantic
Named by purpose
text/primary
text/secondary
action/default
→
Components
Read from semantic only
Button label
Card description
Link
Change a primitive once and every screen that reads from it follows.
Raw values, purpose names, and components each have one job.
Build components from foundations
Components are assembled from the same tokens, so they inherit the system instead of copying it. I document each one with its parts, states, and the reasoning behind its decisions, so the next person understands why it works the way it does, not only how it looks.
Anatomy of a component
Button, input, card
Button
Button
1
Container
radius-8, surface/inverse
2
Label
Type/15 Medium, text/on-dark
3
Padding
space-20 and space-12
Input
name@example.com
We only use this to send receipts.
name@
Enter an email like name@example.com
1
Label
Type/13 Medium
2
Field
radius-8, border/strong
3
Helper or error
Type/13 Regular, status/amber
Card
Card title
A short supporting description goes here.
1
Surface
radius-12, surface/subtle
2
Title
Type/21 Semi Bold
3
Description
Type/15 Regular, text/secondary
Every part of a component points back to a token.
One system, every kind of screen
The real test of a system is range. The same foundations and components carry a dense dashboard, a table, a mobile flow, an onboarding sequence, and a settings screen, with only the layout changing. These are original examples with sample content, built to show how far a small set of parts can go.
Orders overview
Last 7 days
Export
New order
Orders
1,284
+8%
Avg. fulfillment
2.4 days
-0.3
On-time rate
96%
+2%
Orders this week
Mon
Tue
Wed
Thu
Fri
Sat
Sun
Fulfillment by stage
Picked
92%
Packed
78%
Shipped
64%
Recent orders
Order
Customer
Status
Amount
#1042
Harbor Goods
Shipped
$248.00
#1041
Pine Street Studio
Packing
$96.50
#1040
Lumen Works
Delayed
$512.00
#1039
Orchard Supply
Shipped
$74.20
A settings screen with toggles and clear actions.
Document it so it survives growth
A system that only its author understands does not scale. I write short usage guidance with examples, keep naming consistent, and make it easy for others to contribute and ask questions. The goal is a system that keeps working as the team, the products, and the people around it change.
A design system isn't a library of parts. It's a shared way of working.
Next article
Start with the question →
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.
Design systems
Built to scale
How I build design systems that stay consistent as products and teams grow.
Topic
Design systems
Reading time
3 minutes
Covers
Foundations, tokens, components
Visuals
Original illustrations
Foundations
Scales, roles, type, space, radius
Color
Four brand scales and four status colors. Each scale has 11 steps, so every role has room to move.
Primary
Brand and actions
50
100
200
300
400
500
600
700
800
900
950
Neutral
Text, surfaces, borders
50
100
200
300
400
500
600
700
800
900
950
Secondary
Warm emphasis
50
100
200
300
400
500
600
700
800
900
950
Accent
Highlights and delight
50
100
200
300
400
500
600
700
800
900
950
Status
Feedback and alerts
Success 50 · 500 · 700
Warning 50 · 500 · 700
Danger 50 · 500 · 700
Info 50 · 500 · 700
Roles
Action
primary/600
Action hover
primary/700
Focus ring
primary/300
Text
neutral/900
Secondary text
neutral/600
Border
neutral/200
Surface
neutral/50
Emphasis
secondary/500
Highlight
accent/300
Type
Clear headings
Type/24 Semi Bold
Body text that stays easy to read
Type/17 Regular
Labels and captions
Type/13 Medium
Space
8
16
24
32
40
56
Radius
6
8
12
24
Foundations: color scales, roles, type, space, and radius.
Start with a few foundations
A system is only as good as what it is built on, so I start small: color, type, spacing, and radius. Each is a short, deliberate scale rather than a long menu of options. Fewer choices mean faster decisions, fewer one-offs, and screens that look related without looking identical.
Name things so anyone can read them
I name every value by what it is or what it does, never by where it was first used. Raw values sit at the bottom, purpose-based names sit above them, and components only ever read from the purpose layer. When a color changes, I change it once, and every screen that reads from it follows. A designer, an engineer, and a product partner can all open the file and find what they need without asking.
Three layers, one source of truth
Tokens
Primitives
Raw values, named by number
neutral/900
neutral/600
primary/600
→
Semantic
Named by purpose
text/primary
text/secondary
action/default
→
Components
Read from semantic only
Button label
Card description
Link
Change a primitive once and every screen that reads from it follows.
Raw values, purpose names, and components each have one job.
Build components from foundations
Components are assembled from the same tokens, so they inherit the system instead of copying it. I document each one with its parts, states, and the reasoning behind its decisions, so the next person understands why it works the way it does, not only how it looks.
Anatomy of a component
Button, input, card
Button
Button
1
Container
radius-8, surface/inverse
2
Label
Type/15 Medium, text/on-dark
3
Padding
space-20 and space-12
Input
name@example.com
We only use this to send receipts.
name@
Enter an email like name@example.com
1
Label
Type/13 Medium
2
Field
radius-8, border/strong
3
Helper or error
Type/13 Regular, status/amber
Card
Card title
A short supporting description goes here.
1
Surface
radius-12, surface/subtle
2
Title
Type/21 Semi Bold
3
Description
Type/15 Regular, text/secondary
Every part of a component points back to a token.
One system, every kind of screen
The real test of a system is range. The same foundations and components carry a dense dashboard, a table, a mobile flow, an onboarding sequence, and a settings screen, with only the layout changing. These are original examples with sample content, built to show how far a small set of parts can go.
Orders overview
Last 7 days
Export
New order
Orders
1,284
+8%
Avg. fulfillment
2.4 days
-0.3
On-time rate
96%
+2%
Orders this week
Mon
Tue
Wed
Thu
Fri
Sat
Sun
Fulfillment by stage
Picked
92%
Packed
78%
Shipped
64%
Recent orders
Order
Customer
Status
Amount
#1042
Harbor Goods
Shipped
$248.00
#1041
Pine Street Studio
Packing
$96.50
#1040
Lumen Works
Delayed
$512.00
#1039
Orchard Supply
Shipped
$74.20
A settings screen with toggles and clear actions.
Document it so it survives growth
A system that only its author understands does not scale. I write short usage guidance with examples, keep naming consistent, and make it easy for others to contribute and ask questions. The goal is a system that keeps working as the team, the products, and the people around it change.
A design system isn't a library of parts. It's a shared way of working.
Next article
Start with the question →
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.
Design systems
Built to scale
How I build design systems that stay consistent as products and teams grow.
Topic
Design systems
Reading time
3 minutes
Covers
Foundations, tokens, components
Visuals
Original illustrations
Foundations
Scales, roles, type, space, radius
Color
Four brand scales and four status colors. Each scale has 11 steps, so every role has room to move.
Primary
Brand and actions
50
100
200
300
400
500
600
700
800
900
950
Neutral
Text, surfaces, borders
50
100
200
300
400
500
600
700
800
900
950
Secondary
Warm emphasis
50
100
200
300
400
500
600
700
800
900
950
Accent
Highlights and delight
50
100
200
300
400
500
600
700
800
900
950
Status
Feedback and alerts
Success 50 · 500 · 700
Warning 50 · 500 · 700
Danger 50 · 500 · 700
Info 50 · 500 · 700
Roles
Action
primary/600
Action hover
primary/700
Focus ring
primary/300
Text
neutral/900
Secondary text
neutral/600
Border
neutral/200
Surface
neutral/50
Emphasis
secondary/500
Highlight
accent/300
Type
Clear headings
Type/24 Semi Bold
Body text that stays easy to read
Type/17 Regular
Labels and captions
Type/13 Medium
Space
8
16
24
32
40
56
Radius
6
8
12
24
Foundations: color scales, roles, type, space, and radius.
Start with a few foundations
A system is only as good as what it is built on, so I start small: color, type, spacing, and radius. Each is a short, deliberate scale rather than a long menu of options. Fewer choices mean faster decisions, fewer one-offs, and screens that look related without looking identical.
Name things so anyone can read them
I name every value by what it is or what it does, never by where it was first used. Raw values sit at the bottom, purpose-based names sit above them, and components only ever read from the purpose layer. When a color changes, I change it once, and every screen that reads from it follows. A designer, an engineer, and a product partner can all open the file and find what they need without asking.
Three layers, one source of truth
Tokens
Primitives
Raw values, named by number
neutral/900
neutral/600
primary/600
→
Semantic
Named by purpose
text/primary
text/secondary
action/default
→
Components
Read from semantic only
Button label
Card description
Link
Change a primitive once and every screen that reads from it follows.
Raw values, purpose names, and components each have one job.
Build components from foundations
Components are assembled from the same tokens, so they inherit the system instead of copying it. I document each one with its parts, states, and the reasoning behind its decisions, so the next person understands why it works the way it does, not only how it looks.
Anatomy of a component
Button, input, card
Button
Button
1
Container
radius-8, surface/inverse
2
Label
Type/15 Medium, text/on-dark
3
Padding
space-20 and space-12
Input
name@example.com
We only use this to send receipts.
name@
Enter an email like name@example.com
1
Label
Type/13 Medium
2
Field
radius-8, border/strong
3
Helper or error
Type/13 Regular, status/amber
Card
Card title
A short supporting description goes here.
1
Surface
radius-12, surface/subtle
2
Title
Type/21 Semi Bold
3
Description
Type/15 Regular, text/secondary
Every part of a component points back to a token.
One system, every kind of screen
The real test of a system is range. The same foundations and components carry a dense dashboard, a table, a mobile flow, an onboarding sequence, and a settings screen, with only the layout changing. These are original examples with sample content, built to show how far a small set of parts can go.
Orders overview
Last 7 days
Export
New order
Orders
1,284
+8%
Avg. fulfillment
2.4 days
-0.3
On-time rate
96%
+2%
Orders this week
Mon
Tue
Wed
Thu
Fri
Sat
Sun
Fulfillment by stage
Picked
92%
Packed
78%
Shipped
64%
Recent orders
Order
Customer
Status
Amount
#1042
Harbor Goods
Shipped
$248.00
#1041
Pine Street Studio
Packing
$96.50
#1040
Lumen Works
Delayed
$512.00
#1039
Orchard Supply
Shipped
$74.20
A dashboard with a chart, progress, and a data table.
Mobile, from the same components
Home, detail, onboarding
Good morning
Today
Search orders
Needs attention
Order #1040
Delayed
Lumen Works, arriving Thursday
Order #1041
Packing
Pine Street Studio
Order #1042
Shipped
Harbor Goods
Home
Orders
Inbox
Profile
Home
‹ Orders
Order #1042
Shipped
Customer
Harbor Goods
Amount
$248.00
Shipping
Standard
Arrives
Thursday
Track package
Contact support
Detail
Stay on top of orders
Get a quick heads-up when something needs your attention.
Continue
Skip for now
Onboarding
Mobile screens built from the same components.
Sign in, verify, welcome
Authentication and onboarding
Step 1
Welcome back
name@example.com
Password
••••••••
Continue
Forgot password?
→
Step 2
Enter your code
We sent a 6-digit code to name@example.com.
4
8
2
1
That code has expired. Request a new one.
Verify
Resend code
→
Step 3
You're in
Your account is ready. Here is what to do first.
1
Add your team
2
Set notification preferences
3
Create your first order
Open dashboard
Sign-in, verification, and welcome, including an error state.
One system, one screen
Notifications
New messages
Email me when a guest writes in.
Weekly summary
A short recap every Monday.
Product news
Occasional updates and tips.
Save
Cancel
1
2
3
1
radius-12
Panel corners come from one radius token.
2
space-24
Padding and gaps use the spacing scale.
3
action/default
The same green marks every active control.
A settings screen with toggles and clear actions.
Document it so it survives growth
A system that only its author understands does not scale. I write short usage guidance with examples, keep naming consistent, and make it easy for others to contribute and ask questions. The goal is a system that keeps working as the team, the products, and the people around it change.
A design system isn't a library of parts. It's a shared way of working.
Next article
qStart with the Question →
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.