Design System & Accessibility

The design team had outgrown its guidelines. In 2018 we released a visual refresh, 100+ components, and a purpose-based library organized by what each element does, not what it looks like.

Those components grew out of Prism, the HTML5 console I helped design years prior. Read that twelve-year arc in the Nutanix User Interface case study.

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

The problem

Three product pressures had already forced DS 2.0: accessibility feedback on text readability, acquired products that could not migrate to Nutanix patterns, and a visual language (pastel colors, rounded type) that felt dated against modern enterprise UI. We solved the component and direction problems. What remained was enforcement. Without it, the library was optional.

Designers and engineers recreated one-off patterns. Accessibility varied by team. Complex edge cases (verbose VM names, long alert messages, dense datacenter tables) were not consistently handled because there was no shared baseline or way to measure progress. We needed a system teams would actually use, not another PDF.

My role

Design system lead & later manager of a team. We built component architecture and the Prism visual language documented in the Nutanix User Interface case study, then owned what came next: adoption strategy, centralized tooling evaluation, workshop program, bi-weekly feedback loops with product designers, accessibility initiative with Level Access, and the React component library.

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

Process & decision rationale

Rather than rebuilding 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 different but share a purpose; that organization forced designers to choose by intent, not habit. My team extended it into documentation, Figma libraries, and the React catalog so the paradigm was searchable, not tribal knowledge.

Design for enterprise edge cases. Nutanix UI is data-dense by nature. Components had to handle unreasonable character counts, infinite scroll tables, and sort/group/action patterns without breaking hierarchy. Standards were not approved until they survived real product scenarios from Prism, not demo strings.

Audit consumption first. Mapped which teams used the library, where patterns broke down, and which AOS releases correlated with adoption gains. Mandating compliance failed; showing teams their own drift worked.

Validate through collaboration. Bi-weekly check-ins with product designers surfaced uncovered needs; workshops and self-serve resources let teams migrate without blocking releases. Components only became standards after they passed real design review, not committee approval.

Centralize and measure. Adopted shared design tooling with procurement and engineering teams so the library lived where design/eng were already working, then tracked library 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 Codepen-prototyped interactions from 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 live system lives at Nutanix Design System. The product patterns it standardizes started on Prism; see the Nutanix User Interface case study for that twelve-year foundation.

Accessibility became a core standard: we partnered with Level Access for audits and built a11y guidance into every component's documentation, addressing the readability feedback that triggered DS 2.0 and taking the design team from no prior a11y background to WCAG-compliant patterns in production.

Reflection

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

The harder problem was everything after: change management at scale. Driving adoption across designers and engineering teems required translating the system into terms each function understood, validating components against real edge cases instead of ideal states, and proving progress with numbers teams could trust.

The Infrastructure interface case study work in the supplied the product context; this case study is what it took to make those patterns stick. Building the library was a project.

Keeping it it’s an ongoing practice. Yearly interviews and UX/UI scoring still takes work.