Nutanix Design System 2.0

When I joined Nutanix back in 2014, we were a small team of 4 designers including Jeremy, John and Paul. Keeping things consistent was relatively easy because we would always look at each other’s design and share the smallest details. However, over the last three years, thanks to the success of Nutanix’s business, we grew into a 30-people design team and are now handling countless products and features, including the ones that come from acquisition. It became a challenge how we can pass on the design language that we established over the years, not just by using the same buttons and input boxes, but ensuring products and features to share a similar experience across the board. So we believed it was time to build a shared knowledge base on the Nutanix UI design language that touches every aspect from small components to layouts, from visual to UX. We call it, the Design System 2.0.

Why call it Design System “2.0”

Design System as a concept isn’t new at all these days. You must have heard or even used Google’s Material Design or other similar approaches from big companies such as Facebook, Atlasssian, etc. You see the pattern here: Design System is simply made for bigger teams so people can work together more efficiently and the result would be more consistent. But why call it 2.0? Well technically we did have a “1.0” version shortly after I joined, which was built as a collection of Photoshop cloud libraries that include the UI colors, styles and most frequently used components. The biggest problem of the 1.0 version was that it demonstrates the design language by only sharing the components. The additional layers on top of the components, such as when to use what component, what’s the interactive behavior, and what’s the philosophy behind using colors in the UI are all hidden in our heads. When we passed on these libraries, it’s impossible to guarantee consistency because of the lack of instruction details.

Therefore the first goal of the Design System 2.0 to improve the communication with designers by not only showing the “what” but also the “how” and “why” of the components. We decided to build our own Design System website so that we can write rules on how to use each component as well as explain the thought process. To make it easier to maintain, the website is coded in a way that uses a standalone markdown file to render the entire component library, with the ability to detect custom tags such as “Do”, “Don’t” or “Reference” to add instruction right next to the components. In this way, anyone in the team can easily contribute to the instruction text without touching any code.

A More Meaningful Structure

The second goal of the Design System 2.0 is to categorize the components in a more meaningful way. When we started the 1.0 version, we didn’t really have a holistic view of what we are trying to build. It was mostly one component after another based on context: popup related components are put in one folder and chart related ones are in another. This approach was fast if you want to put together a typical design in a certain context such as a simple configuration popup that uses only input boxes and a button. However, when a designer isn’t happy about a particular component, he needs to go through all the other folders to see what else is available. For instance, if someone wants to use tabs in a widget, he might not be satisfied by the general tab bar component, and what he had to do is to search through the entire library and only if he was lucky, he would find the mini tab bar component that was designed for popups, which is technically designed for the popup context but could be reused in other places with narrower space. There has to be a better way to navigate through the library.

As we went over every component we have defined, it’s interesting to realize that no matter what component we are looking at, big or small, in a popup or the header, it’s either for the user to input data, to read data, or to take actions. The context is actually flexible. This inspired us to categorize all of the components into these 3 respective types. For example, “tab bars” will be put in navigational layout section no matter where it is used, and will be referenced in the popup section. The hope is that this approach will allow designers to think more abstractly when they start a new project, by asking “what data do I need from the user?”, “what data the user might need from the UI in order to make a decision”, “how does he apply his decision?” and pick the components accordingly.

After categorizing by the purpose of the components, we also added the layer that defines the scale of the components. For the basic elements such as typography, colors and standard spacing metrics, we call them “foundation components”. In the second tier, we added the common standalone components, including the buttons, tables and various types of inputs, which are the core of the component library. Above that, we found it useful to have the examples of how these components can be used jointly with other components, such as a nested checkbox section, which we call “patterns”. And lastly, we created a tier called “layouts” for grouping, dividing or navigating components. Last but not least, the commonly used full-page design are also included as “templates”.

To sum up, the design system is restructured in this formula: foundation > components > patterns > layouts > templates, while the “components” tier are divided into “data display”, “data input” and “actions”.

Other Goals

In addition to the two main goals above, there are a list of other goals we are trying to achieve:

  1. Clarifying visual guideline. As the team grows bigger, we decided to articulate the thought process of choice of the visual style, especially when it comes to helping the acquired companies to understand the Nutanix visual design language and convert their products to out style.
  2. Resolving historical UX issues, such as text sizes and contrast for better accessibility. They sound like small changes but actually very expensive to make from the engineering perspective, as the Nutanix has big platform today. But since Design System 2.0 will require global rebuild of many components, it is the perfect opportunity to make sure accessibility is done right within the new components.
  3. Offering a new toolkit for designers to improve productivity and collaboration. Our goal is that every designer is able to contribute to the system and the system will evolve constantly by absorbing new design and use cases. As a starting point, we created a google spreadsheet that can be accessed by anyone internally to request new components or give suggestions on existing components in order to use them in their projects. In the future, we want this feature to be integrated to the Design System website directly, so people can mark their feedback right next to the components. Other then that, the new system provides a wide range of tools and assets that can be found on the “Resources” page on the website.
  4. Creating a new front-end framework that matches both the visual design and interactivity with highly precise and polished details. We are adding regular review sessions with developer to make sure components will be reviewed by the design team before they are pushed to the master branch.

What’s Next

Nutanix Design System 2.0 has been launched internally since late 2017 and got a lot of positive feedback from both designers and engineers. It’s more structured, more polished and mostly importantly, more collaborative. Currently we are working hard to add more components to the system for features with unique interaction models that haven’t been covered. It will be a continuous journey to build the unique design system for the enterprise use cases that Nutanix products are handling. It was joint effort of the design team but I particularly want to thank Pascal Gärtner for creating the beautifully structured Sketch file and Sketch libraries that our designers love and rely on every day.

To visit the design system website, please go to: