Comcast Xfinity: Celestial Design Sytem

Started before Celestial, XDS was initially created to bring unity across customer-facing experiences, mainly the Xfinity.com website, the My Account portal, and the Xfinity app. Early on while working on feature teams, I identified that since these experiences serve a different purpose, the existing design system doesn't meet the robust needs of a product like Celestial.

XDS's primary visual characteristics are that they are high contrast and have lots of white space, which wasn't translating well in a information-dense product like Celestial. Agents need to be able to see more content on the screen at any given time, which calls for a more nuanced styles and complex components to establish visual hierarchy.

Under the hood, the XDS components were often not passing the accessibility standards required by Celestial, whether related to contrast ratios, aria labels, or interaction triggers.

After working with XDS for a few months, our core team defined three areas where the system was lacking:

1. Common enterprise components such as popovers, tables, and file upload areas
2. Extensive pattern documentation; for example, documenting different types and hierarchical levels of alerts within a system
3. An emphasis on accessibility across all device types and for users with all types of assistive devices

With the support of our design lead, myself and our principal designer, Alyssa Martin, set up bi-weekly office hours to discuss any challenges our designers were facing with the hopes that we could come to solutions together.

Along the way, we worked to formalize this process: creating intake forms, documenting solutions, and tracking any requests we made to other teams. We started in Airtable and then moved more formally into Jira so that our CDS team was also tracking against the same sprint cycles as all other pods.

As CDS began to intake more work, we sought to define our system by three guiding principles: accessibility, affordance, and elegance.

• Accessibility: Above all, we strive for inclusivity and want our product to be as accessible as possible. For us, that means components aren't created in a vacuum where all designs are perfect; instead we create alongside our UX engineers, problem-solving together for how best to handle a component for all kinds of users (including but not limited to: keyboard users, screen reader users, and those with cognitive disabilities). Every component is stress-tested and goes through an accessibility check before ever being handed off to development.
• Affordance: One of Celestial's biggest challenges with using XDS was that the high-contrast design language didn't give our users enough affordance to understand what they were supposed to expect from a given component. Since it is a requirement that Celestial uses XDS as much as possible, we've taken it upon ourselves to define minimum affordance guidelines for each component.
• Elegance: Our CDS team is made up of product designers who were all originally trained in a branding or marketing space, so in addition to making sure our designs are accessible and affordant, we also want them to look elegant and professional. We write well-documented spec sheets and work together to ensure every hand-off is pixel perfect.

XDS offered little guidance in how to use their components; as a result, we saw pods using components inconsistently. We created a “Patterns” file where we documented known use cases in order to give better guidance on how to use XDS out-of-the-box.

For example, we knew some of the styles (especially the buttons) were not particularly suited for a product like Celestial. Our designers had a difficult time knowing when to use which button style and how to give enough affordance. As a result, we created our own documentation for frequently asked questions and for how to achieve the minimum affordance required by Celestial.

Sometimes while helping other pods, we came across an XDS component that was not up to Celestial’s accessibility standards or one that could be revised a bit so that we didn't have to create a new component from scratch.

In these cases, we audited the component and brought our proposed changes to XDS, asking them to make adjustments based on our research and examples. If XDS accepted the changes, they’ll be absorbed into their kit where the components and documentation will be updated; if they don’t, I would build a CDS-specific component.

The CDS team also handled all Celestial-specific components and compositions, such as space headers, toolbars, and anything XDS wouldn't absorb. While creating these in Figma, we worked closely with our development partners to thoroughly stress-test for accessibility during the design phase.

After consulting with the team, I am was for building a Figma component in our own UI library, writing extensive documentation, and releasing the component to all pods via a Teams channel and a bi-weekly meeting.

Another significant part of our work was educating different audiences about what CDS is, what our team does, and how we inform other teams on Celestial. We've had given an overview presentation similar to the one below a few times; we shared this information with legacy product stakeholders, new teammates, and adjacent Xfinity teams. I had even used a similar deck internally at Think Company during work-shares and for a deep dive example on design systems.

Since CDS was put together after teams had already started shipping design work, there was a of catch-up work to be done. Pods had been following the documentation regarding process, file structure, dev hand-off guides, patterns, and components that CDS released, but they hadn't necessarily updated any files prior to when a piece of documentation was released.

With Celestial's first major release in Q1 2024, one of the last items I worked on was completing an audit of all design and development work, in addition to our usual workload. Our goals for the audit were to catch any misuses of components/patterns, make any easy swaps, add notes for accessibility, have pods update their documentation structure, and flag areas that need further explorations. We completed the audit in October and I spent my last few weeks on the project working with our pods to make adjustments before launch.

I had also been tasked with exploring some DesignOps processes, including: keeping track of change requests, evaluating the strategy and presentation of documentation, and helping our feature pods create composition libraries in Figma.