About the time Ethan Marcotte published Responsive Web Design on A List Apart in 2010, my partner, Jesse James, and I fully embraced responsive web design for our clients. It was bumpy back then and after painfully building out a few responsive apps, we knew we needed to make the practice easier and more repeatable from project to project.
This led us to the practice of creating pattern libraries where we could separate the front-end design and code from the main app and start building a repository of components (navigation elements, hero images, content blocks, etc.) that we could leverage and enhance across all the products we worked on.
Around that time, Brad Frost introduced the Atomic Design metaphor to front-end development. Jesse and I fell in love. Using this metaphor, our front-end components were divided into “organisms” (large components), “molecules” (medium-sized components), and “atoms” (smallest components).
This metaphor took off, not just with us, but it seemed like the entire front-end development world leaned into it. Big time! And it’s had a massive impact on the design and front-end development world. Kudos to you Brad!
At this time, many organizations had already been using style guides for a long time, and combining that with rapidly maturing front-end development practices the Design System for digital products was born.
What is a Design System?
Nielson Normal Group has a nice 101 article on Design Systems that you can read, but I like this quote:
A design system is a set of standards to manage design at scale by reducing redundancy while creating a shared language and visual consistency across different pages and channels. Design Systems 101, Therese Fessenden for Nielsen Norman Group
To add a little of my own panache, I think of Design Systems as being the center of gravity of design for all of the digital products (native apps, web apps, and websites) that your organization designs, builds, and maintains. You might be a software organization that has a family of apps that share a common set of front-end components. Duolingo for example has apps for Language, Math, and Reading and beyond just the logo, you can easily tell they are owned by the same organization. The designs of the individual products are different for different customers but there exists an underlying visual and interactive consistency that supports the organization's brand, while not specifically pegged to any one of their products.
Just as Duolingo’s Language app has its own voice and tone that’s different from their Math app, a design system shouldn’t feel exactly like either of these, rather the design system should be the center of gravity between the two. This center of gravity has design styles and front-end components for the organization and supports the variant designs of other products that leverage the systems. This is where things get hard.
So, if you’re an organization with one or two, a few, hundreds, or even thousands of digital products, should you use a Design System? The TR;DL is that it depends. Before you get to a “yes”, there is a lot of “no” to navigate.
Short Answer: No
I hate to say it, especially as someone who has spent a lot of time being a proponent of design systems and having directly worked on them for several years. With that perspective though, I can say, that many organizations just aren’t ready for the overhead and governance of a design system.
Two important questions I recommend asking when you’re considering a design system:
- Has your organization embraced a culture of human-centered design and Agile software development?
- Do you have a mature approach to product strategy that embraces outcomes over deliverables?
If the answer is “no” to either of these, then I would recommend focusing on where there are gaps with these first. Otherwise, you’ll risk implementing a design system into your organization where it will be both a large effort in terms of time and cost to create and a big uphill battle for your stakeholders to understand the value of the design system.
To break this down further, there are four factors to consider for the long-term success and sustainability of your design system:
Stakeholder Buy-in
If your organization doesn’t already embrace a human-centered and Agile design and development practice, then getting stakeholder buy-in will be very hard. Organizations that prioritize deliverables over outcomes will simply not see the value in the strategic investment of a design system. Organizations that prioritize top-down design over designing with, and for, the humans who use your software will struggle to overcome personal priorities over making decisions that impact users across all of your software products.
If you’re struggling with either of these in your organization, then the culture of your organization may be too far removed from understanding the value of supporting a design system.
Design systems are a bit like flywheels. Once they get going, they’re great, but they take quite a bit of energy to get spinning. What happens in the meantime, especially if your company doesn’t treat it as a separate product with a dedicated team, is a slowdown of those deliverables. At the onset, design systems do not increase output. Rather they decrease output and increase outcomes over a period of time.
If, on the other hand, you’re fortunate enough to work for an organization that dedicates time to long-term strategic innovation and prioritizes outcomes over deliverables, then yay for you! You’re in a much better place to get buy-in for a design system.
Design
Design systems require dedicated time and humans to create the important center of gravity of your organization’s voice and tone for its digital products. In a lot of cases, the beginning of this may exist in some form through branding assets, style guides, and other collections of design assets that you’ve used over time. But none of these in themselves establish the center of gravity for your design system. Instead, they’re often a loose group of artifacts, with different versions that collect over time. They may even be competing with each other and therefore working against establishing that center.
Design teams must first establish the center of gravity of the design system by determining the central voice and tone that all the products will orbit to some degree. Product designers for each of those individual products will start at this center and then, depending on the individual product strategy, the product will either be in an orbit that is closer to that center of gravity or farther out in space.
I learned this the hard way. We failed to establish the design system’s center of gravity because the organization prioritized deliverables over outcomes. Prioritizing deliverables led to the system being extracted from one of the dominant products in the organization. This, in turn, created an unstable center of gravity for the design system.
The roadmaps for the product and the design system were separate, but because the design system was not treated as the central voice and tone for the organization, it was both competing with the output of the product and biasing the entire system towards that product.
Your design system is its own product. Ideally with a dedicated team for design, development, and governance. There’s a vision, strategy, and roadmap with measurable outcomes like any other digital product in your organization. Without this, instead of ending up with a design system, you may end up with a three-body problem.
Development
We all know that development cost is expensive. Luckily, there are great frameworks for building pattern libraries that serve as the technical documentation for your design system. Pattern Lab and Storybook are a couple of examples that you install to build out your system. Figma on the other hand is a great SaaS solution for building out your design systems without having to support your own code.
Deciding which is right requires some homework around building versus buying the solution. Special consideration should also be spent on how well these solutions support accessibility if your products must be WCAG compliant.
Regardless of which path you take for the development of the design system, there is technical decision-making that needs to happen in order to ensure that you’re building future-friendly design and engineering workflows for your teams.
Governance
When I say governance as it relates to design systems, I’m mainly talking about:
- Managing the initial design and build
- Creating workflows for when and how to update and add new components
- Documentation and adoption
- Versioning strategy for updates
Brad Frost talks a lot about the governance of design systems, which I recommend checking out. I also recommend establishing good systems of governance in the very early stages because it will allow things to go more smoothly and be more iterative from the very beginning of the system. These are, after all, the “systems” of the design system. Without these working well, the adoption and efficiency of the system will be impacted.
For example, let’s say you have a simple design system that includes a well-documented style guide including typography, inline styles, image, and logo guidelines. It also has a starter collection of front-end components like buttons, form inputs, and a group of content blocks. One or two product groups in your organization are piloting the design system with their team and they’ve been eagerly adopting it and piping it into their back-end development workflows.
You soon realize that you have to make a change to one of your components. Maybe some margins weren’t working or you need to revise some JavaScript in a component to work better on mobile devices. You now have a versioning issue that you’ll need to work out so that the teams who have adopted the design system can bring in the updates without breaking their app. What could have been a little upfront legwork to build a versioning workflow now becomes a sticky change management challenge and some raised eyebrows from your engineering teams.
Other times, you may be wondering whether or not to add a new component to your system or to create a variant to an existing component. Again, Brad Frost has a great chart for when and when not to create a new component.
Long Answer: Yes! 😀
Design Systems are awesome!
- Your org owns several digital products ✅
- Your org is Agile and human-centered ✅
- Your org embraces outcomes over deliverables ✅
I found this fun Design System ROI Calculator you can use to drop some dollar signs into your decision-making process. This calculator can be a great visual helper for stakeholder buy-in, however, it fails to factor in all the above complexity of buy-in, designing, developing, and governing your design system.
What I do like about this calculator, however, is that it paints a good picture of how increasing adoption of the system and making it more efficient to use has huge cost savings benefits for the long-term. So, just like any other digital product, you’ll have to factor in the long tail of getting to product-market fit, before you’ll see the benefits of adoption and efficiency.
Adoption and efficiency are great outcomes to measure for your design system. All the other rules apply as well. Start small and work iteratively. Test with actual users of the system. Make sure you know what jobs you’re solving for. Pilot with a group or two and grow the system from there.
Long-Winded Answer: Depends
If you’re still here, you know there’s a lot to consider before deciding on whether or not a design system is right for your organization. Like me, you’re also bought into them generally being a great practice for creating a consistent brand and user experience across digital ecosystems. But just as any other transformative practice takes time to implement, get buy-in, and eventually shape the culture of how things are done, start small. Start making progress on those first two questions. Once your organization is thinking more agile, more human-centered, and more outcomes driven then you can take some baby steps into the systems.
You don’t have to do it all at once. Think iteratively. What’s going to create the biggest impact and be the easiest to adopt for your organization? What are some longer-term strategic concepts that you can begin educating your organization about for that future design system?
Wherever you are on this journey. I hope this helps a bit and remember, you’re not alone!