Do not start a design-system rebuild decision with the appearance of the library. Start with what the product actually uses: implemented components, their consumers and differences that create errors or obstruct work. An old library may have sound foundations. A tidy library may be ignored by every delivery team. The right intervention addresses the cause and includes a feasible transition.
If the current state is unclear, commission a bounded review before committing to a replacement. Its purpose is to distinguish documentation repair, consolidation of duplicate components and foundational constraints that prevent agreed needs from being met. Replacement does not automatically save time or money. Migration, regression testing and continued delivery during transition belong in the comparison.
Gather evidence from three places
Design files. Which source is authoritative? Are designers using shared components or local copies? Which Arabic and English states exist? Identify the versions actually used rather than relying on remembered file names.
Implementation. Where are the corresponding code components? Does the same name imply the same behavior? Is the approved error message used in the product? These questions require code access or an inspectable environment and engineering participation. Screenshots cannot establish internal architecture.
Product journeys. Does a difference change someone’s ability to complete a task? A visual variation in an old dialog may be less urgent than a shared selection control that fails to communicate its current value. UX/UI Audit can connect inconsistencies with their consequences in an existing journey.
Where accessibility is included, tools alone cannot determine whether a website meets accessibility standards; knowledgeable human evaluation is needed. WAI evaluation overview. A design-library review must not become a claim that the whole product has been certified accessible.
Worked hypothetical: seven button styles
Suppose a product has seven similarly named button styles. The inventory finds two serving the same purpose with different spacing, two representing ordinary and sensitive actions, one legacy style still used on an important page and two unused styles. This distribution is illustrative, not a benchmark for acceptable duplication.
The conclusion is not to replace all seven with one button. The team proposes merging the functionally equivalent pair after reviewing usage, retaining the meaningful distinction between ordinary and sensitive actions, planning migration for the legacy style and archiving the unused styles after checking for hidden consumers.
One representative page becomes a consolidation pilot. The component is reviewed with longer Arabic copy, disabled behavior, focus and a pending operation. If merging it requires substantial changes to consuming screens, that cost becomes visible early. If the pilot works without changing business behavior, consolidation becomes a credible alternative to rebuilding the entire system.
The review might instead discover that components cannot be separated from their screens and each team uses a fundamentally different structure. A broader intervention may then be warranted, but the decision should rest on dependencies and transition risks rather than a judgment that the library looks dated.
The pilot is deliberately small enough to inspect. Its purpose is not to conceal the rest of the migration behind a successful demonstration; it is to test the proposed approach and expose assumptions before a larger commitment.
Compare options by what they change
| Option | When to consider it | What the proposal should include |
|---|---|---|
| Bounded repair | Foundations are adopted and problems are local | Specific missing states, documentation and fixes |
| Gradual consolidation | Functional duplication and design-code differences exist | Merge mapping, pilot and transition plan |
| Replacement | Demonstrated foundational constraints block requirements | Replacement rationale, migration dependencies and retirement conditions |
For every option, ask what will remain. That question reveals whether the supplier understands the product or intends to recreate everything. Separate library design from component implementation and migration of consuming screens. They are different deliverables even when one team supplies them.
Design Systems covers foundations, reusable components and practical governance within the agreed scope. User Interface Design can resolve specific states. Alignment with a live product needs an explicit App Development scope rather than being assumed as a by-product of design work.
What should the paid review deliver?
Expect a traceable inventory, not just a polished categorisation board. Each component should have its design reference, implementation reference where available, inspected uses, observed difference, consequence, recommendation and confidence level. The report should identify access gaps instead of interpreting “not inspected” as “not used”.
Then ask for a system-level recommendation supported by a small test of the proposed repair path. Useful acceptance criteria include traceability to real product samples, a rationale for retain-or-merge decisions, identified affected consumers and documented migration risks.
A lower component count is not sufficient evidence of success. It may erase a distinction needed for a task or permission model. Equally, an increase in documented states can be valuable if it removes ambiguity without introducing needless variants.
For procurement, ask the supplier to name the inputs needed before a confident implementation estimate can be given. This keeps a discovery conclusion separate from an unsupported fixed migration promise.
Avoid creating a second abandoned library
Common mistakes include treating every visual difference as a defect and every documented component as an adopted one. Another is approving a new library without anyone responsible for moving existing products onto it. The company then has two systems rather than a solution to the old one.
A proportionate recommendation might preserve most foundations, consolidate one high-use family and defer a low-use legacy area with a named owner. Such a result is more useful than an unqualified demand to start again.
Frequently asked questions
Can the audit happen without code access?
Design and visible behavior can be reviewed, but architecture and actual reuse remain unverified. A confident component-migration estimate cannot be supported by screenshots alone.
Do seven button styles prove failure?
No. They may represent legitimate roles or contexts. Inspect meaning, behavior and usage before merging them.
When should the old system be retired?
After explicit transition conditions are met and remaining consumers have an agreed path. Publishing the new library does not establish migration completion.
Is governance needed during the review?
Name decision owners and transition responsibility now. Ongoing release and exception management should have a defined governance scope; it does not replace diagnosis of the current problem.
Begin with evidence from an important journey and a widely used component. If that evidence supports a limited repair, it should remain a genuine option in the proposal rather than a ceremonial step toward selling a rebuild.
Source
- W3C WAI: Evaluating Web Accessibility Overview, reviewed 26 October 2026.
