Amy recently tweeted, “Increasingly I just think speed is a really dangerous and unhelpful design system metric.” Nathan and I both had some reactions to it, we had a quick, private group chat about it, and decided to discuss the topic informally in a way that others could listen into. Here’s a recording of the conversation we had.
There are many things we see eye-to-eye on, partially because we all influence each other through sharing our thoughts about design systems through tweets, articles, and many other forums. There are also a few things we see differently that came up in this conversation that I”d love to highlight here.
Amy brought up a wise point that the overall culture of the tech industry is to focus on speed at the expense of most other things. The recently-popularized mantra “move fast and break things” comes to mind, and there’s certainly a good number of teams that adopt this school of thought as a rallying cry. Amy pondered whether the ability to go faster is weaponizing leaders to further the toxicity of driving their teams past breakneck speeds, at the expense of people’s well-being.
In my opinion, the problem isn’t the metric; it’s the culture. Speed—whether we’re talking about the efficiency of the team or the ability to get to market faster—is one of the strongest appeals of investing in a design system. Rather than throwing out the motivation, I say get rid of the leader that weaponizes it. Turn around the culture that allows someone to take a benefit that can enable good and pervert it to run people ragged.
Bold words, I know, and certainly easier said than done. But that’s the work. As consultants, our job is partly to teach teams new skills. More importantly, we have to teach teams—and especially their leaders—what to do with those new skills. We don’t outlaw money just because people use it to buy illegal drugs and weapons. We instead try and teach our kids that it’s better to buy someone a sandwich. And there’s always more educating to do.
The struggle is more real for someone that works in-house, especially if you don’t have the privilege of finding another job. (Yes, the simplest solution to working under a toxic leader is to find a different leader to work for, either at the same company or a different one, but that’s not an opportunity afforded to everyone.)
So what do you do in this situation? Hide the benefits. Design systems help you work faster. If a sprint of work would have taken your team 2 weeks of effort and a design system helps you do it in 1 week, work at half speed instead, don’t tell your boss, and turn it in at the 2 week mark anyway. Two wrongs don’t make a right, but one right still makes a right. If your boss won’t use the time savings for the benefit of your team, you can take the benefit and spread it around to your colleagues under-the-radar.
Nathan also talked about quality and its high importance to design system success, but I think quality isn’t as important to design system work as people generally think it is. I’ve seen teams chase quality at the expense of adoption, and I think that’s the wrong tradeoff.
First, let’s define “quality.” Quality is “the degree of excellence of something.” As it relates to design systems, I’ve mostly seen that relates to components and either how beautifully they’re designed or how well they’ve been coded. I’ve worked with teams that will delay releasing a component for an extra week or two or four because the design could be better or because they’d like to refactor some code because it’s not as clean as they’d like it to be. Most times, those extra weeks don’t make any difference to how enticing the components are to feature teams. In my opinion, it’s just a waste of weeks that could have gone to other things that increase the likelihood of adoption.
In my opinion, the quality of design or code are some of the easiest things to improve iteratively, partly because:
I don’t believe we’re at the stage in our industry where teams are looking to adopt or create design systems as a way to improve the quality of their product offering. Sure, the promise of higher quality is there, but that’s often framed as a beneficial by-product, not the actual motivation. The real draw is the time saving.
Said differently, focusing on quality is a privilege available to the most mature teams. The majority of teams I encounter would love the ability to improve the quality of their products, but those are future problems. For now, they’re focused on what I believe is one of the primary draws of having a design system: establishing a shared way of working within an organization and having a tool that supports that. To me, that’s a smart roadmap and prioritization decision.
How’d all this sit with you? Strongly agree? Vehemently disagree? Amy, Nathan, and I have teed up a follow-up webinar to continue discussing these topics. Join us on May 3, 2022 and let us know what you think!
Read Next