9:41
Brand detail
PPhotoism
Children’s ParkGwangjin-gu · 200m
Children’s ParkGwangjin-gu · 200m
DESIGN SYSTEM CASE STUDY · 2023
Photorage
Design System
Turn repeated decisions
into shared rules.
A design system that replaced repeated UI decisions with shared components, rules, and documentation.
9:41
Select a brand
1Life4Cuts2Photoism3Haru Film4Photo Signature5Mono Mansion6Selfix
9:41
Terms & consent
9:41
Start subscription
PHOTORAGE PLUSLight plan₩700 / month
Terms of service ›Privacy policy ›
01 · The problem
As Photorage grew,
the lack of a shared system became harder to ignore.
The problem wasn’t just visual. Inconsistent patterns made communication, implementation, and onboarding harder.
PDProduct designerNew screen handoffonline
I’m adding a new page. Which button should I use this time?
10:11 ✓✓Can you send the button specs again—size, color, radius, and disabled state?
10:13Same as the last screen—except this one is orange.
10:15 ✓✓↻
The same decision, explained again.No shared component reference
- 01
const primaryButton = { - 02
background: "#F68B1F",hardcoded - 03
color: "#FFFFFF",hardcoded - 04
padding: "12px 24px",local value - 05
borderRadius: "8px",local value - 06
fontWeight: 600, - 07
} - 08
- 09
const detailButton = { - 10
background: "#FF9417",conflict - 11
borderRadius: "14px",conflict - 12
}
!
Same button, different valuesNo shared token or state definition
Communication loops
Button specs had to be explained again for every new screen.
Hardcoded decisions
Hex values and spacing lived inside individual screens instead of shared tokens.
Interface drift
Small differences added up across screens, making the interface inconsistent.
Enter a tag
Add tags to describe this moment.
48px · black · 8px radiusWhat happened here?
#anniversary
56px · orange · 16px radiusJin Lee
Date of birth
44px · black · 2px radius2000 08 23
02 · Building the system
Turn repeated decisions
into reusable rules.
I documented how each component should look, behave, and be implemented so the team could use it consistently.
- 01
Audit
Map every live screen.
- 02
Extract
Turn repeated patterns into components.
- 03
Define
Standardize type, color, spacing, and states.
- 04
Document
Document when and how each component should be used.
CORE COMPONENT
Buttons
Primary, secondary, outlined, key-color, loading, disabled, compact, service, hashtag, sharing, and plan variants.
- Status
- Stable
- Source
- Figma 1.4.0
- Updated
- Sep 2026
01
Usage
Rules clarify when the documented element supports the product—and when it does not.
DOUse one dominant action per view and choose a variant by task priority.
DON’TDo not choose a style by preference or place competing primary actions together.
02
Live example
Interact with a code-based reference adapted from the real Figma component family.
03
Structure & behavior
Each part has a named responsibility that stays consistent across features.
01Container
Color, size, radius, and state
02Label
One-line action statement
03Optional icon
Loading, service, or category cue
04
Specifications
Values below follow the dimensions and tokens represented in the 1.4.0 library.
- Height
- 47 px
- Radius
- 12 px
- Label
- 16 / 21
button.heightbutton.radiustype.button05
Accessibility
Interaction and visual rules ship together.
- ✓KeyboardEvery action remains reachable and visibly focused.
- ✓LabelsControls describe their purpose and outcome.
- ✓ContrastText and state changes remain legible.
Search documentation ⌘ K
Ready for devCOMPONENT · ACTION
Button
Buttons trigger a single action. Their hierarchy should make the next step obvious without competing with the content around it.
- Status
- Stable
- Owner
- Product Design
- Updated
- Jun 2023
01
Usage
Use one primary action per view. Secondary actions support, but never compete with, the main task.
DOKeep labels specific and action-led.
Use “1개월 무료 체험하기” instead of a generic “확인”.
DON’TPlace two primary buttons together.
Equal emphasis makes the intended next step ambiguous.
02
Anatomy
A button has four controlled parts. All spacing is tokenized rather than set screen by screen.
1234
- Container
Defines size, color, and interaction state.
- Leading icon
Optional. Use only when it clarifies the action.
- Label
Verb-led and limited to one line.
- Safe area
Maintains the minimum touch target.
03
Variants
Choose hierarchy by action priority, not visual preference.
VariantExampleUse when
Primary
One high-priority action moves the task forward.
Secondary
An alternative supports the primary action.
Tertiary
Low-priority actions should remain available but quiet.
Service
External brand styling is preserved only for authentication.
04
States
Every state communicates whether an action is available and what the system is doing.
Default
Pressed
Loading
Disabled
05
Specifications
Base measurements are shared across product teams and mapped to implementation tokens.
- Height
- 48 px
- Radius
- 12 px
- Horizontal padding
- 20 px
- Icon gap
- 8 px
- Label
- 16 / 600
- Touch target
- 48 px min
size.control.lgradius.controlspace.20space.08type.buttona11y.target06
Accessibility
Interaction rules are documented alongside visual rules.
- ✓Clear labelsDescribe the result of the action, not the control itself.
- ✓ContrastMaintain at least 4.5:1 for labels in every state.
- ✓FocusPreserve a visible 2 px focus indicator.
RELATED COMPONENT
Search field
Use search when users know what they are looking for. Pair it with filters only when the result set needs meaningful narrowing.PATTERN
Bottom sheet
Bottom sheets keep a short decision in context. They are reserved for focused selections, confirmations, and temporary actions.브랜드 선택
STRUCTURE & RULES
- 01 · Handle
Signals the sheet can be dismissed.
- 02 · Title
Names one focused decision.
- 03 · Content
Uses a list, grid, or picker—never all three.
- 04 · Safe area
Protects controls above the home indicator.
✓Keep one task per sheet.×Do not stack sheets.
FOUNDATION REFERENCE
Tokens connect design to code.
Every documented value resolves to one shared source, so new components inherit the same visual language.NEUTRAL SCALE
001002003004005006007008009001000
BRAND SCALE
200300400500600700
TYPE ROLES
Title 1HeadlineBody text explains behavior and guidance.Caption · supporting metadata
03 · Component architecture
Build components once.
Reuse them across the product.
I organized the library using Atomic Design so the team could find and reuse components from basic controls to complete pages.
AtomMoleculeOrganismTemplatePage
ATOM · MOLECULE · ORGANISM
＋✓›⌕×
Search ⌕
✓Required service termsDetails and policy›
COMPOSE→
TEMPLATE · PAGE
04 · Impact
Design-related comments
dropped 40% after rollout.
Reduction in design-related comments per screen after rollout.
“Fewer handoff questions made delivery timelines easier to predict.”Product manager
“Clear component guidance made implementation faster and more consistent.”Front-end developer
DESIGN COMMENTS / SCREENIndexed baseline
WHAT CHANGED
01
Rules made the team freer.
The system reduced decision fatigue instead of limiting designers.
02
Maintenance became part of design.
Scalability and implementation context moved into the design process.
PHOTORAGE DESIGN SYSTEM · 2023