The Design System

The design system had one constraint that shaped every decision: it needed to work for three distinct campuses. Bozeman, Billings, and Northern each have their own visual identity, their own audience, and their own editorial teams. The system had to be flexible enough to respect that without fracturing into three separate codebases that would eventually drift apart and become impossible to maintain.

The solution was a shared variable architecture. Each campus lives in its own folder with its own colors, typography, and theme values. But every campus uses the same variable names, linked back to a single base.css. Campus A changes what blue means. Campus B changes what blue means. The system doesn't care, it just knows there's a blue. It's a clean separation of identity and structure that should hold up for years without requiring a developer to untangle it.

For color specifically, we landed on Radix. The decision wasn't aesthetic, it was practical. Radix ships with a built-in scale and accessibility baked into the palette construction. It removed a whole category of contrast decisions from the table, which matters when you're building a system that 1,200+ editors will be using to publish content you'll never personally review.

Typography follows the same logic. The scale is systematic, not ad hoc. Decisions about size, weight, and hierarchy were made once, at the token level, so they don't have to be made again at the component level.

The component library grew out of a research process that was, honestly, pretty extensive. Analyzing hundreds of university websites over the course of a year, looking at what types of content higher ed editors actually need, what gets built over and over, and what tends to get misused. Not just visually, but structurally. What does an accordion want to be? What does a stat block need to communicate?

That research shaped 20+ content sets, each one a deliberate answer to a content problem. The accordion is a good example. On the current MSU website, there are accordion headlines close to 200 characters long. Those questions have had zero clicks in the past year (see the screenshots below!), while shorter headlines around them perform fine. When we built the new accordion, we capped the headline field at 100 characters. Not because of an arbitrary style preference, but because the data said long questions don't get opened. The character limit is a UX decision disguised as a field constraint.

That kind of thinking runs through the whole library. Every field, every constraint, every label in the CMS is an opportunity to either guide an editor toward a good decision or leave the door open for a bad one. We tried to close as many of those doors as possible.

damning evidence of how long titles perform on the old website. this is 2 examples of many.