How to turn ‘slow’ into fast
Design systems standardize decisions. It takes a lot of time to gather complete context, codify, publish and validate decisions that often happen in a vacuum. System teams need to move slowly and thoughtfully, but many organizations prioritize visible speed. How might design system teams be true to themselves while also aligning with corporate culture?
Many design system experts share perspectives about how design systems should move slowly. And I personally agree. Slow, continuous progress over time results in a higher quality system. High quality systems allow product teams to move more quickly. Product teams innovate and ship features rapidly. They test, explore emerging tech and win the race against competitors.
As product teams sprint and race, system teams slowly work to standardize organizational decisions into repeatable structures. Systems should change slowly over time or else teams using those systems will spend far too much of their time updating and migrating. Raise your hand if you’d like more frequent breaking changes…no one?
But this slow-system mindset leaves design system practitioners on a bit of a cliff. It’s difficult to align a slow approach with an organization that treasures speed. Treasuring speed is not wrong, and the market does reward the companies that ship that new feature first.
Design system teams often face pressure from many directions to move as fast as the product teams they support. Going faster for the sake of speed or perception of speed can damage quality and underlying cohesion in a system, undoing much of the hard-earned benefits.
So let’s explore a few ways to preserve a healthy slowness in system work while rising to meet expected pace in your organization.
First, break it apart
Like climbing a mountain, building a system has to be broken down into smaller achievements that feel attainable and deliver incremental value. Getting to base camp is just as important as reaching the summit.
Sweeping, system-wide updates (token taxonomy or library refactoring) and complex component releases (tables or charts) can take an immense amount of effort, time and love. A complete release might take half the year, but there are always ways to deliver value to your audience in smaller chunks.
For global updates, giving early access can help validate decisions early and build up knowledge in your audience ahead of that big release. Validation can prevent large investments of time in the wrong direction, and building up knowledge can make adoption of the latest and greatest smoother. Running an early access program can serve as a deliverable in and of itself because synthesizing findings and prioritizing action can be quantified.
For complex components, defining an MVP release of the most basic version of the component can get the work live faster, setting up a feedback loop before all the bells and whistles have been strapped on. The feedback loop is often revealing, and again can help direct how teams invest their energy. The best feedback loops highlight the right ways to simplify and reduce what the system owns and maintains.
The benefits of smaller releases and early access go both ways. The design system makers get better insights into how their audience will actually use what they make. The consumers of the system get to join the process of defining and shaping what lives in the system. These collaborations can help build up the community’s sense of ownership, especially if your design system is owned by a central team.
Be a multiplier
One person can only personally do so much. But one person can teach others to do what they do in a surprisingly short amount of time. Let’s get the whole village fishing.
The label of being a multiplier was coined by Liz Wiseman in her book by the same title. Multipliers are leaders who are dedicated to deeply growing the people on their teams to multiply their own personal impact. Leaders are more impactful when their teams are set up for success. The same concept applies to practitioners in many fields who are working to enable others. A doctor who teaches first aid to tend to larger groups of people. A developer who writes about coding best practices can inspire others to act on ideas. And a design system team can help other teams apply and extend the system far beyond their own capacity.
Dedicate time to enable others in your broader design and development team to reuse and contribute. Teaching others to reuse the system more effectively will boost adoption. Guiding contributing teams will strengthen what teams share with each other and spread a more common systems thinking mindset. As time is spent teaching others, more contributors are activated and a broader group of the audience will know the ins and outs of applying a system.
As you invest in others, you also pull back the layers of everything that goes in to releasing a new component successfully. It’s an opportunity to address unrealistic expectations that teams might have of how quick they think the design system should move. The logic behind a slower pace is much easier to see when we’re in the trenches together.
Find the right time to hit the boost
Even in long distance races, there comes a time when it makes sense to pick up the pace. Those times shape external perception of a team. When it was time to hustle, did the team rise to the occasion?
It’s important to recognize that different types of systems work require different pace. Token taxonomy updates will take time, especially if there are deep, open questions about brand strategy. Smashing a bug on the other hand should be a rapid change that can directly impact the community and the team that reported it.
There will also be times when an urgent need arises from the community or a new priority comes our way from leadership. In both cases, eyes are on the team, and this is a golden opportunity to re-examine priorities and change if needed. Showing an ability to shift focus to what is high priority for either groups will change the perception of the design system team’s pace in a positive direction.
This can be a slippery slope, though. Changing focus based on what other’s value can be beneficial, but teams must keep sight of their vision. Pivoting for the sake of being nimble can easily lead to being too reactionary and diluting the deeper purpose. When new priorities rise, they need to be actively examined next to current plans. If they align with the vision of the system and have greater importance, go for it! If not, it’s key to communicate back to stakeholders why a priority was moved to the backlog or even denied. Basically, it’s ok to say ‘no’, but take the opportunity to share what matters most to your team and how you make decisions.
Build speed into slow
At the end of the day, speed is exhilarating and challenging. Finding the right place to be fast and iterative can energize a team and bring life into a system.
The main body of the design system should be slow (or stable) in my opinion. But the way we create the system can have pockets of rapid progress. Methods like innovation sprints (ex: Google Design Sprints) or component sprints (ex: Washington Post’s component sprints) can accelerate the rate of progress on simpler components and process issues alike. Using iteration and research to quickly prove concepts can help keep complex component work moving and build excitement and empathy into the process.
Beyond process, many organizations are finding a void that exists right outside their design system. Product teams create on top of the design system, and share between teams when there’s opportunity. This outer layer of components is owned by the community, and often changes rapidly. In my current team, we have a distinction between our core design system and what we’re calling Commons. Commons is built and owned by the community, and it’s also built on our design system. It’s very similar to recipes from Brad Frost’s Design System Ecosystem. It can also be compared to the Carbon Design System’s approach to community assets.
Everything in our system is globally applicable and free of business line logic. The contributions in Commons have specific logic built in and tend to have a narrower range of application. It’s not sustainable for our design system team to pick up and maintain everything in Commons, and it would also set us up as a massive bottleneck because we test, experiment and revise so rapidly in Commons. The community owns those things, so they can make them better, faster. Commons is our layer on top of the design system that moves faster, builds on experiments and helps us see emerging trends in our community more clearly.
Pace is complex
As creators of design systems, we need to be very intentional about our pace and setting healthy expectations around the work. None of this is about deception or tricking people through misdirection. This is about working out in the open and finding pathways towards collaboration, continuous delivery and the right kinds of agility.
These are from my own experience, and might not work for you. I’m also sure I’ve missed some brilliant ideas, so if you have ideas on how to turn ‘slow’ into fast, please share!
