C Spire Design System

Overview

I joined C Spire as a web designer working in AEM. Within days, it was clear something was wrong — not in any single file or component, but in the whole picture. The design environment was a junk drawer. Mixed styles, outdated options, patterns with no clear relationship to the brand, and a visual language that had accumulated over the years without anyone deciding what it should be.

I spent a year working inside that environment before I was asked to fix it.

When my manager's boss approached me about taking on the Design System Manager role, I said yes without hesitation. I already knew what the problems were. I had been living inside them. What I didn't fully anticipate was how difficult it would be to change a system that most people didn't realize was broken — and how much of that difficulty would come not from the work itself, but from the people surrounding it.

I still believe it was worth doing. I still believe it is worth continuing. That belief gets tested regularly. It hasn't broken yet.

The Situation

The brand existed in single-layer Illustrator files.

That detail says everything. Not a token system, not a living style guide, not even a well-maintained PDF — single-layer Illustrator files that required manual interpretation every time someone needed to apply the brand to something new. Visual direction shifted with campaign cycles. What the brand looked like in January was not necessarily what it looked like in March. There was no stable foundation to build from because stability had never been the goal. The goal was the next campaign.

For the digital side of the organization, this created a specific and compounding problem. The primary brand reference was a print-focused PDF — a document built for collateral and campaigns, not for screens. It contained no meaningful information about digital application: no spacing system, no color tokens, no typography scale, no component behavior, no guidance on how print decisions should translate to interactive surfaces. It was the wrong document for the job, and it was the only document anyone had.

What filled the gap was fragmentation. Three to four major teams across the organization had developed their own design styles over time. Some were distinctly different from each other. Most had fragmented further internally, with individual groups pulling from two or three additional visual references of their own. In some corners of the organization, there were genuinely competing ideas about what the brand was — not variations on a theme, but parallel realities that had never been required to reconcile.

Most people working inside this environment did not experience it as a problem. When asked what they designed from, they pointed to the PDF. When asked whether they had a design system, they said yes — meaning the PDF, or the Figma files their team used, or the patterns they had developed over time. They didn't know what they didn't know. The absence of a shared foundation wasn't a gap anyone had formally named. It was just how things worked.

That invisibility was the hardest part to address. A problem people can see, they can be motivated to fix. A problem that feels like normal operations requires a different kind of work entirely — not just building something better, but first making the case that better is possible.

The Constraint

The hard part was not the absence of tooling. It was the absence of shared reality.

I was not stepping into an organization that agreed on what the brand was. I was stepping into one where multiple groups each believed their version was correct, where the people responsible for brand had never been asked to define it for digital contexts, and where the concept of a design system — what it was, how it worked, why it was different from a PDF style guide — was genuinely unfamiliar to most of the designers who would need to use it.

The political reality surfaced quickly. When it became clear a design system was being built, the brand team — who had not been involved in the early work — attempted to insert themselves into the process. Not by contributing. By withholding. Colors, typography decisions, foundational brand details that would have helped us move faster and in alignment were not shared. Brand decisions were communicated to leadership without including us. When we asked for input, it didn't come. When we proceeded without it, the response was resistance — sometimes quiet, sometimes not. There were meetings where the frustration became loud. There were teams that simply ignored the system and continued working the way they always had. There were designers who escalated complaints to their leadership rather than engaging with the process directly.

The authority gap underneath all of this was real. Leadership had approved the design system. But approval is not the same as explicit, visible expectation-setting. When the people responsible for enforcing a new standard don't make clear that the standard is mandatory, the people being asked to change their behavior make a reasonable calculation: this is optional. And optional standards, in a fast-moving organization, are not really standards at all.

I want to be honest about what I think drove most of the resistance. Change is genuinely hard. People protect what they've built. A new system can feel like a judgment on the work that came before it — on the decisions that were made, the files that were created, the styles that were developed over years of trying to solve real problems with inadequate tools. I don't believe the resistance came from bad intent. I believe it came from fear and familiarity, which are harder to address than disagreement.

The mandate gave us the authority to move. It did not give us alignment. Those are different problems, and for a long time, we were solving both at once.

How I Thought About It

The decision to move fast and establish a core before involving other teams was not mine to make. Leadership made that call. What was mine was figuring out how to execute it well — how to build something stable and trustworthy inside a politically complex environment, with incomplete information, and without the luxury of waiting for consensus that was never going to come organically.

My manager and I built first. Two people. We worked from what existed — the brand guidelines, the Figma files we could find, the visual patterns we could identify across the organization — and made judgment calls about what the digital foundation should be. Some of those calls were informed. Some were made in the absence of information the brand team had but wouldn't share. We moved anyway.

I started with tokens and architecture rather than components. That is a slower path to something anyone can see, but a faster path to something that actually scales. Components built on an inconsistent foundation drift the same way the old disconnected files had drifted. I wanted the structure to be right before the library grew on top of it — because fixing the foundation after the library exists is significantly harder than getting it right before.

Governance was part of the architecture from the beginning. Not as a control mechanism — as a way to reduce unnecessary decision-making. Inconsistency rarely comes from bad intent. It comes from local decisions made in isolation, by teams solving the same problem independently without a shared reference. A contribution model and a defined process for adding, reviewing, and updating components meant the system could grow without losing coherence. The standard had to be clear enough that teams could move faster with it than around it.

Accessibility was built into the defaults from day one. If the system was going to become the shared foundation for every product surface, accessibility decisions made at the system level would multiply across every component and pattern that inherited them. One sound decision — made once, at the right level — improves everything built on top of it. I was not willing to retrofit that later.

The education work was constant and is ongoing. I held sessions on what a design system is, how it works, why it is different from a brand PDF, and what role everyone plays in making it sustainable. Some of those conversations landed. Some didn't. I learned to separate the people who genuinely didn't understand from the people who understood but chose not to engage — because those two situations require completely different responses. For the first group, clarity and patience. For the second, escalation and documentation.

What I kept coming back to — what kept me steady when the resistance felt heaviest — was why this work matters in the first place. When a design system works, it gives people something most designers never get: the freedom to create without having to solve the same foundational problems every time. The harder decisions have already been made. The guardrails are already in place. You can just build. That vision was worth protecting, even when the path to it was harder than I expected.

What I Built

The decision to move fast and establish a core before involving other teams was not mine to make. Leadership made that call. What was mine was figuring out how to execute it well — how to build something stable and trustworthy inside a politically complex environment, with incomplete information, and without the luxury of waiting for a consensus that was never going to come organically.

My manager and I built first. Two people. We worked from what existed — the brand guidelines, the Figma files we could find, the visual patterns we could identify across the organization — and made judgment calls about what the digital foundation should be. Some of those calls were informed. Some were made in the absence of information the brand team had but wouldn't share. We moved anyway.

I started with tokens and architecture rather than components. That is a slower path to something anyone can see, but a faster path to something that actually scales. Components built on an inconsistent foundation drift the same way the old disconnected files had drifted. I wanted the structure to be right before the library grew on top of it — because fixing the foundation after the library exists is significantly harder than getting it right before.

Governance was part of the architecture from the beginning. Not as a control mechanism — as a way to reduce unnecessary decision-making. Inconsistency rarely comes from bad intent. It comes from local decisions made in isolation, by teams solving the same problem independently without a shared reference. A contribution model and a defined process for adding, reviewing, and updating components meant the system could grow without losing coherence. The standard had to be clear enough that teams could move faster with it than around it.

Accessibility was built into the defaults from day one. If the system was going to become the shared foundation for every product surface, accessibility decisions made at the system level would multiply across every component and pattern that inherited them. One sound decision — made once, at the right level — improves everything built on top of it. I was not willing to retrofit that later.

The education work was constant and is ongoing. I held sessions on what a design system is, how it works, why it is different from a brand PDF, and what role everyone plays in making it sustainable. Some of those conversations landed. Some didn't. I learned to separate the people who genuinely didn't understand from the people who understood but chose not to engage — because those two situations require completely different responses. For the first group, clarity and patience. For the second, escalation and documentation.

What I kept coming back to — what kept me steady when the resistance felt heaviest — was why this work matters in the first place. When a design system works, it gives people something most designers never get: the freedom to create without having to solve the same foundational problems every time. The harder decisions have already been made. The guardrails are already in place. You can just build. That vision was worth protecting, even when the path to it was harder than I expected.

The Outcome

The system is live. It is in active use. It is getting better.

Those three sentences matter more than they might sound, given everything it took to get here.

Components are being added and refined. The token architecture is holding. The contribution model is in place. And one of the most meaningful developments has been quieter than any of those things — watching a designer on the team begin to genuinely understand what the system is for, and start championing it with other designers. Early adoption momentum rarely looks like unanimous buy-in. It looks like one person who gets it, starts making the case to their peers, and makes the standard feel less like a mandate and more like a shared way of working. That is happening. Slowly, but it is happening.

What I keep coming back to is this: a design system's value isn't always visible in a single artifact or a single release. It shows up in the decisions that don't have to be made again. The patterns that don't have to be rebuilt. The inconsistencies that get caught at the system level before they spread. Every time a designer opens the library and finds what they need without having to invent it, that is the system working. Every time a component gets updated in one place and the change propagates correctly, that is the system working. Those moments don't make for dramatic case study metrics. They make for a better place to work.

I want that for everyone on the team. Even the ones who are still resisting.

What I'd Do Differently

I would have pushed for formal leadership alignment earlier — not just approval, but explicit, visible expectation-setting with every team that would be affected. Approval from the top created the mandate to move. It didn't create the conditions for adoption. Those are different things, and I would have worked harder to close that gap before the resistance had time to organize around it.

I would have brought the brand team into the conversation differently — not waiting for them to insert themselves, but creating a structured role for them from the beginning that gave them real input without giving them veto power over decisions that needed to be made. Whether that would have changed the outcome given the dynamics involved, I genuinely don't know. But the attempt would have been worth making earlier.

I also would have defined success metrics from the start. The system is clearly reducing design debt and improving consistency — but impact that isn't measured is impact that's hard to defend when priorities shift or resources get reallocated. Baseline measures, adoption tracking, and component usage data should be part of the operating model from day one, not something you retrofit when someone asks how it's going.

The harder reflection is this: I've learned that the most difficult part of this work isn't technical. It isn't even political, though the politics are real. The hardest part is holding onto your belief in what you're building when the people around you are afraid of it.

I understand that fear now in a way I didn't when I started. Change feels threatening when you don't know what's on the other side of it. People respond to that threat in ways that can be painful to be around — and I won't pretend it hasn't been, at times, disheartening. But I've come to believe that the fear and the resistance aren't really about the system. They're about the unknown. And the unknown becomes less threatening the more you can show people what's waiting there.

A good design system doesn't take things away from designers. It gives them something back — the freedom to create without having to solve the same foundational problems every time. The harder decisions have already been made. The guardrails are already in place. You can just build.

I believe most people, given time and the right environment, will choose that. Not because they're told to. Because it genuinely makes the work better.

That belief is what keeps me building.