Decision-making velocity and deviation in design systems
When you start building a design system, the team is new, the topic is new, people in the organization are hopeful but mostly unaware of the challenge, and it’s important to pick a strategy in the beginning. Two options are “do things right” and “do things fast”. I chose “do things right” in the early days, and that backfired; gradually switching to “do things fast” worked pretty well though, despite the team being already known in the organization by that time.
A lot of the issues the core team encounters along the way caused not by the amount of time it takes to implement a change, but the amount of time it takes to agree on how it’s going to be implemented. Decision-making is a bottleneck.
The core team, sensing that they are a bottleneck, might start cutting corners. For a design system this would mean deviation from the main direction, gradually becoming less useful.
In this post, I’m exploring the idea of doing things fast as a strategy for an early-stage design system team:
- choose to move fast and, to keep moving fast, purposefully sacrifice the coherence in the design system
- track the deviation: make it a habit to document all the cases, then measure it and compare to the team’s velocity over time
- and then experiment with the purpose of adjusting the decision-making velocity (increase it) and accidental or purposeful deviation in the design system (decrease it)
Learn to make decisions fast
Decision-making velocity is the rate at which the core team can clear the future changes in the design system. If you pursue expansion through contribution, each decision needs to take into consideration how well a change will fit the system and how much simpler the reasoning about the next batch of changes is going to be. The zen of contribution flow is when every next decision, every next change is based on one or more of the previously accepted and incorporated changes, thus taking less and less effort.
This is a noble effort to make the design system less spontaneous. You want the design system to take the least amount of mental effort to apply in the greatest possible number of cases when thinking about changes in the product. There isn’t any use for a design system that is close to being as complex as the product it is supposed to power.
In reality, the “compounding” maneuver, when you build up decisions in a way that every next one has more leverage and is easier to make, doesn’t seem practical. Going for such an extreme would mean overthinking a lot and betting on assumptions. Unless you and your team are certain that you have a perfect understanding of the product suite and the design system that supports them, it’s better to find a way to make small decisions at a high frequency, but in a way that they lead the outcome — the design system — towards its target state. So one day, you’re talking about the date picker that should pick a date range, and another day about height of the button and height of the text input clashing, and the next week you find yourself discussing design tokens around motion and animation that are somehow still hardcoded all over the UI, and in each of those case you’d actually benefit more from making a good-enough decision quickly and inform everyone involved about why it’s good enough and what you’re gonna do next. Three-quarters agility and one-quarter long-term vision.
That all said, I’m a believer in fast decision-making now. Especially in the very beginning, assuming the organization is taking first steps building a design system, the core DS team needs to go fast. Unless the org values getting things right at first attempt, making decisions and turning the changes around fast is going to give the team the most credibility, of all scenarios.
Track and measure deviation
After you have achieved fast decision-making, it’s time to track the deviation from the direction the design system is taking.
What is deviation? It’s a new variant of a UI component that doesn’t seem to fit with the rest. For example, a button that one can make “default”, “primary”, “secondary” and “anchor”. Or a new design token that represents a color or a spacing that is not used anywhere else in the product.
Tracking deviation, but not trying to prevent it, seems to be a reasonable strategy. A lot of stress and grief that I’d made a mistake of putting my team through was trying to get things right at the first attempt. For many months, I had been telling the team that “every person on the team should be able to make a decision in such a way that every other person would make the same decision” and “consistency is part of our definition of done, hence inconsistent changes can’t be added to the design system”. While true in some ways, it wasn’t timely. We were starting out, we didn’t have a complete system yet, as in, could be used to guide the creation of a new product feature end-to-end. This was effort spent towards things that mattered less than — guess what — ability to accept changes much faster at a slightly lower quality threshold.
Still, you can never tell how useful your design system is if you don’t know how much it deviates from the product and from its own direction towards the target state.
Deviation is debt. So the same techniques can be used to track it:
- document every deviation
- document its origin: is it a change in the design system itself that doesn’t fit the rest? is it a change in the product that has new custom implementation that contradicts the design system?
- measure and take no action — yet
Important: you want to measure the deviation to tell whether the strategy is working. You do not want to measure the deviation to tell whether the team is performing. There can be many reasons for why some of the changes to the design system do not fit perfectly, and while some of them might be a result of uninformed decision, there can be good reasons for most of them. If there are too many, it’s likely the direction you’re setting for the team and the vision for the design system aren’t correct.
First step to taking things that go sideways under control is acknowledging them. So, acknowledge the deviations: snap a screenshot, describe why it’s no fit, and create a ticket. In code, adding a “TODO” comment helps: it’s a convention, it’s understood by most people who write code, and you can grep that.
Capture the cases where the product and the design system do not match; for example, the way the data is presented in product UI does not match any of the data presentation and manipulation patterns described in the design system.
Also, capture the cases when the design system internally becomes less cohesive; for example, a new UI component contains too much custom presentation code and does not rely on more basic primitives that other UI components in the component library are built from.
You’ll end up with a collection of tickets. I found the value not in walking those tickets over the development process, but in just the fact that they exist. If you only measure the number of these tickets per unit of time, this will provide a basic but useful statistic: how much up or down does it go over time? Remember that you’re still optimizing for moving fast. If the number of tickets goes up and accelerates, don’t freak out, stick to the course.
Experiment with deviation and velocity
The next step is to find a combination of parameters that works best for the team — and restaff if that makes sense.
Once the core team is comfortable making decisions and subsequent changes quickly, and you are aware of the number of cases where this doesn’t fit the overall direction or target state of the design system, you might want to try:
- run a few especially rigorous design critique sessions
- ask the product teams to walk, together with the design system team, through the entire process, from concept and early design draft to the implementation and pull-request
- or invest into onboarding materials and live training sessions to inform product teams about the practices they should follow to make changes that better match or fit into the design system
Try each a couple times, invest 10–15% of the team’s effort on that, just don’t swing too much in the other direction. You don’t need a full-blown design system certified practitioner program, just a few retrospectives with people who are open to giving and receiving feedback.
Over time, you’ll see either the velocity going down, or the number of deviations going down, or both. Or maybe something else. I had seen velocity and deviations decreasing together, — a perfect case for adjusting the team staffing. That said, I tried to keep the team configuration without changes, betting on a small core team with lots of experience and skill; more about the reasoning later.
Note that in a rapidly growing organization, the increasing number of new people and teams is going to mess with the stats. It’s gonna require effort to distinguish between deviations caused by lack of context (don’t know the rules, so break them) and deviations that are informed and thoroughly planned (know the rules so well, can break them).
You’ve probably had enough of the word “deviation” for today, haven’t you? If you’re just starting as a leader in a brand new design system team, I hope that this post provided yet another point of view on how to set the team up for success in their early days. If you’re a seasoned practitioner, then my hope is that it helped you recollect some of the past choices, how the team should operate and such, and evaluate them. Either way, I wish you a fantastic week ahead! As usual, feel free to ping me on Twitter & share what you think.