OPEN SOURCE DESIGN SYSTEM
note: The information below refers primarily to Clarity NG. Our recent efforts have been focused on Glarity Core built to be framework agnostic using web components. This work is detailed in 2 Medium articles available here:
Working with the Clarity team is an amazing job for a designer. I lead a team of designers and work hand in hand with a dozen developers. I often design directly with development, because I prefer working less in Figma and more in CSS. We build, iterate, and finesse things together.
I joined the team with the effort very well under way while still in the beta stages. I have built many components, systems, and handled bugs and enhancements in addition to external contributions. This includes a intensive accessibility effort this year. 3.0 is coming soon and we have many things in store for the coming months.
After our 1.0 release in 2018, I began the process of refinement. We made many choices in the midst of creating the system we could now reassess. Had we a complete theming solution in place, the job would have been easier, but Clarity was built by a small team along with external contributors, making an audit essential. This analysis made our visual refresh properly targeted with respect to our resources and timeline.
At top of my list was our open source typeface, Metropolis. While providing us with exceptional value given its similarity to the typeface VMware uses in brand and marketing, it suffers from shortcomings due to its provenance from an independent type designer, rather than a foundry. These included uneven kerning pairs, migrating centerline, optical massing and join problems, as well as many missing glyphs. Designers were unhappy using this typeface and I empathized with their frustrations. I made it a priority to elevate the face to higher standards. The typeface known as Clarity City was born. Clarity City will still be open source once we remedy the irregularities.
With Metropolis in place for the foreseeable future, I addressed the hierarchy concerns in the existing type scale. The sensibility for Clarity type classes was very light in weight and density. This resulted in applications with flat hierarchy. I reviewed usage with product teams and in our components. The most extreme examples of confounded hierarchy exhibited as many as 15 separate sizes and weights in a single screen. I created a system with a limited number of choices along with usage guidelines.
After several rounds of options, working sessions, and review it became clear that we had 2 concerns. These were open layouts such as landing pages etc. and tightly packed information pages that require information density. I added weight and size to the display classes, and distilled the complexity in the middle and small sizes. I shifted to color from neutral to cool grey and created a template system to assist in achieving hierarchy. The increased dynamic quality of the resulting screens was well received, more usable, and more attractive.
The initial designs for Clarity were lacking in chroma and contrast. We needed blacker blacks and whiter whites, more saturated color. Before going down this path I interviewed designers across product teams to validate my observations. The feeling that increased chroma and contrast was what we needed was validated.
I changed our color model to HSL and created a UI palette using the brand palette as a foundation. By finding all the complimentary hues then using the saturation and lightness channels to calculate tints, tones, and shades, I was able to achieve a harmonious collection that both reflects the brand and is suitable for UI. This includes a set of utility colors for vision impaired users.
Accessibility aka A11y is an key aspect of everything we build. This became increasingly important with the upcoming EU requirements relative to WCAG 2.1 - we needed to make substantial changes to Clarity, and to all the products using Clarity. There are multiple versions of Clarity in the wild, and many products use their own (non-Clarity) components and overrides. The task was to make Clarity compliant, as well as all VMware products dependent on Clarity.
We hired an accessibility team and soon had many a11y bugs to address. This is a fulfilling place to devote ones energy. Everyone should be able to avail themselves of the power of computing regardless of special needs. A11y goes far beyond simply checking and ensuring compliance for contrast ratios, but also covers ensuring screen reader, keyboard, and other interface paradigms work correctly. Accessibility is such an important aspect of UI design and development.
Many initial components were built hastily and may adhere to arbitrary inconsistent and margins. This is exacerbated by the previously mentioned line-height conventions. These made layout a consequence rather than a result of intent, and designers were often upset with how their work was implemented by development. Without some utilities to address this the only (unrealistic) alternative was to edit the properties of components piecemeal in order to finesse layout. I introduced a design token based layout component as a way for designers to better embrace gestalt principles to control hierarchy. This system makes it easy for developers to follow the layout specified in the designs.
At first my suggestion for inclusion of theming met with resistance. The thinking was that we didn’t want designers or engineers customizing our UI components that are designed to create unity. In principle I agree and have experienced the liability a lack of restraint can be. In a perfect world, themes are owned by people with the skills, experience, and time required to make solid ones. Eventually the concept of theming gained traction and became a system of custom properties that allows us to leverage ideas such as the design tokens I mention above.
We had a few issues with overt containers. Several of the legacy applications were built by developers, and the go-to solution for solving grouping was to put elements in containers (cards). This became a stylistic attribute of our applications and Clarity itself. The cognitive load of so many keylines defining bounding boxes was too much. As part of a cleaner look I removed all unnecessary line work which resulted in a more fresh and light feel.
Below is a before and after of 3 components with unnecessary container attributes removed.
Since Clarity supports nearly 100 products and the questions coming though on Slack and email can be overwhelming I instituted the practice of holding office hours. This is a forum where teams can come ask questions, request guidance in using a component or solving a use case, or simply listen to the team and I discussing the current initiatives. Clarity Office Hours have been well received and well attended with the added benefit of giving me insight into the design challenges faced bt product teams. A design system is a 2-way street and I am grateful for all I have learned about our products from the designers who are improving them on a daily basis.
The Clarity team is a group of creative developers and designers. I am happy to have the opportunity to work with them. It is remarkable how we continue expanding the difficulty of the challenges we tackle, while keeping up a rapid cycle of enhance, iterate and release. I have been able to lend my design skills to the effort while learning much about front end development and accessibility. I'd encourage anyone unfamiliar with our work, especially those interested in design systems, to visit clarity.design - the project is open source and available to anyone who wants to study our system or use our components.
"Clarity is VMware's open source UI library which includes Figma and Sketch components in light and dark themes, UX guidelines, HTML/CSS framework, and Angular components, all working together to craft exceptional experiences."
Get in touch:
Get in touch: