There was a previous attempt to establish a universal design system using PrimeNG as a base for UI components and tokens, but only some designers followed it, and without guidelines in place, any use of it was inconsistent. I talked to designers, developers, and product owners to understand why they didn’t use it, to get a real sense of what people actually needed from a design system before proposing another one.

I audited what styles and components were used across the applications, to find where things overlapped, shared patterns existed, discover component needs and gaps, flag accessibility issues, and identify technical constraints, so I could make informed decisions on the new design system’s strategy and build components and patterns that bridged gaps, met accessibility compliance, and suited the applications’ various component needs and variations. I also checked everything against CenterPoint’s brand guidelines to see where existing styles matched brand standards and where they didn’t. Below are some of the elements used across the different systems and products.

One proposed option was to keep the AI products on their own system, create a separate system for the rest of CenterPoint’s internal and external applications, and keep the marketing website separate as well. The AI products already had a strong, consistent system, used mostly by an outside agency, and it was beneficial for them to look and feel distinct so users knew they were interacting with AI. The website would stay separate because it had just been redesigned by another agency, was governed by marketing rather than product, and used a very different set of components: pill buttons and inputs, a top-level nav with dropdowns, a link-heavy footer, cards with images and blocks of text, and hero sections.

This option would have meant lower disruption, faster implementation, and a better chance of successful adoption. However, it would have required maintaining more systems over the long term and risked inconsistency.

The other proposed option was to merge everything into a single, centrally owned design system. Primitive tokens and a core component library would be shared, with additional libraries for AI and marketing-specific components. This approach would provide the highest consistency and lowest long-term maintenance. However, the level of governance required might not be possible to achieve or sustain with so many applications, designers, outside agencies, and product owners with their own priorities, keeping everyone aligned to one system long term would be a risk.

After several discussions, we chose neither of the two original options. Instead, we kept the AI design system separate and built a new, unified system for all non-AI products, with a separate component library for marketing-site-specific components. The decision came down to distinct style needs, content needs, team structure, and the likelihood of successful adoption.

AI products benefited from looking different so users knew when they were interacting with AI, while the rest of CenterPoint’s applications needed something simpler and more corporate to build trust with a wide audience. A strong AI design system was also already in use and well maintained across multiple applications.

We built the new system on the marketing website’s foundations, since they already captured all of CenterPoint’s brand elements, and merged in the components that also worked for the rest of the applications. The remaining components were branched off into a marketing-specific UI kit.

I developed a roadmap for building the new system and rolling it out across the applications.

I built the new system on top of the core identity and brand standards, bringing in the marketing foundational styles and creating new components for web and mobile needs. Over several months, I partnered with designers and developers across product teams to test, validate, and refine everything in their product work.

I built color ramps from the brand colors, folding in the marketing website’s colors and gradients. Brand blue and its tonal variations are the dominant color throughout the system.

Brand guidelines specified Proxima Nova for web, but most applications, including the website, already used Inter. Proxima Nova isn’t open source, so it was much harder to use across applications. I brought this concern to brand directors, and they agreed to make Inter the standard.

Once the foundations were established, I met with brand managers to walk through the elements and how they’re used, and make sure everything stayed in sync with the established brand standards.

I created components for web and mobile needs across the organization’s applications. Throughout the process, I met regularly with product designers from each team to gather feedback and make sure the components fit their needs. I carried over suitable components from the website system and moved the ones that weren’t a fit into a separate marketing UI kit.

Designers tested the components on their own screens and in new designs, and I revised them based on their feedback, which meant months of back-and-forth across teams. I also worked with developers to identify and close technical gaps, test the built components, and shape the storage and documentation strategy. Below are a few examples.

After piloting and refining components with designers and developers, I created documentation for each component to aid in proper usage and implementation. The documentation included:

• When to use and when not to use it
• Anatomy, including hidden options
• Variants and states
• Properties, tokens, and styles, and where they apply
• Dos and don’ts
• Accessibility requirements
• Content guidelines

I defined patterns that show how to handle common experiences using the components. They give users consistent behavior as they move between products and give designers and developers ready-made solutions instead of starting from scratch and accessibility compliance is built into the structure. Below are some of the patterns that were created.

I created a contribution process and guidelines, and a Microsoft Form for submitting new component or token requests, changes to existing ones, and promotions to core.