Vision for a Design System

Once upon a time there was a design team. Spread across India, Bulgaria, and the United States, this team took on a variety of projects, and delivered each one of them. Everything was going swimmingly until one day it all came down to two buttons.

“Do we like this one or that one?”

And that’s how Vision was born.

Origin Story

According to Nielsen Norman, a design system is “a complete set of standards intended to manage design at scale using reusable components and patterns.”

Design systems are set up to perform a variety of functions.

• Allow UI components to be reused, reduce design and development effort
• Free up time for the team to focus on large, complex issues
• Establish a unified visual language across products, platforms, teams
• Enable consistency in look, feel, and behavior across applications
• Set up design standards, ease onboarding for new team members

At VMware, the End User Computing (EUC) Design team spent a long time debating the merits of one button v/s another. There was little difference between the two, and yet it was clear that the designs were distinctly different. The team wondered: How many other versions of the button component even existed?

A lot of time had been spent designing multiple versions of the same components, and much of it could have been avoided by using a design system with a defined set of components. Not to mention the varying look and feel of the components themselves that conveyed a lack of consistency across products and platforms. EUC Design was working on multiple products but they all belonged to a single product suite. Meaning, they were meant to convey a common look and feel.

As design continues to scale up, the need for a design system gains in importance. This brings us to Vision.

Framework

The Vision framework comprises of mobile UI components (e.g. cell, button, label) and UX resources (e.g. image assets, colors and fonts, animation). The color palette was the first item added to the framework. It was made up of base colors and semantic colors. Base colors included an extensive set of colors grouped by family, while semantic colors provided guidelines for light/dark mode pairings for UI components, as well as actions, icons, dividers, and text. Similar guidelines were defined for alerts, including light/dark mode backgrounds for iOS and Android. Design specifications were provided for actions (positive, negative, neutral) as well as status messages. Color contrast ratio and font sizes were defined separately, thus integrating accessibility into the framework.

Soon after, the Vision Sample app was released internally. This app allows anyone at VMware to preview the Vision UI components before adding them to an app.

Process

It takes a team to support a design system such as Vision. Designers and developers have to work in tandem to keep the system current and updated.

Take a UI component, for instance. There is a multi-step process to follow in order to add a single UI component to the Vision framework. A designer writes the design spec for a component, and the developer writes code as per the spec. In addition, Vision UI components have to meet specific accessibility criteria, such as Right-to-Left language support, VoiceOver accessibility, large text accessibility, etc. Multiple rounds of design and code reviews are conducted with various stakeholder groups before the component can be added to the Vision framework and the Vision Sample app. Once done, the component can be consumed by any app within the VMware Productivity Suite.

Now, there may be scenarios where a certain UI component is deemed app-specific, and there is not a need for it to be added to the Vision framework. Take an email icon, or a calendar component. There may not be a case for reusing them in other apps. However, if a particular component has “reuse value,” it goes through a stringent approval process before it is added to the Vision framework.

The process of adding a component to Vision may sound simple and uncomplicated but it can get challenging, especially when release timelines are tight. Often, a component needs to be ready sooner so it can be included in an upcoming app release. There isn’t sufficient time for it to be reviewed fully, as per the Vision framework process. Components developed in such a manner often end up being highly app-specific, and they may need to be developed further (or standardized) before they can be added to Vision.

Vision is maintained by designers and developers who have to be mindful of release timelines. Ironically, a system like Vision may be the best solution to the problem described above. As more components and resources are added to Vision, designers will be able to find everything they need within the system, and they can save themselves design time and effort. This is a catch-22 situation because it takes a lot of time and effort also to keep Vision current and updated.

Vision as a Product

If the Vision framework were to be regarded as a product in its own right, it would be only natural to have a dedicated team to support its functions.

• Maintain acceptance criteria
• Manage reviews for new and updated components
• Share release notes
• Conduct onboarding sessions for new team members
• Set up brownbag events for other teams
• System maintenance and upkeep

The above would be some of the tasks of the Vision team. Moreover, the success of a design system hinges heavily on its adoption, and to that end, this team would be responsible for socializing Vision with as many groups as possible, so it truly becomes a design system for all design teams within the company. This is not a “pie-in-the-sky” goal — it is absolutely doable. Over the last two years, Vision has developed into a stable yet flexible design system, thanks to the efforts of various designers and developers. Having a team dedicated solely to Vision would make it a richer and more robust system.

Work in Progress

A design system is always in a state of “work in progress” as it is constantly being updated and added to. This isn’t a bad thing at all. Everyone has a real opportunity to contribute to a design system like Vision that is built for flexibility and adaptability because it aims to meet the goals of multiple design and development groups. There is a certain democracy to this arrangement, and yes, as messy as it might get, there is real value in nurturing a system of this kind where everyone is an equal stakeholder, investor, and contributor.

Inputs: Andrew Munoz, Rob Eagle, Eric Munoz, Vinayak Srivastava, Karthik, Damyan Gaitanov, Nikola Kirev, Daniel Tsonkov

Illustrations: Yova Bogdanova