A case study on building Meridian — a token-based, WCAG AA-compliant design system — after an audit found each of Studio Nord's 7 product teams shipping its own inconsistent, sometimes inaccessible components.
Try the component library ↓2 of 4 failed a contrast check.
Meridian is Studio Nord's shared design system: a token-based library of accessible components, built once and consumed by all 7 product teams — instead of each team maintaining its own buttons, forms, and navigation from scratch.
An internal audit found 4 different button styles, 6 different spacing scales, and components duplicated across teams that looked similar but behaved differently. Worse, an accessibility pass found several of those components failing WCAG AA contrast and keyboard-navigation checks — each team had rebuilt the same problems independently, with no shared source of truth to catch them.
Build a single, token-based system that's accessible by default rather than by request, ship it in a way 7 teams with different roadmaps could actually adopt without a big-bang rewrite, and cut the back-and-forth between design and engineering that came from every team re-specifying the same components.
Design debt compounds the same way technical debt does: every team that copies an old, slightly-wrong component instead of a shared one makes the next audit larger and the next fix harder. The longer 7 teams stayed on their own components, the more expensive a shared system would eventually be to retrofit.
A five-stage double-diamond process, run end-to-end with weekly syncs alongside one PM and two engineers.
Research & competitive analysis
Personas & journey mapping
HMWs, IA & user flows
Wireframes to hi-fi UI
Usability testing & iteration
Four opportunities emerged for making Meridian something 7 teams would actually adopt, not just a Figma file.
WCAG AA contrast, focus states, and keyboard navigation ship by default — not something each team has to remember to add.
Color, spacing, and type live as tokens shared between Figma and code, so design and engineering can't silently drift apart again.
Components expose slots and variants instead of rigid, locked-down templates, so teams don't fork the library to get what they need.
Teams can adopt component-by-component alongside their existing roadmap, instead of stopping feature work for a big-bang swap.
Understanding why 7 teams kept rebuilding the same components instead of reusing each other's, and what accessibility actually looked like across them.
1:1 moderated interviews with designers and engineers across all 7 teams.
An automated component audit plus a follow-up survey validated interview themes at scale.
A structured review of three established design systems to map strengths, gaps, and openings for differentiation.
MDMaterial Design |
CBCarbon (IBM) |
PLPolaris (Shopify) |
|
|---|---|---|---|
| Description | Google's broad, general-purpose system covering nearly every UI pattern | IBM's enterprise system, built with accessibility as a first-class constraint | Shopify's system for merchant-facing admin and app-extension UI |
| Strengths | Extremely comprehensive, strong theming tools | Rigorous WCAG compliance, excellent documentation of the "why" | Practical adoption tooling, opinionated defaults reduce decisions |
| Weaknesses | Generic by design — heavy re-theming needed to not look like Google | Steep learning curve, verbose for smaller teams | Patterns lean Shopify-specific, less portable elsewhere |
| Adoption approach | All-or-nothing theming layer across the whole product | Comprehensive but front-loaded — a big investment before any payoff | Incremental, component-by-component adoption encouraged |
The gap isn't another comprehensive system — it's one that combines Material's completeness, Carbon's accessibility rigor, and Polaris's incremental adoption model, without their respective weaknesses: generic re-theming, a steep upfront learning curve, and platform-specific lock-in. Meridian's opportunity is accessible-by-default components that any of the 7 teams can adopt one at a time.
Synthesizing research into shared patterns, then into two personas that anchored every design decision.
"I don't want to design a button again. I want to know the one we have is good."
"If it's not in code with the props documented, it doesn't exist to me."
Scenario: Ibrahim adopts Meridian's Button component for the first time.
| Phase | Discovery | Documentation | Installation | First Use | Team Rollout |
|---|---|---|---|---|---|
| Action | Sees Meridian mentioned in an engineering all-hands | Reads the Button page — props, variants, accessibility notes | Installs the package and drops it into a branch | Swaps a hardcoded button, tests keyboard navigation himself | Proposes the switch to his team's next sprint |
| Feeling | 🙂 Curious | 😌 Reassured | 🙂 Confident | 😊 Relieved | 🎉 Proud |
| Opportunity | Announce with real components, not just a slide deck | Document accessibility behavior, not just visual specs | Make install as easy as any other internal package | Let the component work correctly on the first try | Give teams a lightweight way to propose adoption to their lead |
Reframing research insights as "How Might We" questions, then structuring the product around them.
→ Bake WCAG AA contrast, focus states, and ARIA labeling into the component itself, not a checklist someone has to remember.
→ A searchable component index with live examples and a "who else uses this" list.
→ A visible last-updated date and version number on every component's page.
→ Composable components with documented slots and variants instead of locked templates.
→ Tokens shared directly between Figma and the component library, not hand-copied by each team.
→ A lightweight RFC process for extending or changing a shared component.
Flow 1 · Reviewing a component before reuse
Flow 2 · Proposing a new component
From low-fidelity structure to a component library built around accessibility, composability, and clear documentation.
Not every idea survived contact with engineers. A single mega-configurable Card component is the clearest example — and the reasoning behind cutting it shaped Meridian's whole approach to composability.
Fewer components meant less to document and less to learn — one Card could become an info card, a stat card, a list item, or an empty state just by toggling props. It looked like the fastest path to consistency across 7 teams.
Four focused, purpose-built card components composed from the same shared primitives — matching the "composable, not one-size-fits-all" principle set in the design strategy above.
Indigo
#32335C
Amber
#9C7419
Stone
#7C7F94
Paper
#F0F1F5
Rust
#B24444
Indigo and amber replace the neutral grayscale most internal tools default to, so Meridian-built products still read as considered rather than generic; the rust token is reserved for destructive and error states only, never routine emphasis, so it keeps its meaning across 7 teams' products. Contrast ratios for every token pairing are documented, not assumed — see Accessibility below.
The Meridian documentation site, itself built entirely from Meridian components — the library proving its own rules.
Verified 4.9:1 against --color-paper at every supported size. Below AA fails the build.
Notifications team completed migration. One team left to full adoption.
Every element on the flagship screen traces back to a specific research finding.
The audit found teams couldn't tell which library version they were on — the header now states it plainly, every screen.
Replaces "accessible by design" marketing language with a real, countable ratio teams can hold the library to.
The most-adopted component categories surface first, so the highest-leverage gaps are never buried.
The one category below target uses the accent color — color signals a decision point, not decoration.
All five destinations are reachable one-handed — see the reachability study below.
A design system is only as accessible as its weakest component — every token pairing and touch target was checked before it shipped, not after a team complained.
Primary actions, the status card, and the bottom navigation all sit in the bottom two-thirds of the screen — the zone a thumb reaches without a grip shift, enforced as a layout guideline for every product team.
Every component ships with an automated contrast and focus-order check in CI — a component that fails WCAG AA can't merge, regardless of how it looks in Figma.
This isn't a screenshot — it's a working slice of the actual review flow tested in the study below. Tap the flagged component, then merge, escalate, or defer.
Flagged because automated tests found arrow-key navigation doesn't wrap across month boundaries. Test coverage: 92%.
Logged — Date Picker stays on the review queue until the keyboard-nav fix merges.
Meridian will notify every team using Date Picker once it moves out of Beta.
Components CI wasn't fully confident about surface first, with a test-coverage score attached.
Tap in to see exactly why a component was flagged — never a black box.
Every path is logged against the component's history — no separate tracker required.
Moderated testing with the engineers and designers who'd actually adopt Meridian, to validate whether the documentation and review flow held up in practice.
8 participants (2 engineers and 1 designer from each of 4 pilot teams), moderated remote sessions via Maze, testing four core tasks: finding the right component in the browser, reading its accessibility notes, integrating it into an existing screen, and understanding why a component was flagged Beta.
Session recording · Task 2 — reading a component's accessibility notes
This reaction — relief once the number was shown, paired with an instinct to distrust an unexplained badge — showed up in 5 of 8 sessions and directly shaped Finding 03 below.
6 of 8 participants picked a Beta component without registering its status — the pill only appeared on the detail page, not in the browse list.
Made the status pill always visible next to the component name, in the list and the detail view.Several participants expected a component's tokens to live inside its own docs page, not a separate top-level section.
Added a "Uses these tokens" cross-link block directly into every component detail page.Engineers trusted "4.9:1 measured" far more than a plain "Accessible" checkmark with no number attached.
Replaced every pass/fail badge with the actual measured contrast ratio.Validated through iterative usability testing across all 4 pilot teams ahead of a full 7-team rollout.
Documentation is only useful if it's impossible to miss — hiding accessibility status behind a detail page defeats its purpose. I also learned how much a measured number beats a claimed badge: engineers didn't want to be told a component was accessible, they wanted the ratio, so they could judge it themselves.
Next steps include closing the remaining 4 components to full WCAG AA compliance, building a Figma plugin that surfaces the same contrast data at design time, and partnering with each team's tech lead to retire the last of the pre-Meridian one-off components.