The design system you don’t need
Design systems, so hot last summer.
It’s been a while since the “I must have a design system” hype peaked. Back then, most designers felt the need to try this novel artifact, available in the Sketch or Figma closest to you.
It's almost 2021 now, and we’ve learned a lot. We now know that, if poorly purposed, Design System structures can become needy, demand governance and distract us from real product and user problems, only to end up succumbing under its own complexity.
Teams with infinite resources — time, money and patience — to pull the right strings are the ones reaping its benefits. When this is achieved, designers, developers, and the rest of the company will all live in blissful harmony forever. Yet for some of us, experienced or not, deciding how to document and produce a reliable source of truth is still a challenge.
In this article, we’ll dive into design systems, examine their benefits and make sense of smaller but powerful structures like Styleguides and Pattern Libraries.
We’re going to address questions like:
- What is a Design System and how does it become too complex?
- How do we tame design documentation with smaller structures?
- Is a Pattern Library or a Styleguide good enough for small projects?
First of all, let’s make sense of Design Systems.
Design Systems
Alla Komaltova defines Design Systems as “a set of interconnected patterns and shared practices coherently organized to achieve the purpose of digital products”. It makes sense when you think of it as a framework to understand the elements responsible for keeping you, teams and stakeholders on the same page.
It starts with the realization that a product is not only your software or the Sketch file it lives in, it’s the company and practices around it. Marketing guidelines, design choices, the physical and social environment, shared language, branding requirements, voice and tone, to name a few. Up to this point, it seems like a reasonably good idea to wrap all that in a neat little bow. In theory, we can spark product awareness, provide a shared language between teams, improve business by having a ready-to-scale product, not to mention a consistent development cycle, from UI development to front-end, sometimes even back-end.
It wasn’t an easy ride though. With the hype came the illusion of a system capable of solving most of the problems that industry and designers face. But being a living organism just like the software we create, design systems shouldn’t rely on definitive structures, it must be able to change directions and adapt under the circumstances, which is where the issues begin to show clearer shapes.
The organic nature of developing products can make Design Systems increasingly needy, and without a clear strategy, you can either lose track with endless updates or be stuck with obsolete structures. Companies that succeed in this task had to dedicate entire teams in order to keep up with constant updates and with the vetting of new entities making it into their Systems.
To make all of it come together seamlessly, we need to establish processes for everything your design system touches. Clear communication across teams, dedicated personnel for dealing with updates and documentation maintenance are essential to extend your Design System’s shelf life.
Complexity
The image below highlights some of the complexities involved in adequately maintaining a Design System over time. The animation shows a multi-pronged coordinated effort to manage communication, governance and guidelines that, when achieved, lets your DS have a shot at usefulness.
As the endless flow of documenting, removing and maintaining incoming and outgoing aspects of your process and product, the beige spinning circle represents the necessary governance & communications effort to constantly touch base with specific gatekeeping processes. Also notable is the inverse relationship between effort and value that follows: smaller projects make this complexity more manageable, but reap less benefits from overgrown processes and structures due to upkeep costs, whereas very large projects usually have the resources to take fair shots at proper maintenance but face an exponential complexity increase as the number of entities, processes and connections shoots up.
Governance
Someone needs to be responsible for setting up the environment for the new content that enters the system. You can either create a structure where a manager sets the pace and decides what gets in or out, or you can create an open environment, where everyone gets to collaborate when necessary. In this last scenario, everyone gets to analyze components and give feedback. This may be a good way to get people involved and have everyone sharing the same language and understanding.
Communication
It’s not an easy task to get people to access and keep up with an ever-changing system. Don’t expect to be the only designer ahead of the system, relevant information scatters very easily whenever a new person joins or leaves. A simple color addition or change on a main component needs to be properly documented with its purpose and in sight, so everyone will be on the same page.
Guidelines
Components are meant to be created purposefully. A simple library displaying it might not do well to serve the UX behind. Clear guidelines explaining motivations, giving context and showing examples are helpful to avoid misuse and the creation of new and unnecessary elements.
Every product demands different foundations and solutions. Atlassian’s design team felt that they needed a tailored showcase of its design system. The solution improves communication and stand up for its visual language using cards. Their design system includes marketing, product, brand and even illustration guidelines.
Here’s a list of great design system you may be inspired by:
- https://www.carbondesignsystem.com/
- https://polaris.shopify.com/
- https://primer.style/
- https://material.io/
- https://www.microsoft.com/design/fluent/#/
When should we wrap up everything in a design system?
Bigger products demand a ready to scale and move fast environment. They are always shifting over a myriad of UI elements, UX decisions, brand updates and code rewrites. Now imagine a smaller design team being responsible for creating, maintaining and updating such structures.
“Maybe I don’t need a Design System after all”
Lucky you! We still have Pattern libraries and Styleguides. They still serve a great purpose if the intention lies towards the visual and development side of the product. As a designer, overwhelmed with the growing list of novel design artifacts, I still get confused by the overlapping attributes each one has. So, I’ll put their nuances in a more fashionable way.
Functional and perceptual patterns
Let’s assume you have have a nice wardrobe and, within it, you have combinations of clothing that covers most of your social needs: a party, work, meeting, gym. This wardrobe is your collection of functional elements, full of raw pieces that provide a range of clothing possibilities to the everyday you. We can define this as the functional side of the wardrobe. They are the raw blocks provided by browsers, <button>, <a>, <input>… or, in this analogy, lifeless pieces of clothing.
Going further with this analogy, let’s say you have some preferences regarding colors, brands and everything that gives a personal touch to the pieces, hence style. These called functional blocks serve a purpose, but lack personal preferences. Now they gain colors, borders, proportions, background.
After this fashion inspection, the wardrobe looks more like it was made for you, not only it has the pieces you like, but a personal touch, attributes that improve perception. At this point, we can relate this wardrobe with your product/site and finally say that a set of functional elements can be a functional pattern, and a set of rules that defines the look&feel is called perceptual patterns.
Styleguides (Perceptual Patterns)
Every digital product, being a software or a website, starts with basic definitions of color, typography, borders, proportions, and they both respect the brand guidelines behind. Every design system has this core category, responsible for keeping the looks of buttons, titles and every bit that composes an interface. These rules and design decisions together can be called a Styleguide — you don’t have to describe everything your project is, nor style every functional pattern. You just need to have a clue about how it should look&feel.
Important: Styleguide is just a documentation, it can live inside a sketch file or website. It can show static or interactive elements.
Primer, by GitHub is a well-documented Styleguide. It has definitions for borders, shadows, spacing, animations, margins, everything that defines the looks of its product and appeals to perception.
How to use
Less cumbersome products, with fewer designers, can make good use of this kind of documentation. A simple set of visual rules can be a good starting point for keeping consistency and avoid the comes and goes of a design system.
What you can document in a Styleguide:
- Primary and secondary colors
- Typography usage/hierarchy
- Scale/proportions
- Icon style
- Border style
- Shadows
- Visual affordance (alerts, hover, disabled)
- Animation
Pattern Libraries (Functional Patterns)
Some call it a design system, but it ain’t one. Pattern libraries relate with what we’ve described as Functional Patterns. It can be a calendar widget, a navigation, a card with tabs, a modal, a multi-select or any meaningful, purpose driven block of interaction. Similar to Styleguides, it can live inside a design file or at the front-end.
As a designer, at some point you will have to deal with your UI sketches becoming real front-end elements. In this new environment, they have code, maybe a new language and other people around it. A pattern library may put everyone in sync.
Patterns libraries are put for greater use when they document the purpose behind each design design element, improving reusability and creation of new components and even unnecessary duplicates.
How to use
Start by documenting every interactive block in your product. If you have a working product, the UI elements exist in code as well, so make sure everything is aligned.
Components you can document:
- Navigation elements
- Inputs
- Buttons
- Cards
- Charts
- Tables
- Lists
On the practical side:
- If you want to keep it on the UI side, use built in libraries in Sketch, Figma or Adobe XD
- If you want to keep it on the UI and Front-end side, use tools like Storybook.
- If you want to keep it simple, with a set of HTML/CSS components, just create a /library page and list everything.
Do I really need a design system?
This article is meant to give designers a reflection about complexity and the tools we choose to work with. We can acknowledge that a design system is indeed a great tool for the way we create software these days, but we also should have in mind that this design system can become more complicated than the product you are trying to build if not tamed.
I work for a software consulting company, Guava Software, and we have a sort of clients with diverse challenges and contexts, each one at its own level of complexity. Our design team is composed by five talented designers, each one in a different front with stakeholders, users, developers and the product itself. So for a small team, with different products, it makes sense to have smaller and flexible structures.
If your product has a higher level of complexity and you can afford time and money to put your team to built, keep and manage a design system, go for it, the reward will be twice the effort.
TLDR
Design system
Documents the holistic view of the product. (brand, marketing, UI, copy, tone and voice)
Styleguide
Documents the looks, the aesthetics of brand or UI elements.
Pattern Library
List of meaningful, purpose driven blocks of interaction
Read more
