Deprecate a Design System Component
Design a governance workflow for retiring a shared component while giving product teams evidence, migration guidance, and a fair exception path.
The brief
Understand the problem
Background
Removing a flawed component is not just a library release. Teams need to find live usage, understand the reason for change, plan migration work, and manage genuine exceptions without letting the old pattern persist indefinitely.
User context
Nadia maintains a company design system. The legacy modal component fails current accessibility requirements and appears in 43 product surfaces owned by nine teams.
Product problem
The system team needs to coordinate a measurable deprecation while product teams need enough context to estimate work and avoid unsafe replacements.
Objective
Create a component deprecation workspace covering impact review, announcement, migration tracking, and exception decisions.
What to design
Define the experience
Required experience
- Review component health, adoption, and known risks
- Define a replacement path and milestone dates
- Notify affected owners with usage-specific guidance
- Track migrations and decide time-limited exceptions
Screens and states
- Component health detail
- Deprecation setup
- Migration tracker
- Exception review
Core user flow
Follow the critical path
- 01
Nadia opens the legacy modal report and validates the affected products
- 02
She selects the accessible dialog pattern as the replacement and defines milestones
- 03
Owners receive notices that link to their detected usages and migration recipe
- 04
One team submits an exception for a regulated release freeze
- 05
Nadia approves a limited extension with an owner and review date
Product rules
Requirements and constraints
Requirements
- Show component versions, detected usages, owners, and confidence in each match
- Connect the deprecation reason to concrete design and code guidance
- Support announcement drafts tailored to adopters, maintainers, and leadership
- Track migration status at the product-surface level
- Require rationale, risk controls, owner, and expiry for every exception
Constraints
- Usage detection can be incomplete and must show its last scan date
- Published packages cannot be removed before the announced support date
- The replacement may not support every legacy behavior
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Adoption
- 43 detected surfaces
- 9 owning teams
- 31 current package versions
- 12 versions more than one year old
Milestones
- Notice published: April 8
- New use blocked: May 6
- Support ends: August 30
Finish line
What to deliver
- Four desktop screens documenting a component deprecation from impact review through exception handling
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.
Theory to review
UX principles for this brief
Use these as decision lenses, then validate the design with the people and context in the brief.
heuristicOccam’s RazorWhen explanations or designs account for the same requirements equally well, prefer the one that depends on fewer unnecessary assumptions.
lawSteering LawMovement time through a constrained path tends to increase with path length and decrease with path width along the trajectory.