Design systems, patterns, principles, guidelines, UI Kits, and components, oh my! Important? Yes. Confusing? Also yes. Previously, we wrote about design patterns, one aspect of design systems. In this post we broaden the focus by outlining 7 key aspects of design systems.
In Building a Visual Language author and Airbnb designer Karri Saarinen deftly connects design and systems:
Design has always been largely about systems, and how to create products in a scalable and repeatable way. From Pantone colors to Philips screws, these systems enable us to manage the chaos and create better products. Digital products are perhaps the most fertile ground for implementing these systems and yet it’s not often considered a priority.
Saarinen cites the lack of physical constraints, the variety of platforms, and the multitude of stakeholders as significant barriers to establishing design systems. Saarinen is right. From ecommerce, to enterprise software, to highly targeted mobile apps, the challenges are similar. Too many people moving too fast to rush products to market with little regard for a unified design based on sound principles and a robust design language.
In The heartache of design at scale (part 1 of a six-part InVision series featuring Josh Clark, Dan Mall, and Brad Frost) industry leader Clark explains: “We have great people solving the same problem over and over and over again.”
In the same segment, design systems expert Dan Mall cites the common misconception that a UI kit is a design system. Because a UI kit is often locked into a single tool like Sketch, by definition it is not a design system.
A UI kit is part of a design system and can contribute to building one: “But really we should be liberating all of our design tools from outside of a particular environment where it’s locked down and instead working on something that everyone can kind of touch.”
Atomic design guru Brad Frost extends the explanation. Having a bunch of UI components without context is like dumping a bunch of Ikea parts on a table and saying: “Okay, time to build this dresser.”
The point is to devise design systems accessible by all teams that can address every aspect of the design process.
In The heartache of design at scale Frost builds on Clark’s and Mall’s arguments as he outlines the benefits of design systems. These systems:
Provide a future-friendly foundation to grow and evolve to the system over time.
Design systems can include design principles, design tokens, UX guidelines, development guidelines, UI patterns as well as brand guidelines, voice and tone guidelines, writing guidelines, and processes.
Establishing and adhering to design principles contributes to better designs. According to Saarinen, Airbnb’s design principles include:
Asana takes a different approach with more specific and actionable design principles:
The specific principles cited here are merely examples, albeit good ones. What matters is crafting design principles that are broad enough to reflect the organization’s ideals and long-term business objectives but specific enough to inform design.
A screen audit is an effective method for identifying page types, UI patterns, the current nomenclature, and flows that do and do not work well. With key screens from all systems literally front and center, the design team can assess the scope of what will eventually become part of the new design system.
A design team at one company might discover hundreds upon hundreds of components and page types. A screen audit at a different company might yield well-defined page types and a shorter list of components. You simply cannot know without completing the audit.
As Frost explains, the purpose of the screen audit is to “hunt for these distinct patterns and the idea is to sorta collect them all under one roof.”
Teams then meet to present their findings. One person might show the various social media buttons presented inconsistently across different product lines. These presentations are important, says Frost, “because it’s here where that sorta shared pain and shared language starts coming out. It’s in this presentation that teams are able to sort of call things names, right?” For example, here’s an admin bar. Someone else might say that they call it the gray bar while the developers might say that they call it the utility bar: “It’s through this presentation that the shared vocabulary starts forming.”
Shared terms emerge, as do inconsistencies such as the previous example listing three different terms for the same design element. The screen audit provides the basis for developing a more robust design language.
A design language need not be static, but it should establish the agreed-upon terms for each component and design element. A design language should also remain flexible as business and design needs change.
A useful design language should plug into a governance process wherein design terms are reviewed and updated by a cross-functional team.
Initially, the patterns library can be as simple as a large document illustrating each UI pattern discovered during the audit. This document can be shared with the CEO: “And this is where the magic happens because you don’t have to be a designer to understand that having 70 different button styles is a bad idea, right?” says Frost.
Over time, this large document should take the form of a robust library with: