CCC Design System

When Navigate Enrollment, Navigate Classes, and the Stanford Bulletin were being designed and built, each had its own visual language, its own components, and its own patterns. Navigate Enrollment was built from scratch — every component created in days during the pitch that replaced Base22's agency work. Navigate Classes built on top of that foundation but diverged as it evolved. The Bulletin was a ground-up redesign with its own requirements.

The divergence was visible in the most fundamental elements. Button styles were inconsistent across products — different corner radii, different sizing, different hover states for what were semantically the same action. Color usage had drifted — the same Stanford red appearing at different opacities and in different roles across surfaces. Card patterns had evolved independently in each product, meaning a student moving from Navigate Classes to the Bulletin encountered information presented in a structurally different way for no reason other than the products had been designed separately.

None of these were catastrophic in isolation. Together, they signaled something a user would feel even if they couldn't name it: these products don't quite belong to each other. For a platform whose entire purpose was to feel unified, that was a fundamental problem.

Without a shared system, three things were inevitable: visual inconsistency across products that were supposed to feel like one platform, duplicated design and development effort as each team rebuilt components the others had already made, and an increasingly impossible goal of eventually merging all three into a unified surface.

A design system wasn't optional. It was the only path to a platform that actually behaved like one.

The system started with the Bulletin's needs — but was always built with Navigator's visual language in mind. Rather than designing from scratch, I took the look and feel established across Navigate Classes and Navigate Enrollment as the starting point and enhanced it: refining the foundations, formalizing what had been implicit, and extending the system to handle the Bulletin's more complex content requirements. The result is a system that feels continuous with the Navigator products rather than parallel to them — which is exactly what integration will require.

The system is organized in two layers that reflect how design decisions actually propagate across a multi-product platform.

Global Foundations establish the visual and interactive language shared across every Connected Curriculum product. Typography defines a unified type scale with defined weights and hierarchy, consistent across Bulletin and Navigator products. Colors use semantic tokens rather than raw hex values — encoding meaning (primary, secondary, interactive, destructive, status) and meeting WCAG 2.1 AA accessibility requirements, with every color decision evaluated for contrast ratio — critical for a platform serving OAE students and a global audience with diverse accessibility needs. Icons provide a unified set covering every interaction state and content type. Buttons and Links standardize interaction patterns covering every state and variant. Error pages ensure consistent 403, 404, and 505 handling across the platform.

Product-specific component libraries give each Bulletin section its own structured vocabulary, organized into four tiers. Local Atoms and Utilities are the smallest indivisible elements: labels, tags, badges, status indicators, input fields, checkboxes. Independent Objects are self-contained components: course cards, program cards, list items, result rows, detail panels, filter chips. Structural Containers are page-level layout components that define how information is spatially organized. Accordion Suites are expandable content patterns handling complex academic content — they exist as a separate tier because they don't just organize space, they manage cognitive load by controlling what is visible at any moment.

This four-tier structure exists separately for Courses, Programs, Policies, and Departments — rather than as one shared product library — because each section serves a meaningfully different user intent and content type. Sharing components at the atomic and global level ensures visual consistency; separating at the product level ensures each section can evolve to serve its users without forcing compromises across sections that have genuinely different needs.

The Completing Connected Curriculum Design System was built for the Bulletin — but it was always designed with the full platform in mind.

When Navigate Classes and Navigate Enrollment integrate into the unified platform — work beginning in the coming months — the design system is what makes that integration feel seamless rather than assembled. The components, tokens, and interaction patterns already exist. Integration means migrating the existing Navigate components to the shared token and component structure — a process made significantly faster because the system was built to match the Navigator visual language from the start. Those products won't need to be redesigned. They need to be unified. A student moving from program discovery in the Bulletin to class search in Navigate Classes to enrollment in Navigate Enrollment will experience one continuous, coherent product. The design system is the reason that continuity is achievable rather than aspirational.

For teams thinking about AI-powered products: a well-structured token-based design system with precisely defined components, documented states, and clear behavioral constraints is also the foundation that makes AI-generated UI components reliable. When the vocabulary is structured and explicit, AI generation has a framework to work within. The system is not just infrastructure for today's products — it's the foundation for whatever products come next.

A design system that lives only in Figma is a reference document. Developers interpret it, approximate it, and gradually diverge from it. The gap between design intent and built output grows with every sprint.

The collaboration model with Stanford Web Services was designed to close that gap from the start. Every component is documented with every variant, every state, and every interaction — detailed enough that SWS developers build directly from the Figma source rather than interpreting or approximating. The result is a design system that functions as source of truth rather than suggestion.

SWS brings engineering depth and their own design capacity. I bring design architecture and product vision. The implementation is a joint output — components I designed and specified in Figma, built and reviewed through a shared process with SWS engineers. This is not a design system handed over a wall. It is a system built in active collaboration between design and engineering, which is why it's actually being used.

Building a design system at this scale — across three products, four sections, two tiers — involves significant documentation work that does not benefit from being done manually. I used AI tools to accelerate the parts of system-building that are about consistency and completeness rather than judgment.

Figma Make — I used Figma's AI features during component creation for naming consistency, layer organization, and generating content variations for realistic component states. A design system with inconsistently named layers and components creates confusion for anyone who inherits it. Figma Make kept the system organized at a level of consistency that manual naming rarely achieves.

Claude — I used Claude to draft and refine component documentation, structure the information architecture of the system itself, and think through edge cases in component behavior. When designing the Accordion Suite — which needed to handle policy content, degree requirements, and course details with meaningfully different nesting structures — working through the variations with Claude helped identify gaps before they became developer questions.

The principle is the same as everywhere else: AI handles the work that benefits from speed and consistency. Judgment about what components the system needs, how they should behave, and what constraints they should encode — that remains the designer's work.

The Completing Connected Curriculum Design System is live and actively used by Stanford Web Services developers building the Bulletin today. The library covers 180+ components across global foundations and four product-specific sections — every component documented, every state defined, every variant specified.

The system has already eliminated duplicated design work across Bulletin sections — components built once for Courses are available to Programs, Policies, and Departments without being rebuilt. It has reduced the design-development gap through detailed Figma specifications that SWS engineers build from directly rather than interpreting loosely.

And when Navigate Classes and Navigate Enrollment integrate into the unified platform in the coming months, the system extends its reach to the entire Connected Curriculum ecosystem — making the unified platform vision concrete rather than conceptual, because the design language already exists and the remaining work is integration, not invention.