CCC Design System
Building the Foundation for Stanford's Unified Academic Platform
I led design across all three of Stanford's academic products in this ecosystem: Navigate Enrollment, Navigate Classes, and the Stanford Bulletin. Navigate Enrollment and Navigate Classes launched first, both built on Stanford's existing Decanter design system, by Stanford UIT.
After launch, user testing on those two products surfaced a finding. Decanter's type and UI needed to change. That finding started the Completing Connected Curriculum Design System. I built a new system and applied it first to the Bulletin, which was still in design at that point. Navigate Enrollment and Navigate Classes stay on Decanter for now. Migration to the new system is planned for next year.
Lead Product Designer
Stanford Web Services
UXDS
Challenge
How do you design and build a new system in time to launch with a product still in progress, while two live products keep running on the system you're replacing, and set up a path to bring them onto the new system later?
Research
Testing on the live Navigate Enrollment and Navigate Classes products surfaced a finding. Decanter's type ran too large. Students and staff read the interface as heavy and dated relative to the tasks in front of them. The finding came up repeatedly across testing sessions. It pointed to a barrier on content-dense screens, where fast scanning matters.
That finding justified building a new system instead of adjusting Decanter's existing components. The Bulletin, still in design at the time, became the first place the new system could apply. It wasn't yet locked into Decanter the way the two live products were.
Constraints
The system had to work for two situations at once. The Bulletin could adopt it from the ground up, every component built to the new foundation from day one. Navigate Enrollment and Navigate Classes couldn't do the same without a planned migration. The system had to hold up when that migration happens next year, not get redesigned again at that point.
In the meantime, an inconsistency exists in production. The Bulletin runs on the new system. Navigate Enrollment and Navigate Classes still run on Decanter. The gap is sequenced. A user can encounter it today moving between products.
The system also had to serve two engineering teams with different processes. Stanford UIT builds Navigate Enrollment and Navigate Classes. Stanford Web Services builds the Bulletin. Both teams build from the same documented source when their part of the migration happens.
Key user needs
- As a student or staff member, I need type and UI dense enough to scan quickly, without slowing down, so I find what I need without extra effort.
- As a Stanford UIT or Stanford Web Services developer, I need one documented system built to handle both a ground-up build and a future migration, so I work from a fixed source, not from assumptions.
- As the design owner across all three products, I need a system ready for Navigate Enrollment and Navigate Classes before their migration starts, so the work happens once.
Key features
Global foundations
Typography moved to a smaller type scale, a direct response to the testing finding on Decanter, with a defined hierarchy built to apply across the Bulletin now and the Navigator products at migration. Color runs on semantic tokens instead of raw hex values. Primary, secondary, interactive, destructive, and status roles each carry their own token. Every pairing meets WCAG 2.1 AA contrast, a requirement on a platform serving OAE students and a global audience with a range of accessibility needs. Icons cover every interaction state and content type. Buttons and links standardize state and variant. Error pages handle 403, 404, and 500 the same way, and the pattern extends to Navigate Enrollment and Navigate Classes at migration.
Product-specific component libraries
Each Bulletin section, Courses, Programs, Policies, and Departments, runs its own four-tier taxonomy. Local atoms and utilities are the smallest indivisible pieces: labels, tags, badges, status indicators, input fields, checkboxes. Independent objects stand on their own: course cards, program cards, list items, result rows, detail panels, filter chips. Structural containers define page-level layout. Accordion suites hold complex academic content and control what a user sees at any given moment. That function sets accordion suites apart from spatial layout, so they hold their own tier.
Sharing components at the global and atomic level supports the migration planned for next year. Navigate Enrollment and Navigate Classes won't need new foundations built from scratch. They need their own product-level components layered on what already exists.
Built for a staged rollout
Every component carries documentation across every variant, state, and interaction. Stanford Web Services builds the Bulletin from the Figma source today. Stanford UIT can build Navigate Enrollment and Navigate Classes from that same source when migration starts.
I own system architecture and product direction across both teams and both timelines. Each engineering team runs its own build and review process on its own schedule. The system holds across that staggered rollout.
AI in the process
A system built for a staged rollout carries documentation work. It has to specify behavior clearly enough to build once now and build again correctly next year. I used AI tools where speed and consistency mattered more than judgment.
Figma Make supported naming consistency, layer organization, and content variations for realistic component states during creation. Inconsistent naming creates friction for a team building from the system a year from now. Figma Make held that consistency at a level manual work rarely sustains.
Claude supported drafting and refining component documentation, structuring the system's own information architecture, and working through edge cases in component behavior. The Accordion Suite had to hold policy content, degree requirements, and course details, each with its own nesting structure. Working through those cases with Claude surfaced gaps before they became developer questions, now for the Bulletin and later for the migration.
The principle stayed constant across both tools. AI handled speed and consistency. Judgment on what the system needed, how components should behave, and what constraints they should encode stayed design work.
Reflection
Building this system after Navigate Enrollment and Navigate Classes had already launched set the terms of the work. The system had to prove itself on one live product's testing data, get built correctly for a product still in design, and stay ready for two more products it wouldn't touch for another year.
The work centered on a foundation precise enough to apply today and hold up unchanged when Navigate Enrollment and Navigate Classes migrate next year. I built it without knowing exactly what that migration will surface once it starts.
The system runs in production for the Bulletin today, with more than 180 components across four product sections and one shared foundation grounded in the Decanter testing. Navigate Enrollment and Navigate Classes still run on Decanter, migration planned for next year. The Bulletin carries the system's first proof point. The migration is where it runs at full scale.