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.
Design Systems Step 1: Recognize the Challenge of Designing at Scale
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.”
Design Systems Step 2: Understand What a Design System Is Not
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.
Design Systems Step 3: Understand What A Design System Is
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:
- Promote UI Consistency and cohesion allowing users to accomplished what they need to accomplish.
- Allow for faster production.
- Lead to higher quality production.
- Establish a shared vocabulary between disciplines and different products
- Make things easier to test and contribute to developing more resilient solutions.
- Create a useful reference for the teams to come back to.
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.
Design Systems Step 4: Establish Design Principles
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:
- Allow users to focus on their work without interference.
- Increase confidence through clarity.
- Foster productive and emotionally satisfying interpersonal dynamics.
- Design for fast, effortless, and intentional interactions.
- Empower everyone through progressive discoverability.
- Be consistent and standard, and innovate when it’s worth it.
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.
Design Systems Step 5: Perform a Screen Audit
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.”
Design Systems Step 6: Create a Design Language
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.
Design Systems Step 7: Build a Patterns Library
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:
- All design elements currently in use and any components or patterns that will be used in new products.
- A well organized structure. This task is challenging because a useful patterns library will be accessed by UX and UI designers, developers, product managers, and other stakeholders.
- Clear, legible graphics showing the main types for each component. For example, the library should list and show every button type such as primary, secondary, tertiary, and each button state such as default, hover, active, and inactive.
- Components in context. For example, don’t just show a text field. Show it in the larger context of a form or wizard commonly found in your products.
- A quick and easy way to find code, usage, and best practices to accommodate designers, developers, and stakeholders.