Simon Business School — Design System & Brand Governance
Project Overview
In late 2025, the University of Rochester rolled out a new brand identity, its first real update in over twenty years. The university was after stronger recognition globally, and part of that meant every school under the URochester umbrella showing up with one consistent, modern look instead of a dozen slightly different ones.
Simon wasn't set up for that. The website had grown piece by piece over the years, with nothing underneath tying it to any kind of brand standard. Design decisions got made page by page, by whoever happened to be working on it at the time. So when the parent brand changed, there was no easy way to bring the site along with it.
This project fixed that. I built a token-based design system that connects the URochester brand standards to Simon's live Drupal platform, a component library that designers, developers, and content editors all work from, and a process for keeping design and development in sync as the brand keeps evolving.
My Role: Lead UX Designer
I led the design system work, building a system that did not exist before. It started with an audit of where Simon's brand actually stood across the site, which meant going through the existing pages and the Drupal codebase to see how far things had drifted from any consistent standard.
From there I defined the token architecture, mapping the URochester brand standards, colors, typography, spacing, and responsive guidelines, into a system of design tokens that could connect directly to how the site is actually built. I built out the component library on top of that, so designers, developers, and content editors were all pulling from the same set of pieces instead of rebuilding things their own way. And I set up the workflow between design and development to keep the two in sync as the brand keeps evolving.
I worked closely with our developer throughout, which was a big part of why the system holds up. This new design system matches how the site is actually built and maintained, not just how it looks in a design file.
Tools: Figma, Claude, Drupal 9, Sitecore.
The Opportunity
The rebrand brought a long-standing problem at Simon to the surface: there were brand guidelines, but nothing actually holding the website to them.
Guidelines can tell you what the colors and typefaces are supposed to be, but they can't stop a site from drifting when it's being maintained by many different editors, across different platforms, over a span of years. When I checked Simon's site against the official brand standards, less than half the brand palette was included in the foundation, the typography was applied inconsistently, and there was no single place a designer, developer, or content editor could go to reference component usage and guidelines.
Simon's website is the school's most visible recruitment channel, and for a lot of prospective students, it's their first real look at the school. We had a goal to make sure Simon maintained its own brand identity, while still feeling like an extension from the larger University brand as a whole.
Before
After
The Impact
Simon is now more aligned with the new URochester brand than any other school at the university. And because that alignment is built into the tools people use day to day, keeping it that way doesn't rely on someone noticing when a page falls out of line. It also holds across everything a prospective student might see, whether that's the main site, a campaign landing page, or another marketing channel, so Simon looks the same no matter where they come across it.
Before
After
Handoffs between design and development got a lot smoother. Before the system, every handoff meant the developer had to interpret the mockups, ask what values to use, and figure out how the design fit with what was already in the code. Now both sides pull from the same named tokens, so most of that back-and-forth just goes away.
Campaign pages also come together faster now. The marketing team can build new pages from components that are already on brand, instead of asking for new design work every time one comes up. During recruitment cycles, when there's a lot to get out the door quickly, that makes a real difference.
Before
After
The system also holds up over time instead of slowly falling out of sync the way the old site did. The workflow is straightforward: I make the design changes in our design system file, flag anything that needs to happen on the development side, and our developer goes in and makes those adjustments in the code. Because every change runs through that same path, the design file and the live site stay matched up instead of drifting apart.
The old site drifted because there was nothing like this in place. Changes would get made in one spot and never make it to the other, and over enough time the site stopped matching any standard it was supposed to follow. Now there's a clear handoff for every change, so the system stays accurate as the brand keeps evolving rather than falling behind between updates.
Before
Updated fonts, background colors, button styles, and inline text links repsonsive to each color background.
The Strategy
The university had built the new identity, but a finished set of brand guidelines and a website that actually reflects them are two very different things. The identity existed on paper. Getting it onto Simon's live site, across years of accumulated pages and multiple people maintaining them, and keeping it there without someone manually policing every change, was the real work, and that's what the system had to solve.
The system was built around three ideas.
Tokens connecting the brand to the code. Every brand decision, the colors, type, spacing, and sizing, became a design token that maps directly to something in Simon's live platform. When a standard changes, I change it in one place and it updates everywhere it's used. It also means that when the university puts out future brand updates, Simon can pick them up without rebuilding anything from scratch.
A component library that works for the people actually using it. Three different groups rely on this system, and they each need different things from it: designers building campaign work, developers maintaining the site, and content editors updating pages in the CMS. Building for the content editors was probably the most important call I made. Most of the day-to-day changes to Simon's site are made by people who aren't designers, and if the system only holds up when a designer is in the loop, it doesn't really work. So the components had to be set up so that the on-brand choice was also the easiest one to make.
A process to keep it from falling apart. Design systems go stale if nobody maintains them. Rather than tack that on afterward, I made the change-tracking process between design and development part of the system itself. Every update gets documented, passed to development, and built the same way, so the system stays current instead of slowly drifting.
Measurement
The system works because of how it's built, not just what it looks like. Everything runs on reusable tokens, so a brand value like a color or a type size is defined once and pulled in everywhere it's used, rather than hard-coded page by page. When something needs to change, it changes at the source and updates across the board.
The component library works the same way. The components aren't static pieces thrown together to look right once. They pull directly from the variable definitions and use auto layout, so they stay consistent and adjust properly across different screens and contexts on their own. That's the difference between a library that actually holds up as the site grows
and one that quietly breaks the first time someone needs a variation nobody designed for.
Because it's built this way, the system stays accurate as things change instead of drifting, and the people using it don't have to rebuild the same things over and over to stay on brand.
Implementation
The work rolled out in phases, going from audit to foundation to adoption without disrupting the live site.
Brand audit and token foundation. I started by auditing Simon's site against the official URochester standards to see where the gaps actually were, then defined the full set of tokens off of that. I used Claude AI to help with the audit, which surfaced inconsistencies across the site faster than going through it all by hand would have.
Component library. I built out production-ready components for the site's core needs: buttons, forms, tables, cards, and the layout structures that match Simon's CMS. For each one, I matched it to what already exists in production first and then improved from there, so the Figma system and the live site always describe the same thing rather than drifting apart.
Handoff and upkeep. I wrote the handoff documentation around how our development team actually works, and set up the ongoing change-tracking process between design and development so the system stays current after launch.
A source of truth for content. I put together a single reference that content editors can go to when they're updating pages, so the site stays consistent no matter how many people are working in it. Since most of the day-to-day changes come from people who aren't designers, having one clear place to check keeps everyone making the same choices instead of each person deciding on their own.
Key Takeaways
Brand guidelines on their own don't get you brand alignment. You need a system behind them. The rebrand gave Simon the reason to change, but the design system is what actually got the site aligned and keeps it that way.
The second thing was realizing who a design system is really for. Building for the content editors, not just designers and developers, is what made the whole thing work. At most places, the people in the website every day aren't designers, and a system that ignores them falls apart in production no matter how good it looks in Figma.
This project also shifted how I think about design systems in general. The components are the part people see, but the real value is that it gives the school a way to put its brand out consistently and quickly across everything it runs, instead of rebuilding it every time.
Future Considerations
The work on this will be an ongoing process maintained over time for brand consistency as the University evolves. The most immediate next step is extending the system past individual components to full page templates, so the layout-level consistency across Simon's web properties falls under the same model instead of being handled site by site. There's also room to connect the token system more directly to the production codebase, which would cut down the handoff between design and development even further.
Longer term, the token setup was built so the university's future brand updates can be picked up without a rebuild, so the system should keep holding as the parent brand evolves. And the same approach could extend past the visual side into content, giving copy and messaging the same kind of shared standard the components have now, so the way Simon sounds stays as consistent as the way it looks.