Design System & Accessibility

By 2018 the design team had outgrown its own guidelines, so we shipped a visual refresh, more than 100 components, and a library organized by purpose: what each element does, not what it looks like.

Those components grew out of Prism, the HTML5 console I helped design years earlier. That twelve-year arc is its own story, told in the Nutanix User Interface case study.

The patterns existed by 2018. The problem was getting 30+ designers and engineering teams across three countries to actually use them. So the work shifted from publishing guidelines to building adoption infrastructure.

The patterns existed by 2018. The problem was getting 30+ designers and engineering teams across three countries to actually use them. So the work shifted from publishing guidelines to building adoption infrastructure.

The problem

Three pressures had already forced DS 2.0: accessibility feedback on text readability, acquired products that couldn't migrate to Nutanix's patterns, and a visual language (pastel colors, rounded type) that looked dated next to modern enterprise UI. We'd solved the component and direction problems. What remained was enforcement. Without it, the library stayed optional.

Designers and engineers kept recreating one-off patterns. Accessibility varied by team. Complex edge cases, verbose VM names, long alert messages, dense datacenter tables, went unhandled because there was no shared baseline or way to measure progress. We needed a system teams would actually use. A PDF of guidelines wasn't going to cut it.

My role

I led the design system, then managed the team behind it. We'd already built the component architecture and the Prism visual language (covered in the Nutanix User Interface case study), so what came next was mine to own: adoption strategy, evaluating centralized tooling, running the workshop program, biweekly feedback loops with product designers, the accessibility initiative with Level Access, and the React component library.

I went from a single IC to managing six designers and four engineers.

Process & decision rationale

Rather than rebuild components from scratch, we built a data-driven adoption loop on top of DS 2.0.

Purpose before pattern. The taxonomy grouped every component by job: layout, display data, input data, or take action. Tables, charts, and badges look nothing alike, but they share a purpose, and that grouping forced designers to choose by intent instead of habit. We extended it into documentation, Figma libraries, and the React catalog, so the logic was searchable instead of living in someone's head.

Design for enterprise edge cases. Nutanix UI is data-dense by nature. Components had to survive unreasonable character counts, infinite-scroll tables, and sort, group, and action patterns without losing hierarchy. Nothing became a standard until it survived a real product scenario pulled from Prism, not a demo string.

Audit consumption first. We mapped which teams used the library, where patterns broke down, and which AOS releases correlated with adoption gains. Mandating compliance didn't work. Showing teams their own drift did.

Validate through collaboration. Biweekly check-ins with product designers surfaced needs we'd missed. Workshops and self-serve resources let teams migrate without blocking releases. A component only became a standard after it passed real design review, never committee approval.

Centralize and measure. We adopted shared design tooling with procurement and engineering so the library lived where design and engineering already worked, then tracked adoption per AOS release until we hit 100%.

On the engineering side, we paired the design library with an accessibility-ready React component library, turning interactions once prototyped in CodePen during DS 2.0 into WCAG-documented production patterns teams could ship without reimplementing behavior.

Outcomes & evidence

Adoption climbed from 43% to 100% across four major release cycles. The system lives at the Nutanix Design System site. The patterns it standardizes started on Prism. That twelve-year foundation is its own case study.

Adoption kept climbing after 6.0, from 66% at release 6.1 to 100% by 6.6.

Accessibility became a core standard. We partnered with Level Access for audits and built a11y guidance into every component's documentation, closing the readability gap that triggered DS 2.0 in the first place and taking the design team from no accessibility background to WCAG-compliant patterns in production.

Reflection

DS 2.0 proved we could craft components and a coherent visual direction for a hyperconverged product.

The harder problem was everything after: change management at scale. Driving adoption across designers and engineering teams meant translating the system into terms each function understood, testing components against real edge cases instead of ideal ones, and proving progress with numbers people actually trusted.

The Infrastructure UI case study covers the product context. This one covers what it took to make those patterns stick. Building the library was a project. Keeping it alive is an ongoing practice, with yearly interviews and UX scoring still part of the work.