QUADWORK

Case study · University of Maryland

One system for a campus that never had one.

UMD's web had grown unit by unit for decades. We gave it a shared foundation that every team could adopt on its own terms, and the teams chose to.

Client
University of Maryland, Office of Marketing and Communications, Web Services
Our role
Principal architect; led a team of 9 through an 18-month build and owns the 3-year roadmap
Years
2022–present (public launch summer 2024)
Scale
1,680+ web properties across 12 colleges, 6 divisions and 50+ departments
Services
  • Strategy
  • Design
  • Engineering
  • Accessibility
  • Governance
A grid of design system documentation pages showing heroes, cards, people profiles and statistic components on dark backgrounds.
Component documentation from the UMD design system.
The starting point

Six platforms, no shared parts, and a brand that had drifted.

Every unit built for itself, on WordPress, Drupal, React, Angular, legacy Java or static HTML. Nothing was shared, so the same accessibility failures turned up site after site, and the university's look slowly came apart.

Twelve reds standing in for the twelve hex codes the audit found for one brand color. Shades are illustrative.

12hex codes for one brand red
100+separate button implementations
30+carousels, each built from scratch
An inventory board of dozens of inconsistent buttons and links collected from university websites.
Part of the content inventory: the same button, rebuilt over and over.
What we changed

Four decisions did most of the work.

  1. Put the brand in one file

    A tokens package holds every brand decision: color, spacing, type. It ships as CSS custom properties, JavaScript, JSON and TypeScript types. When the brand team adjusts a color, they edit one value and every component, site and story follows. The same tokens now reach kiosks, event signage and email templates.

    /* simplified example: the brand lives in one place */
    --color-red: #E21833;
    --space-base: 8px;
    --font-sans: "Source Sans", sans-serif;
  2. Meet every team where it already is

    We split the system into nine single-purpose packages in three layers: foundation, core and components. A team can take only the tokens to fix its colors this week, then add components when it's ready. Nobody has to replatform to join.

  3. Earn adoption instead of ordering it

    On a decentralized campus, mandates create resistance. So the system had to be the fastest way to ship. Teams that held out at first joined once they watched colleagues launch faster, and the central team's job moved from building every site to curating the system.

  4. Let automation keep the promises

    Campus teams can't build on on a library that breaks without warning. Every change passes a gate of tests and budgets before it merges, and semantic versioning lets units take updates safely. One accessibility fix reaches every site that uses the component.

How it works

Three ways in, one result.

The same accessible, on-brand output, whether the person adopting it writes code or not.

No code

Copy from the playground

Content editors build a section in a live playground and paste the working markup into their CMS.

Some code

Two CDN tags

Legacy sites with no build step add two tags and get the full component set.

Full stack

Install the packages

Developers install from npm with tree-shaking, in React, Vue, Angular, PHP, Salesforce or Java.

Illustration: three paths labeled no-code, modern code and expert code lead through a park to the same destination.
Guardrails

Every change passes the same gate.

Good intentions don't survive a deadline. A failing check does, so we wrote the standards into the pipeline.

Checks on every pull requestrequired
  • Unit tests across 48 suites1,032+ tests
  • Lighthouse CIscore ≥ 95
  • Bundle size budgetno regressions
  • Core Web Vitalswithin budget
  • Visual regressionno unreviewed diffs
In production

Running on the university's most visible sites.

Results

What changed for the people doing the work.

90%+accessibility scores on adopter sites, up from below 40%
400%increase in design velocityReported by UMD’s Office of Marketing and Communications
70%+lower development cost for some partner units, who stopped paying to rebuild the same parts
50+accessible components in 9 packages

Departments that never talked to each other now share a vocabulary.

For your campus

You don't need UMD's size to get UMD's result.

  • Start with your flagshipWe redesign your main site on a token-driven component library, so the investment doesn't end at one site.
  • Open the door to unitsColleges and departments adopt at their own pace, through whichever of the three paths fits their team.
  • Meet the deadline onceAccessibility lives in the components, so Title II work doesn't have to be repeated on every site.

Talk to us about your campus

Credits & sources

Who did what, and where the numbers come from.

Role
Principal architect, inside UMD’s Office of Marketing and Communications, Web Services.
Sources
magness.im design system series; omc.umd.edu/work/the-umd-design-system; designsystem.umd.edu; github.com/UMD-Digital/design-system
Images
Screenshots are UMD-owned . Diagrams are our own.