Celestial Design System

Back to work

From 15% to 95% Accessibility Compliance

Owning the end-to-end design of Comcast's next-generation employee-facing design system — building components, establishing process, and driving accessibility across web, iOS, and iPadOS.

Hero Image

Client Comcast (Frontline UX)

Duration March 2024 – October 2024

My Role Principal Experience Designer

Team 1 design lead, 3 designers, accessibility team, Prism engineers

Platforms Web, iOS hybrid (Capacitor), iPadOS hybrid (Capacitor)

Key Deliverables Component design & documentation, accessibility remediation, process standardization

The problem

Celestial was only 20% complete when I joined — and the 80% that existed had an accessibility compliance rate of roughly 15%.

Comcast was building Celestial to replace its legacy 360 products and unify every employee-facing tool — Xfinity App, Flex, TV, Web/Mobile Native, and all Celestial Spaces — into a single, cohesive design system. The vision was ambitious, but the system was behind. A massive backlog of components and patterns needed to be designed and documented. There was no structured process for creating, reviewing, or handing off components. And the teams consuming the system — multiple product Pods across the Celestial ecosystem — needed components that actually worked at scale across four breakpoints and three platforms.

The design system had a foundation, but it needed someone to own it end-to-end and turn it into something teams could actually rely on.

Problem visualization

15% legacy accessibility compliance when I joined

95% compliance across all new and updated components

4 breakpoints designed per component

3 platforms supported (Web, iOS, iPadOS)

My role

Think Company was brought in to staff the Celestial Design System (CDS) team, and I owned the system end-to-end. That meant creating new components, refining existing ones, producing comprehensive documentation, driving accessibility from 15% to 95%, and collaborating across design, accessibility, and engineering teams to ensure everything scaled.

Every component I touched needed to work across four breakpoints — desktop, tablet horizontal, tablet vertical, and native mobile — spanning both web and native app experiences. The work wasn't just about designing components; it was about building the processes and standards that would let the system grow sustainably long after my engagement ended.

Component Ownership

Designed and documented components end-to-end across all four breakpoints and three platforms. Each component included anatomy, behavior specs, usage guidelines, accessibility requirements, and sticker sheets.

Accessibility Champion

Collaborated directly with the accessibility team from the earliest stages of every component. Drove compliance from 15% on legacy components to 95% across all new and updated work.

Process Standardization

Established a structured, repeatable workflow for component creation, review, and handoff that was adopted by the full CDS team — replacing ad hoc practices with clear, documented steps.

Cross-Functional Collaboration

Worked closely with the CDS team, Prism (engineering counterpart), the accessibility team, and multiple product Pods consuming the system — ensuring every component met real-world needs.

The approach

Phase 1 — Exploration & Ideation

Understand the ecosystem

Conducted research with designers across Celestial product teams to understand their pain points and component needs. Performed competitive analysis against industry-standard design systems. Collaborated with accessibility and engineering teams early to establish compliance requirements and technical feasibility before any design work began.

Phase 2 — Design & Iteration

Build iteratively with cross-functional input

Created components through rapid iteration, incorporating feedback from the CDS team, Prism engineers, and the accessibility team at every stage. Conducted cross-functional validation to ensure components met the needs of all consuming product teams — not just the design system in isolation.

Phase 3 — Delivery & Implementation

Document, hand off, and ensure adoption

Produced comprehensive documentation for every component: anatomy breakdowns, behavior specs, usage guidelines, accessibility requirements, and sticker sheets. Conducted post-sprint reviews with consuming Pods to ensure adoption readiness. Handed off completed components to Prism for integration into the shared UI kit.

Designing for every surface

Every component needed to work across four breakpoints and three platforms — and still feel like one cohesive system.

Celestial supports web, iOS hybrid (Capacitor), and iPadOS hybrid (Capacitor). That meant every component I designed had to account for desktop, tablet horizontal, tablet vertical, and native mobile contexts — each with its own interaction patterns, touch targets, and layout constraints.

This wasn't about simply making things responsive. Each breakpoint required intentional design decisions: how does a data table behave on a tablet held vertically versus horizontally? How do navigation patterns shift between web and native? The goal was consistency without rigidity — the system should feel unified, but each platform should feel native to its context.

Multi-platform component showcase

Making accessibility non-negotiable

When I started, legacy components had roughly 15% accessibility compliance. That wasn't just a metric — it meant real employees using these tools every day were struggling with interfaces that didn't work for them.

I made accessibility a first-class design constraint, not an afterthought. Every component was designed in collaboration with the accessibility team from day one — not reviewed by them after the fact. We established clear requirements for keyboard navigation, screen reader support, color contrast, focus management, and touch targets before any visual design work began.

By the time I left, new and updated components had reached 95% compliance. More importantly, the process itself had changed. Accessibility wasn't something to be fixed later — it was built into how the team worked.

"Accessibility isn't a feature — it's a design constraint that makes everything better."

Before

~15% accessibility compliance on legacy components
Accessibility reviewed after design, not during
No structured requirements per component
Inconsistent keyboard and screen reader support
Compliance treated as optional cleanup

After

95% compliance across all new and updated components
Accessibility team involved from exploration phase
Every component documented with accessibility specs
Keyboard navigation and focus management standardized
Compliance built into the repeatable workflow

Building the process, not just the components

A design system is only as good as the process behind it. When I joined, there was no structured workflow for how components got created, reviewed, or handed off.

I established a repeatable process that the full CDS team adopted: exploration and competitive research first, iterative design with cross-functional feedback, comprehensive documentation as a non-negotiable deliverable, and structured handoffs to Prism with clear specifications. Every component I delivered included anatomy breakdowns, behavior specifications, usage guidelines, accessibility requirements, and sticker sheets for designer consumption.

I also introduced post-sprint reviews with consuming Pods — the product teams actually using these components. This closed the feedback loop between the design system team and the people relying on it, ensuring we weren't building in isolation.

Exploration & research

Every component started with competitive analysis, cross-team interviews, and accessibility/engineering feasibility reviews — before any pixels were pushed.

Iterative design

Rapid iteration cycles with feedback from CDS, Prism engineers, and accessibility at every stage. Cross-functional validation ensured real-world viability.

Documentation standard

Anatomy breakdowns, behavior specs, usage guidelines, accessibility requirements, and sticker sheets — delivered for every single component.

Structured handoffs

Clear specifications handed to Prism for integration into the shared UI kit. No ambiguity, no guesswork, no rework.

Pod feedback loops

Post-sprint reviews with consuming product teams closed the gap between what the design system offered and what teams actually needed.

Sustainable scale

The process was designed to outlast my engagement — giving the team a repeatable, documented workflow they could follow independently.

Outcomes

Accessibility impact

Raised compliance from 15% to 95% across all new and updated components
Embedded accessibility into the component creation process from day one
Established documentation standards that include keyboard, screen reader, and focus management specs

System impact

Designed and documented components across 4 breakpoints and 3 platforms
Standardized the component creation workflow, adopted by the full CDS team
Delivered components to Prism for integration into the shared UI kit

Process impact

Established a repeatable workflow: research, design, document, review, hand off
Introduced post-sprint reviews with consuming Pods to close the feedback loop
Streamlined design-to-development handoff, reducing ambiguity and rework

Team impact

Strengthened collaboration across design, accessibility, and engineering teams
Facilitated seamless adoption of new components by product Pods across the ecosystem
Left the team with processes and standards that scaled beyond my engagement

What I learned

Celestial reinforced something I believe deeply: the best design system work is invisible. When it's working, teams don't think about the system — they just build with it. Getting there requires rigorous documentation, relentless accessibility standards, and a willingness to design the process as carefully as the components.

The accessibility work was especially meaningful. Moving from 15% to 95% compliance wasn't just a number — it meant real people could actually use the tools they relied on every day. And the approach mattered as much as the outcome: by making accessibility a first-step design constraint rather than a last-step audit, we changed how the team thought about inclusive design permanently.

This project also set the stage for everything that came after. My deep knowledge of Celestial's architecture, components, and patterns became a major asset on the Point of Sale project — where I was specifically brought in because of that fluency. The systems thinking I sharpened here carried directly into the work I'd go on to lead at Meevo.

Continue reading

Previous case study

Stepping Into the Leadership Gap

Design Leadership, Enterprise UX, Sprint-Based Delivery

Next case study

Migrating 300+ Brands to Figma

Figma Migration, Design Training, White-Label Systems

I'm going to say the quiet part out loud: AI built this website. And I'm proud of that.

Most people hide behind the fact that they use AI to create things. I want to flaunt it — because I think the way you use AI says more about you than whether you use it at all.

I've spent 16 years trying to deploy the portfolio website I always envisioned. I tried everything a non-coder could try — Webflow, Wix, Squarespace, literally just shipping a Figma prototype as my portfolio for the last few years. My most recent attempt had me deep in Framer, convinced I'd finally cracked it. Another unfinished project. The truth is, when you're working full time leading design teams, there's never enough time or energy left to also build and maintain your own site. The vision was always there. The bandwidth never was.

AI changed that equation entirely.

I designed every screen, every interaction, and every detail of this site in Figma — the same way I design everything. Then I used Claude Code to bring it to life, guiding it step by step through layout, styling, animation, and content. Every decision was mine. Every pixel was intentional. The AI was the tool that finally closed the gap between what I could envision and what I could ship.

But the site itself is just one output. The real unlock came from the way I've been working on projects like Meevo — building an AI-assisted design operations framework around markdown files, GitHub repositories, and context systems that keep multiple AI agents working with the most comprehensive understanding of the project possible. Over 18 months of leading that engagement, I accumulated a massive amount of project data: strategy documents, design rationale, stakeholder feedback, research findings, system documentation, the works.

So when it came time to write the case studies on this site, I didn't start from scratch. I pointed AI at all of that structured context and used it to help me aggregate, synthesize, and draft the narratives you're reading here. Because why wouldn't I? The craft is in the curation, the framing, and the judgment. The AI handles the grunt work that used to make case studies the thing designers never finish.

The result is the thing you're looking at right now — a portfolio that actually represents who I am, built the way I believe design should work. Not despite AI, but because of it.