Design System Adaptation
Use this skill when the right move is translation, not imitation.
Use when
- The team already has a design system.
- The user wants inspiration from an outside reference without replacing the current product language.
- A redesign needs to preserve core product consistency.
Do not use when
- The project has no meaningful visual system yet.
- The user explicitly wants a net-new project-level design system from scratch.
Adaptation failures to avoid
- treating a reference as a skin pack
- changing every token at once
- copying layouts that do not match the product workflow
- importing marketing-page aesthetics into app surfaces unchanged
Workflow
1. Define the stable core
Lock what should not change:
- component contracts
- accessibility requirements
- brand constraints
- product shell behavior
2. Extract the transferable signals
Identify what is actually portable:
- typography attitude
- palette discipline
- density model
- component geometry
- emphasis strategy
3. Translate into the local system
Express the adaptation through:
- token adjustments
- component rules
- layout rhythm
- state treatment
4. Name the non-transferable parts
Be explicit about which reference traits should stay out.
5. Produce a safe change path
Recommend the smallest set of changes that can shift the experience materially without destabilizing the product.
Output format
Return:
1. Existing system constraints
- what must remain stable
2. Reference signals worth keeping
- what is transferable
3. Translation plan
- tokens
- components
- layout
- motion
4. Non-transferable traits
- what to reject
5. Safe rollout path
- smallest meaningful implementation sequence
Use together with
design-style-archetype-selectiondesign-system-distillationdesign-ui-critique-and-polish