Simon Business School - Design System with AI-Assisted Codebase Translation
Simon Business School's website had been built incrementally over several years, and by the time I started this project the codebase reflected that. Thirty-two SCSS files with inconsistent variable naming, nine missing brand colors, dead font files still bundled in production, and no shared language between design and development. The University of Rochester had also just completed a full rebrand, and Simon's digital presence was drifting further from alignment with the parent institution.
The goal of this project was to build a token-based design system in Figma that mapped directly to the live Drupal codebase — cleaning up what existed, filling in what was missing, and creating something that three very different groups of people could actually use: developers building and maintaining components, content editors working in the CMS, and designers creating new campaign work or prototyping solutions.
My Role
Senior UX Designer — Simon Business School Collaborators: Simon development team
I led the design system strategy, token architecture, and component library build. I also worked closely with our developer throughout the process to make sure the Figma system mapped to production reality rather than an idealized version of it, and to deliver handoff documentation that was specific enough to be actionable.
The Problem
The codebase issues weren't obvious from the outside — the site looked reasonably consistent to a casual visitor. But underneath, the foundation had real gaps. Only 5 of the 14 official University of Rochester brand colors existed in the codebase. Variable names were misleading in places — $riverside-green was actually a near-black #252525. Seven identical $font variables were creating inconsistent token mapping. Eight legacy program color variables that were no longer in use were still in the code. There was no documented spacing scale, no sizing tokens, and no component specs that a developer or designer could reference.
On top of the technical debt, the rebrand created urgency. Of all the sub-schools at the University, Simon needed to move toward alignment with the parent brand. That meant the design system wasn't just a cleanup project — it was also the mechanism for getting Simon's digital presence into brand compliance.
The AI-Assisted Process
Rather than manually auditing 32 SCSS files and 89 Twig templates by hand, I used Claude AI as a technical companion throughout the process. The goal wasn't to have AI do the design work — it was to use it to surface issues in an established codebase faster than a manual review would allow, so I could focus on the decisions that actually required design judgment.
Step 1: Codebase audit:
AI analyzed the full Drupal project — every SCSS variable, font-face declaration, breakpoint value, and component pattern — and helped map 94 lines of variables.scss plus styles scattered across 32 files into a single structured inventory.
Step 2: Brand Alignment:
AI cross-referenced every codebase color against the official URochester brand palette. This surfaced the 9 missing colors, identified non-brand colors that needed to be migrated, and flagged the misleading variable names. The goal was to remove legacy styles and bring Simon into alignment with the parent brand.
Step 3: Token Architecture:
Working with the development team, we defined 105 design tokens across colors, typography, spacing, and sizing — each one mapped back to a specific SCSS variable with a clear migration path.
Step 4: Component Translation:
For each component, AI extracted the exact live styles from the codebase so I could match the Figma component to production reality before improving from there. This helped surface responsiveness issues and brand inconsistencies across existing components.
Step 5: Developer Handoff Documentation:
The handoff documentation was written to speak the developer's language — exact SCSS-to-token mappings, code snippets, and bug fix lists rather than visual redlines. The goal was to give the developer the full picture of each component so they could make the right implementation decisions for the codebase rather than just following a spec sheet.
Token Foundation
Phase 1 defined the complete token system across four categories:
-
Colors: 14 official brand colors, extended palette, semantic tokens (text, background, surface, border, interactive, status) with a total of 105 created and updated variables.
-
Typography: Inter Variable (sans-serif), Ivy Presto (serif, H1/H2 only) per official URochester brand guidelines. 6 heading levels, body styles, component-specific styles, all with desktop and mobile scales.
-
Spacing: 17-value scale from 2px to 120px on a 4px base unit, each mapped to specific SCSS variables and usage contexts.
-
Sizing: Border radius values, border widths, icon sizes, button dimensions, container widths, etc.
Component Library
With the token system in place, I built production-ready components with proper variants, auto layout, and full state coverage. The library serves two purposes — it gives developers a spec they can implement directly, and it gives designers a set of components they can use to build new marketing layouts or prototype solutions for stakeholder review without starting from scratch.
-
Buttons: Primary and secondary with 4 states each at desktop and mobile sizes, all consuming design tokens rather than hardcoded values.
​
-
Forms: Text inputs with 5 states, checkboxes with 3 states, and form labels with required and optional variants. Matched to the existing Simon Slate form framework in the codebase.
​
-
Tables: Deadline table with desktop and mobile responsive patterns. Filterable course table with interactive dropdown components and filter pill states.
​
-
Cards: Expandable cards, colored background cards, and list cards in multiple themes — all with full state coverage at desktop and mobile.
​
-
Layout: Drupal section component with 1, 2, 3, and 4 column variants matching the CMS grid system.
Developer Handoff
Every component includes a detailed spec with exact token-to-SCSS mappings. Two examples worth calling out:
​
The deadline table handoff identified swapped colors in production — the developer had navy on table headers and near-black on body text, which was backwards. It also flagged an invalid CSS selector (.deadline-table td:first should be :first-child), a text alignment bug on all td cells, a font override forcing a single typeface across the entire table, and a mobile pattern that was hiding the <thead> entirely rather than using a stacked layout.
​
The filter table handoff delivered a token cheat sheet mapping 8 Figma tokens to existing SCSS variables, a spacing reference with exact values per table element, a typography table for 7 elements at desktop and mobile sizes, JavaScript interaction notes for filter state management, and accessibility requirements with ARIA attributes and keyboard navigation.
What this enabled:
This allowed for a consistent component and layout reference for the live Drupal site, resolution of responsive issues across breakpoints, WCAG-related updates identified and addressed, and developer handoff documentation specific enough that it removed guesswork and kept development moving. Simon now aligns more closely to the URochester rebrand than any other sub-school at the university. Phase 3 page template work and Phase 4 Code Connect token export are both in progress.
Key Takeaways
The biggest shift in this project was treating the design system as something that needed to serve three different audiences rather than just one. Developers needed exact code-level specs they could implement without interpretation. Content editors needed a component library they could use inside the CMS without breaking the design. Designers needed a Figma system they could build with quickly and trust was accurate to what would actually ship.
​
Getting all three of those right required staying close to the codebase throughout — building in Figma while referencing production reality rather than working from an ideal state and hoping it translated. The AI partnership accelerated the translation layer between design intent and code, but the decisions about what to build, how to organize the hierarchy, and what the components should actually look like were still the core of the work.