The state of design systems in 2020
Back in 2017 I started a new job architecting and building design systems at a fortune 500 tech company. During these three years there have been drastic improvements to the design system ecosystem. Design tools like Figma with a focus on building and supporting design systems have started growing in popularity.
Code tools like Stencil have been cranking out features making component libraries easier to build. It’s an exciting time to be part of a design system team, but with the booming changes of the landscape, it can be a daunting project.
What is a design system?
Systems are the cornerstone of success in a culture of innovation. A design system is no exception. While the definition varies depending on the context, I define a design system as a software development resource that provides value to an organization by:
- Documenting a consistent, yet evolving, design language.
- Accelerating the design and code processes.
- Systematically tying design and code together.
🔗 Resource: Brad Frost sometimes writes about design systems.
What does a design system consist of?
As you start digging into a specific topic, you’ll find it keeps getting deeper and deeper. There’s always more you can do in any one category. Scoping your design system to meet the needs of the organization is crucial to its success.
While scoping your design system it’s important to keep it slim. Above all else, your design system is a tool that your designers and developers will use to do their daily job. Your goal is to add value to their workflow by providing them a useful tool that they want to use.
What shouldn’t be in a design system
UX research and its related data should not be in a design system. The conclusions that make up the design guidelines should absolutely be backed by research, but the research data used to derive these conclusions shouldn’t be included. Your goal is to create a valuable tool for production.
💡 From my experience: I suggest creating a UX research system within the organization. I like to describe the design system and the research system as the yin and yang of design innovation — they fuel each other to keep design evolving within the organization.
Considerations when scoping your design system
What design softwares does your design system need to support? Sketch, Figma, and XD. Those are the big three in the UI design world today. Sketch being the most widely used, but Figma and XD are both cranking out features with, seemingly to me, a focus on being the better design system tool. You’ll likely need to build a design library for each software used by your designers. Each design library you build will require constant support and maintenance.
💡 From my experience: Figma has the better feature set and environment for creating design libraries. XD looks more and more promising every month though, so keep an eye on it. Sketch is just as capable with some plugins and 3rd party tools, and looking at what Sketch has planned for 2020, they might just end up the better tool after all. Regardless of who wins the battle royal it’s an exciting time for UI designers.
What code technologies should the design system support? From web technologies like React, Angular, Vue — to mobile technologies like Swift, Java, and React Native. A component library can be built for a multitude of different technologies. Each component library you build will require constant support and maintenance. This is often the scope creepiest part of design system. Unfortunately, these technology divides often result in multiple design systems being built within an organization — sometimes unknowingly to each other. Spotify found themselves in this exact situation.
💡 From my experience: Web components are a viable solution for creating components that can be used in any modern browser based technology. I highly recommend checking out Stencil — “Stencil is a toolchain for building reusable, scalable Design Systems.”
What are the goals and objectives of the design system? Deciding on your underlying goals and objectives is a crucial requirement. You’ll find there are influences from different parts of your organization. Some will push to optimize the system to improve time-to-market while demanding it tomorrow, others will want to over engineer and future-proof, some will want to focus solely on the user experience and design. The goals you come up with will ultimately decide your priorities, so spend some time talking with the leaders in your organization to ensure you’re providing as much value as you can.
💡 From my experience: Despite what you’re reading, creating value with a design system is a monumental task. Honestly, just getting people to use the damn thing will be difficult. The cost of a good design system compared to the value it provides can easily be a net loss unless you scope and plan accordingly. Your job is to research the organization, calculate the possibilities, and create the tool that provides the utmost value.
Utilizing open source solutions. Creating everything prudent for a design system from scratch is a resource consuming and costly task. Instead of building it all yourself, I recommend using open source solutions when necessary. Take Gitlab’s Pajamas for example. Instead of committing to building their own charting components, they utilized an open source solution. Many companies choose to use Material Design Guidelines instead of spinning the wheel trying to create their own guidelines. If your organization’s goal is to move quickly, open source is a great solution.
💡 From my experience: The hard truth is, you’ll have to make tradeoffs. It likely isn’t conceivable to build, support, and maintain everything that you want in your design system. My advice is to use open source solutions as much as possible and spend your resources focusing on what will give the most value to the organization.
The Meta Systems
The meta systems, or the systems that are built for maintaining the design system itself, are just as important to the success of the project as the design & code. These systems should strive to make growing, scaling, and maintaining your design system as frictionless as possible.
The governance system. Your design system should constantly be growing and evolving. That’s easier said than done though. The most important step to ensure the design system grows as intended, with as little friction as possible, is to document a sound governance process. Here are a few questions your governance system should answer:
- Is the design system centralized or distributed?
- Are the design guidelines strict or loose?
- Who maintains the different parts of the design system?
- What does a designer do when they can’t find a component they need?
- How do new components or features get added?
- How is quality assessed and assured?
🔗 Resources: Brad Frost wrote about the governance process in detail. Nathan Curtis also documented governance models that were tried at Oracle.
Documenting your design system. The documentation system is another crucial part of a design system. This is the centralized hub where anyone in the organization can come to and learn what your design system is, and how to use it. Most likely you’ll want to build a doc site. This is also a great place to document your progress and roadmap. Your doc site will turn into yet another large system that someone will need to build, support, and maintain.
CI, CD, & automation. By now you’re probably seeing just how quickly the scope of a design system can splinter out of control. With multiple design libraries, code libraries, guidelines, and various systems, it can easily be overwhelming and in some cases just not feasible without the help of engineering efforts. Automation should be used as much as possible to keep all the moving parts of the design system synchronized and ensure quality.
💡 From my experience: Automation is king in systems. You can do things like visual regression testing to make sure the design components and coded components are always visually synchronized. Using features like Figma’s Embed you can automate syncing design with your doc site. You can automate testing, deployment, and numerous other more detailed tasked within your design system to help ensure the system scales with less friction.
Common problems & pitfalls
Updating the design system. It can be difficult to keep design files, code, doc sites, and an organization in sync. There’s no such thing as making a simple change. Every change trickles throughout the entire system and even the organization. How do you ensure designers and developers get the new changes in their working environments? A documented governance system along with some smart automation will help ensure updates are as simple as possible.
💡 From my experience: Figma’s Team Library is a great solution for sharing changes across design projects. While hosting a component library on a repository manager like NPM is a great solution to make sure developers get new updates in their project’s code base.
Theming the design system. One way or another, you’ll need to allow for theming. It could be dark mode, it could be white labeling, it could be wireframing. We can build theming into the core of our design system in both design and code.
Getting community support. Likely, your governance model includes some kind of community support model. From advise to bug reporting to pull requests — if you aren’t allowing for as much crowdsourced support as possible you’re setting the system up to fail. Open sourcing, and using open source solutions, is a great way to get support from people within your organization, and all over the world.
Getting people to use it. One of the biggest challenges once the design system has been created is getting people to use it. Don’t attempt to force your organization to use it. Instead you should strive to make a tool so good they’ll want to use it. Designer & dev experiences should be a major goal when creating your design system, if you want people to want to use it.
What’s next?
Hopefully this gives you a good starting point for planning out your design system. Follow along for more posts about specific design system problems I’ve had to solve — along with some cool experiential ideas. There are a lot of really cool topics that I’ll cover like synchronizing your design library and doc site, doing snapshot testing to automate consistency between design and code, and is it possible to ditch Sketch and use purely coded components to create your design library with the help of React & Framer? Let’s find out! Follow along and let’s learn together.
