Astra Design System
Following the end-of-life declaration forNetApp HCI, our UX team pivoted to working on a new product Astra Control. Thismeant that the product team scaled from having one UX Designer to sixovernight. During the transition, one of major items identified to increaseteam productivity was that the new product’s design system needed to bedrastically simplified and crucial documentation that was missing added.For this project I was tasked with determining how best to integrate the deployment of Rancher Server, a managed Kubernetes offering from Rancher, on NetApp's private cloud appliance (HCI) to provide our customers with a NetApp supported managed Kubernetes offering.
One of the team’s earliest stumbling blocks with the new design system involved how many different variants it contained and how closely each variant was coupled with exactly where in the application it was originally designed to be used. A perfect example of this phenomenon was the button component. In the original system there were an alarming number of different button components included one made for use in dialogs, in wizards, in tables, above tables, in pop-overs, in details pages,and many, many more. For the most part these different button components differed only in very subtle ways such as whether the button was 28px tall or 32px, or whether the corner radius was 6 or 12px, etc… To make the design system easier to use and the button component more reusable for future designs, I led several rounds of discussions with the original designer to simplify the button component down to a single component with 6 different button types and 2 sizes.

During the redesign phase, one of the most important goals was that the vue component and the Figma component needed to use the same language and have the same levers and knobs dictating style and sizing.This would ensure better communication between designers and developers and eliminate any mental-mapping required by the developer to translate designs into code.
