Alan Baker ← All work

One design system, two audiences

I led the design and development of Waterford.org’s design system: predictable for teachers and admins, playful for students, and a single source of truth developers had wanted for years. Getting teams to adopt it took more advocacy than I had planned for, and that is where much of the learning was.

Design systemsAccessibilityGovernanceAdoption
Role
Associate Director of User Experience
Company
Waterford.org, 2022 to 2025
Platform
K-2 learning platform serving 300,000 students
Built with
Figma, React, Material Design components
The problem
Components and colors were built separately, with no single source of truth. The platform changed with whoever built it, and it was slow to change at scale.
The turning point
One system had to serve two audiences: predictable for teachers and admins, playful for students. It also gave developers the foundation they had wanted.
The result
After rollout, development speed rose 62% and code reuse 80%, with WCAG 2.1 AA built in.

The platform had no single source of truth

Waterford.org builds a K-2 learning platform serving 300,000 students, with a focus on personalized learning, reporting for educators, and accessibility for every user.

The whole platform was built from unique components that shared no single source of truth, and colors were raw hex values. Depending on who built a page, it could carry different styling from a different source, so the experience changed from developer to developer and from page to page. It was also a time sink: developers had to create everything from scratch. The team worked primarily in React, and nothing was tokenized. I led the design and development of the system to give every team one foundation.

The review showed where inconsistency cost the most

I used Nielsen Norman Group’s ten usability heuristics as the backbone of a heuristic analysis of the existing experience. Together with stakeholder and user interviews, it showed where inconsistency cost the most and what to recommend.

  • Consistency and standards
  • Match to the real world
  • User control and freedom
  • Visibility of status
  • Error prevention
  • Recognition over recall
  • Flexibility and efficiency
  • Aesthetic and minimalist design
  • Error recovery
  • Help and documentation

I borrowed where people needed predictability and built where children needed delight

This was a deliberate choice. We were doing a lot of testing, and too much of it went into validating styles and interactions. That time was better spent on activities with students and features with teachers.

Material is a proven design system that Google has already validated, so it didn’t need validating again. Teachers and admins wanted something predictable they could use without relearning anything. For them I pulled in Material components for things like calendars, drop-downs and input fields and modified them with our branding. It also sped up development through ready-made React compatibility.

The student-facing platform stayed largely custom, because children needed something different from adults. The trade-off was giving up a fully handcrafted system on the teacher and admin side. There was no sense in reinventing a text field when a small change to the stylesheet meets our standards and our branding.

One source of truth for every color and component

Without a central system, colors were raw hex values and components were built one at a time. Changing anything at scale meant finding every instance and tying it back to a new source of truth. Developers had wanted a single source of truth for years, but there had been no designer to take it on until I arrived.

I started with cards, since they appeared everywhere in the product and starting there had the biggest impact. I designed them to be modular, covering summary cards, complex dashboards, calls to action, checklists and videos, so one component could serve all of those uses.

Before. The same jobs, solved differently on every card: inconsistent label styling and layout, key actions like assign hidden behind menus, a checkbox that wasn’t functional, no indication of how long a task takes, and call to action buttons in different places.
Four legacy cards with annotations: inconsistent label styling and layout, key actions such as assign hidden behind menus, a checkbox that is not functional and misleads users about its purpose, no indication of the time cost of a task, and call to action buttons in different places depending on content.
After. Consistent labels, key actions in the bottom bar, an icon that shows the task type, a clear Required label, a time estimate, and every call to action in the same place.
Diagram of the card component: an optional image, a header with up to four labels, an icon and an overflow menu, a body with title, subtitle and paragraph, and a footer with tertiary, secondary and primary actions, each annotated with its rules.
How I viewed the component. One card built from an optional image, a header (labels, an icon, an overflow menu), a body (title, subtitle, description) and a footer (tertiary, secondary and primary actions). Primary actions never hide in the overflow menu.
The same four cards after the design system update, with annotations: consistent labels and styling, key actions in the bottom bar, an icon that shows the task type, a Required label, a time estimate, and all calls to action in the same location.

Then I built the tokens. Nothing was tokenized before this project, so the naming had to make sense to designers and developers who had never worked in a system this technical. I chose a human-centered structure, category, role, component, variant, state, plus a color modifier, that balanced clarity with technical precision and could grow without becoming cryptic or inconsistent. In the end it was about optimization and a clear data hierarchy: one place to change something, and every team working from it.

Color and typography design tokens, such as color-surface-navbutton-default mapped to neutral-100 and font-family-base mapped to segoe-ui, beside the Waterford Reading Academy reports screen with a navigation rail, filters and report cards.
Tokens. Color and typography tokens, beside the Reading Academy reports screen built on the system.

A palette for children, not adults

The old palette focused on one kind of user, the adult, and applied it to everyone. But Waterford’s platform is driven by its students and their engagement. Teachers are a supplement to the digital activities, which run in short 15-minute intervals: you set a student down, the activity does what it needs to do, and the student finishes. Moving from the adult experience to the student experience felt wrong.

My palette for the student side is more inviting and brings in the mascot characters, so students feel like they’re having fun while they learn. I built it with marketing and the art department, working from the character guidebook marketing provided. Some characters couldn’t be used for certain things, I followed those rules, and I went to them whenever I had a question. Across the platform, the palette, typography hierarchy and iconography guidelines are accessible and meet WCAG standards while staying true to the brand’s look and feel.

From one-off styles to a shared system

Proper use of color, shape and type hierarchy creates an enjoyable, predictable experience for every user. Tokens bridge the gap between design and development, and a clear semantic structure keeps the system scalable and easy for every team to talk about.

Buttons

Before
Legacy button set: a filled Primary Action button next to Secondary and Tertiary text links, all in the same teal.
  • No visual hierarchy
  • No predictable outcome for input
  • Poor accessibility
After
Updated button set: a filled blue Primary Action, an outlined Secondary, a plain-text Tertiary and a red Destructive button.
  • Clear visual hierarchy
  • Modernized interaction pattern
  • WCAG 2.1 AA compliant

Text fields

Before
Legacy text fields: a blue-filled field with a colon label, and a red-filled field with an asterisk label.
  • Missing states
  • Ambiguous color patterns
  • Poor accessibility
After
Updated text fields in four states, default, focused, disabled and error, each with a floating label.
  • All states accounted for
  • Standardized color patterns
  • Fully accessible design

Design tokens

Before
A legacy color definition with no tokens: Button/Main, set to the raw hex value #3095B4.
  • Not optimized for development
  • No button states
  • Hex values hard to communicate
After
Updated token structure. A primary button is shown in five states, default, hover, focus, disabled and pressed, each mapped to a semantic token such as button-primary-default, which points to brand-500, with modifiers such as shadow-outer, border-focus, opacity-disabled and shadow-inner. The naming pattern is category, role, component, variant, state, followed by a color modifier.
  • Shared language between design and development
  • Clear button states and semantic naming
  • Brand color understood by every team

Documentation was not enough: six phases, and an adoption lesson

The six phases ran as written, from audit to continuous improvement. Each one produced named deliverables.

  1. Phase 1

    Discovery and audit

    4 to 6 weeks

    Inventoried every component, color, font and interaction pattern across educator dashboards, parent portals and student activities. Interviewed teachers, parents and internal teams, and reviewed accessibility against WCAG 2.1 AA.

    Delivered:UI audit report, pain point map by audience segment, accessibility gap analysis

  2. Phase 2

    Foundations and governance

    3 to 4 weeks

    Defined the unified color palette, type scale and iconography, created design tokens for color, spacing, typography and shadows, and decided how new components are added, reviewed and approved.

    Delivered:Design principles document, token library (Figma and code), governance workflow diagram

  3. Phase 3

    Core component library

    6 to 8 weeks

    Built in order of usage, starting with buttons, form fields, navigation bars, cards and modals. Accessibility came first, and everything was designed for web and mobile.

    Delivered:Figma component library, coded component library, usage guidelines for each component

  4. Phase 4

    Pilot and feedback loop

    4 to 6 weeks

    Applied the system to one high-traffic module, trained designers, developers and content teams, and gathered feedback through surveys, analytics and interviews.

    Delivered:Pilot release, feedback report with prioritized improvements

  5. Phase 5

    Gradual rollout

    8 to 12 weeks

    Migrated module by module (parent portal, student activities, admin tools), retired outdated patterns from the code and design files, and kept internal teams informed.

    Delivered:Updated modules, migration checklist, internal communications toolkit

  6. Phase 6

    Continuous improvement

    Ongoing

    Ran quarterly audits for consistency and accessibility, set up a process for new component requests, and tracked time saved, support tickets and satisfaction.

    Delivered:Quarterly audit reports, updated documentation, roadmap for future enhancements

What the plan did not anticipate

Adoption. I had assumed that once the system was documented and the components existed, teams would start using them. Many designers, and some developers, were comfortable with their existing workflows and hesitant to change, and that slowed the initial rollout.

What closed the gap was more advocacy, more training sessions, and real-world examples that showed the value of the system.

After rollout: faster to build, easier to use, accessible by default

The opening problem was no single source of truth. This is what changed once there was one, for the people building the platform and the people using it.

Front-end library synchronization

  • +62%development speed
  • +80%code reuse
  • −40%bug reports
  • −65%deployment time

How this was measured: developer feedback, QA feedback and Jira ticket velocity, taken over the following quarter and compared year over year.

Task completion

  • +14%task success
  • +38%user satisfaction
  • −41%error reduction
  • −45%training time

How this was measured: user testing with two users a week over the following quarter. About one in five were returning participants from earlier rounds, and the rest were product users I hadn’t personally tested before.

Accessibility

  • WCAG 2.1 AA
  • Keyboard navigation: 100%
  • Screen reader support: 100%
  • Color contrast: 4.5:1 or higher

Adoption is as much about people as it is about process

What went well

Honestly, I was surprised at how smooth collaboration across teams went. The developers were excited and eager to establish this, as they had been wanting a design system for years, and product appreciated being able to understand the value of having such a scalable system across the organization.

What didn’t go as planned

One thing I underestimated was how much effort it would take to drive adoption across teams. I assumed that once the system was documented and components were available, teams would naturally start using them. The truth was that many designers, and some developers, were comfortable with their existing workflows and hesitant to change. Adoption required more advocacy, training sessions and real-world examples to show the value of the system. While it slowed the initial rollout, the extra investment in onboarding ultimately built more credibility and name recognition for the UX team, and more advocacy for the system.

What I would do differently

I would invest earlier in onboarding and education for the teams adopting the system. While the technical foundations of tokens, components and governance were solid, I realized that adoption is as much about people as it is about process. More hands-on workshops, usage examples and quick-start guides up front would have reduced friction and built trust in the system faster.

How the people I worked with describe it

“…instrumental in elevating our design systems and boosting student engagement.”

Jake FaganManaged Alan directly at Waterford.org