Are you looking to deliver updates faster, more consistently, and with higher quality?
Design systems promote the reuse of code and patterns, making the web more consistent, efficient, and accessible and giving you time to focus on new design and UX challenges. One of Sparkbox’s earliest design system clients saw a 300% return on their investment in the first three years of having a design system (with 80% of time saved in design and specifications and 75% of time saved in development). With statistics like that, it’s easy to understand why so many companies are jumping to create design systems.
But some of them may be jumping too quickly.
In Sparkbox’s 2019 Design Systems Survey, in-house team respondents were asked if they could go back in time, what would they change about their design system. The most common answer was that they would do better planning from the beginning. Yikes! Design systems are no small feat to create, and that’s work you don’t want to have to repeat because you didn’t have the right plans up front.
You might be sitting there wondering “where do I start?” Let me tell you how I’d get started.
Unite Your Team
One of those respondents wrote,
“[I’d] rewind AAAAALLL the way to the beginning and have someone in the room when the initial development approach was discussed, so we can try to get them bought into the idea of a codebase connected into the design system.”
Design systems centralize decision making and unite groups who’ve had to make decisions without the benefit of all parties. While this is a great advantage, it can also be difficult for groups who’ve grown fond of the freedom to operate autonomously.
The power of having a centralized codebase that is delivered to and consumed by various technologies is great, but you have to figure out how to work with the right people to make that happen. All those groups, with undoubtedly different agendas, mean it’s going to be messy. And when things look messy, there’s nothing I love more than performing a Discovery to unearth as much mess as possible at the very beginning. You have to start by talking to the right people: those who will need to work in and with the design system and those who will be impacted by it.
Give Everyone a Voice
“Projects don’t fail for technical reasons. They fail because of people.”
This is a phrase evangelized around the Sparkbox office by our Vice President, Rob Harr. And it’s a phrase that proves itself time and again. To make good project decisions, we must pull in everyone we can at the start to understand how what we’re considering could help and hurt their current processes. And we want to openly discuss what we hear with everyone so that we can mitigate pain and maximize the value of that work for the teams.
We like to interview the central team members we’ll be working with, key leadership, and people who are very excited for the potential project. We also want to hear the opposition out. Someone who has the potential (and/or desire) to kill your project is often in the best position to say what could go wrong. We need to allow those people impacted and who could impact it to have a voice. Hearing them out allows them to feel included (which makes them part of the project and can soften their tone in future conversations) and often gives us the insight needed to alleviate their concerns right there in the moment or as the project progresses.
Sure, we need to talk about the technologies that are in play and in consideration for the future, but we also need to talk about processes and workflows (both today’s and potential future ones). We need to talk about how decisions are made. And then we have to do the really uncomfortable work of deciding who has the most say in how the project is conducted and its goals. In other words, who is the design system product owner?
Find Your Product Owner
A design system product owner, especially at a large organization, must be a masterful mediator. This product owner must have a clear understanding of business goals and know enough about the work to be done (user experience, development, etc.) to give feedback and help contributors appropriately scope their work. The product owner needs to know when to push and when to make concessions based on business value and effort. And the product owner needs to win and continually maintain the trust of the key stakeholders while navigating and communicating those decisions. You don’t have to know who this person is in order to start a design system, but the sooner you can establish this person, the better to help mitigate things going wrong.
Audit What Currently Exists
Another respondent from the Sparkbox Design Systems Survey wrote,
“[if I could go back in time, I’d] perform an initial product audit to better identify common patterns, before diving into the build of the system.”
This is a great idea. As part of a recent Discovery with a Fortune 500 company with 160+ web properties, we found they had already attempted the start of a design system. We audited this system and asked about its creation and usage so far to understand why this was only a first attempt. This audit showed us how to successfully move forward. And you don’t have to start building a design system in order to perform a valuable audit—perhaps you just redesigned something that you want the design system to start with. Auditing templates is a great place to start to see how close the current code is to a design system structure.
Look at What Others Have Learned
You can learn a lot from others’ experiences. Our 2019 Survey found that
“The 49% of in-house team respondents who ranked their design system as successful follow three commonalities:
Have a dedicated team to maintain the design system
Integrate the design system into the developer workflow
Source at least 50% of work product from the design system”
Let’s work our way through these points from the bottom up...
Organizations who source over 50% of their work product from the design system perceive their design system as more successful. This goes hand-in-hand with the second finding that having the design system in an external codebase and consumed via build pipeline or package OR having the design system in the main codebase is effective in creating a successful design system. Making it easy to consume the design system is one of the best ways to help it feed the whole of your sites.
Fortunately, if you’ve been following this article and talking to the right people (like the development team) from the start and getting them on board with the value of a design system, then they’ve already been exploring what it would look like to weave a design system into their existing systems. Making sure to act on a workflow that prioritizes this from the start—with the right teams—is a priority at the top of your roadmap.
This brings us to the final commonality of successful design systems. As soon as you start to build the design system, it will need to be maintained. In terms of management and maintenance, design systems are best maintained by those who are using them. Based on our 2019 Design Systems Survey findings, those who have a dedicated team with both designers and developers assigned to support the system are more likely to have a successful design system. Now it’s time to set a course to make something worth maintaining.
Big Vision, Small Changes
As another survey respondent wrote,
“[If I could go back, I’d] have [a] strategy in place before just doing it.”
Armed with your current pain points and your vision, you can start to logically outline the first few months of what it will look like to get there. Creating a roadmap will help your teams rally around the big vision while also giving you the smaller steps to execute that vision.
Experience (and the Lean/Agile process) has taught us that the biggest risk for software projects is building the wrong thing. Taking the time to plan your design system up front will enable you to start building the right thing from day one.
What I’ve described above is how we approach Discovery efforts for clients who are looking to create or reimagine their design system. If you’d like our help with your design system, let’s talk.
