Harvey Is Rebuilding Its Design System From the Ground Up

Harvey, the company behind the AI assistant used by law firms, has announced it is rebuilding its design system from the ground up. That is the whole of the confirmed news: a ground-up rebuild, announced by the company itself, rather than another round of component patches.

Why does that matter? Because most design teams choose the opposite path. A system that has been in production for years usually accumulates exceptions — one-off components, inconsistent tokens, duplicated patterns that shipped under deadline pressure. Teams typically retire that debt incrementally, refactoring a component here, renaming a token there, and hoping the entropy stops growing.

Harvey says it is not doing that. The company has decided the existing foundation no longer serves the product and is starting over.

What do we actually know?

The announcement, published by Harvey under the title "Rebuilding Harvey's Design System From the Ground Up," confirms the scope of the decision: a full replacement rather than an audit-and-repair cycle. The company has not yet published the accompanying details — timelines, component counts, migration strategy, or the specific failure modes that triggered the decision.

That last gap is the interesting one. A ground-up rebuild is an expensive, high-risk commitment, and teams rarely make it lightly. The usual triggers are well known in the field: token architectures that can't support theming, accessibility debt that violates WCAG 2.1 success criteria such as 1.4.3 Contrast (Minimum), or component APIs that force product teams to bypass the system entirely.

Which of these pushed Harvey over the edge remains to be seen. The full write-up, when it arrives, should say.

Why does a rebuild beat a refactor — and when doesn't it?

The case for starting over is straightforward. A new system lets a team set constraints before code exists: a single source of truth for tokens, documented component contracts, accessibility baked into base components rather than retrofitted. Retrofitting contrast, focus order, and semantics into a live system means touching every screen that inherits the old components.

The case against is equally concrete. During the migration, two systems coexist, and every product team pays a tax in conditional logic, duplicated components, and design review overhead until the old library is retired.

So the announcement raises a question experienced practitioners will want answered: what is the migration plan, and how long will both systems run in parallel?

What happens next?

Harvey's post signals the decision, not yet the execution details. Watch for the follow-up documentation — migration sequencing, token architecture, and accessibility baselines — which will determine whether the rebuild becomes a case study in doing it right or a cautionary tale about throwing away working components too eagerly.