The more screens and the more people, the faster things fall apart without rules. That said, building an elaborate system for a small project costs more than it saves.
11 terms11 live demos
"I sent you the Figma link" is not a handoff
Every state · error and empty screens · image assets · fonts · responsive rules. Development stalls unless all five travel together.
01
Design System
디자인 시스템
When this comes up
"Build us a design system" — a request that starts with weighing up the size of the project.
A framework binding components, rules and documentation into one. It sets out "this is what a button looks like here, and this is when you use it".
See it Try clicking
① Tokens — the base values for colour, spacing and type size
② Components — buttons, inputs, cards…
③ Patterns — rules for combinations, like filling a form or showing a list
④ Documentation — when to use what
A design system missing ④ ends up used by nobody.
Easy to get wrong
Building a design system first on a small project costs more than it saves. Under 20 screens, a style guide is plenty. Past 100 screens, or with several people working together, life without one is misery.
Using it on the job
A design system without documentation ends up used by nobody. "When to use what" matters more than the list of components.
Ask for it like this
At around 20 screens, I would suggest starting with a style guide (colour, type, spacing, base components) rather than a full design system. We can expand it into a system if the project grows.
"Is the style guide included?" — a question about whether it is a separate deliverable.
A single document collecting colour, type, spacing and components. Part of a design system, and its lighter version.
See it Try clicking
COLOR
BUTTON
Easy to get wrong
On agency work, "is the style guide included?" is a question about deliverables. Handing over mockups and producing a reusable rules document are different amounts of work.
Ask for it like this
Please confirm whether a style guide is part of the deliverables. Handing over screen mockups and documenting the colour, type, spacing and component rules are separate pieces of work.
A piece of UI built to be reused — buttons, inputs, cards and anything else that repeats across screens.
See it Try clicking
Button
TextField
Tag
Tag
Easy to get wrong
A designer's "component" (Figma) and a developer's "component" (React and friends) are the same idea in different tools. Aligning the names — both Button/Primary — cuts a lot of communication cost.
Ask for it like this
Please align the Figma component names with the code component names. Standardising both on Button/Primary, TextField/Default and so on makes communication much faster.
"Make this button a bit different" — deciding whether it is a new component or a variant.
A variation of the same component. One button carries combinations of size (large/medium/small) × kind (primary/secondary) × state (default/hover/disabled).
See it Try clicking
All of these are variants of the same "Button" component.
Easy to get wrong
Draw a new button in every mockup without defining variants and the developer cannot tell whether it is a new component or a variation of an existing one. You end up with ten near-identical buttons.
Ask for it like this
This button is not a new component — it is a variant of the existing Button. Handle it as size=sm, variant=secondary. Please do not create a new one.
"I changed the button colour but this one did not update" — when the link is broken.
The main component is the original and an instance is a copy placed from it. Change the original and every instance changes with it.
See it Try clicking
Main component
↓
Instance
Instance
Detached
The third one is disconnected, so changing the original no longer reaches it.
Easy to get wrong
This structure is what lets you change a button colour once and have it apply everywhere. Conversely, "detaching" an instance to edit it freely breaks that link, so later changes to the original skip it — a regular source of accidents.
Ask for it like this
Please do not detach component instances. If a change is needed, add a variant to the main component instead. Detaching means it cannot be updated in bulk later.
"Not that blue, the other blue" — a conversation that ends once colours have names.
Values such as colour, spacing and font size defined with names. You say color-primary rather than #4F46E5.
See it Try clicking
color-primary= #4F46E5
space-4= 16px
radius-md= 8px
font-body= 14px / 1.6
Easy to get wrong
The device that gets designers and developers using the same word. Say "primary" instead of "this blue" and there is no ambiguity, and when the brand colour changes later you edit one token value.
Ask for it like this
Please define colour, spacing and font size as design tokens. Use token names (color-primary) in code rather than hard-coded values (#4F46E5), so a future brand colour change only touches one place.
"How should we divide up the components?" — setting the classification.
A methodology building UI in five levels: atoms → molecules → organisms → templates → pages.
See it Try clicking
Button, input
atom
→
Search form
molecule
→
Header
organism
→
Page
complete
Easy to get wrong
The concept is excellent, but few teams keep strictly to five levels in practice. Rather than spending a meeting on "is this a molecule or an organism", it is more practical to simplify to three — base elements / compositions / screens.
Ask for it like this
Rather than strictly following the five levels of atomic design, I will simplify classification to three — base elements (buttons, inputs) / compositions (search forms, cards) / screens. Better not to spend time arguing about classification.
"What happens when the text gets longer?" — the moment a developer asks.
A Figma feature that arranges elements and maintains spacing automatically. Boxes grow on their own as content lengthens.
See it Try clicking
✗ Free placement
longer text means resizing the box by hand
✓ Auto layout
the box and the spacing adjust themselves as content grows
Easy to get wrong
It maps almost one to one onto Flexbox in code. Mockups built with auto layout are far easier to implement. Mockups where elements are positioned by eye make responsive work painful — this is something interviewers check for.
Ask for it like this
I will build the mockups with auto layout. Spacing holds as text length changes, and it transfers directly to Flexbox in development.
The rule of keeping spacing and sizes to multiples of 8 (8, 16, 24, 32…). Sometimes 4 is allowed alongside.
See it Try clicking
8
16
24
32
13 ✗
Easy to get wrong
The device that stops 13px, 17px and 23px creeping in. Developers stop asking "why is this 15px?". Most screen resolutions dividing evenly by 8 is part of the reason too.
Ask for it like this
Please use only multiples of 8 for spacing (8, 16, 24, 32, 40). Allow 4 as well for fine adjustment, but avoid values like 13, 15 and 17.
"I sent you the Figma link" — that is only part of a handoff.
The process of passing a finished design to development in a form it can be built from.
See it Try clicking
✓Every desktop and mobile screen
✓Mockups per state (hover, disabled, loading, error, empty)
✓Image and icon assets (SVG, @2x/@3x)
✓Font files or the web font address
✓Breakpoint and spacing rules
Easy to get wrong
"I sent you the Figma link" is not a handoff. At minimum these five travel together: ① every state ② error and empty screens ③ image assets ④ font files ⑤ responsive rules. Turn it into a checklist and the back-and-forth shrinks.
Ask for it like this
I will work through the handoff checklist — ① full desktop and mobile screens ② state mockups (hover, disabled, loading, error, empty) ③ image and icon assets (SVG, @2x/@3x) ④ font files ⑤ breakpoint and spacing rules. Development starts once all five are ready.
"Why does it not match the design?" — leave it out of the schedule and it explodes right before launch.
The stage where the designer checks the built screens against the design.
See it Try clicking
1Button height 40px → actually 36px
2Gap between cards 24px → actually 16px
3The bottom button sits behind the home bar on mobile
Design QA is listing items like these with reference numbers and handing them to development.
Easy to get wrong
It has to be scheduled separately. The day development finishes is not the day the project finishes. Without design QA, "why does it not match the design?" lands right before launch. Allow 5–10% of the overall schedule.
Ask for it like this
Please allow three days for design QA after development finishes. I need time to list the differences from the design with reference numbers and re-check after they are fixed. Leaving this out of the schedule pushes the launch date.