Case Study · Verisk ClaimSearch
Scaling design quality across a 20-product-team portfolio without scaling headcount.
One design system of 30 components, built and governed by a UI/UX team of four for a 20-team product portfolio, with 10 teams actively consuming today.
ROLE
Design System Lead & Librarian
TEAM
Myself and three designers / engineers
FOCUS
Governance and leverage
TIMELINE
2025 - present
The problem
I had already established design standards for ClaimSearch through a style guide, giving teams a shared reference as they reimagined their products. The style guide did its job, but I saw its ceiling: because the standards lived as documentation rather than components, every UI was still built by hand, and consistency could be recommended but never enforced. A component library was the natural next step.
Our migration from Adobe XD to Figma was the moment to build it. I led a four-person team in creating an enterprise design system that served 20 product teams, delivered under a framework shift from Ember to Angular and a hard WCAG AA requirement.
01
How I approached it
Architecture and the library
The library is organized into two tiers. Foundations carry the design decisions every component inherits: brand assets, design tokens (color, typography, spacing, effects), a responsive grid with four breakpoints, iconography, and shared utilities. Components cover the full interaction inventory — inputs and selection controls, navigation (breadcrumbs, tabs, tree menus, progress steppers), feedback patterns (banners, tooltips, popovers, modals, preloaders, load-failure states), and data display (tables, tags, section tiles).
Governance model
The system runs on hybrid ownership: a librarian-governed core with federated contribution. Components are promoted into the library against explicit criteria: multi-use, non-composable, stable, generalizable, and accessible, through staged validation: intake → triage → design → review → release. Every library publish ships with a logged changelog, so consuming teams always know what changed and why.
Contribution workflow
Any designer on the team, myself included, can initiate an intake request when they identify a component candidate. As librarian, I then review and approve intake, the contributing designer builds the component, it passes through testing and design review, and I create the supporting documentation and publish. The library remains the single source of truth: publishing rights stay with the librarian, which keeps the system's integrity independent of its contribution volume.
Adoption strategy
Adoption is policy, not preference: product designers build from library components by default, with one-off UI permitted only when the pattern doesn't yet exist in the library (in which case the designer initiates an intake request) or when the UI is genuinely product-specific. The rule applies to every reimagined and net-new product, which means the system's coverage grows with the portfolio rather than lagging behind it.
03
A challenge that didn't go smoothly
Situation
A product team, working at AI-assisted speed, shipped a stepper to production before our canonical library version was ready. My early flag didn't survive their delivery timeline.
Complication
When a second product needed the same UI, it forced a choice: rework live production code, or let two versions diverge. The deciding stakeholders were business-side, so design-system principle alone wouldn't settle it.
Action
I reframed the decision around total cost of ownership rather than consistency, then introduced a third option: assess whether the shipped version had real merit for ordering flows. It did, so we adopted it into the library as an approved variant instead of forcing either side to lose.
Result
No throwaway rework, no fight over shipped code, and the second product reused a governed component immediately.
What I changed
The lesson was that informal flags don't survive AI-speed delivery. I used the incident to formalize the intake process, so "this already exists" is now a gate in the workflow, not a message that can be missed.
04
Outcomes
-
Adoption: 10 of 20 product teams actively consuming the system, with the default-to-library policy driving coverage across every new and reimagined product.
-
Velocity: component implementation that previously took hours of hand-coding now scaffolds in minutes through AI-assisted generation against the system's tokens and specs.
-
Quality: stable, fully WCAG AA–conformant components, resulting in fewer UI-related defects, and higher design-review pass rates.
-
A structural shift: the system helped a dedicated UI development function take shape, centered on the library rather than rebuilding UI product by product.
