Define a problem space for a design system team

Recently, I found myself repeatedly joking that if I ever join another company, knowing myself, I'll probably try to fund a design system team. It’s a management equivalent of drunk text: you sure know it’s a bad idea, but something happens, and here you are with a message that’s been sent and can’t be unsent. But the whole thing about creating a team that builds and runs a design system has to make sense! It’s not free, and there’s usually a lot of competing projects that need funding, so why put cash into something as intangible and not directly translatable into the customer value as a design system? Let’s put this whole idea under some logical scrutiny!

A model for justifying a design system team in the org

If I try to be formulaic about the idea of creating a space for a design system team to be, it’s probably that the benefits of having a central team should outweigh the expenses.

There are expenses:

• actual people on the design system team working on things
• hiring and managing individuals, which is likely going to mean creating a special accountability structure, communication streams, and the way to evaluate job performance
• scoping the team’s ownership area and keeping it focused
• there might be (should be) a series of one-off expenses on training, experimentation, ahead-of-time education

And then there are some benefits:

• having a team of highly specialized people means the rest of the org doesn’t have to specialize, — this gives almost everyone across the entire org the benefit of focus and peace of mind
• at the same time, product teams, whose core job is to create customer value, can focus exactly on that most of the time, while spending the least amount of time possible dealing with productivity problems (not easy to achieve, but it’s worth it)
• central roadmap for design productivity: if two teams need to invent two similar, perhaps nearly identical, things (let me sing a song about date pickers here [opens piano]), they just don’t, — or at least not yet; instead, they request a change from the design system team
• focusing the team on organizational productivity, as opposed to generating customer value, means the team can pursue the former without being distracted; for one, a non-obvious benefit: if things are done right, there’s never such a thing as production outage for a design system team

About specialization

How about a blast from the past? In the past, organizations, especially large ones, would throw around the expression “center of competence” to mean that there’s a group of people, a small percentage of the entire org, who can do a specific job. The rest of the org, it implied, can’t, but that’s okay.

Design systems work requires specialization, and if there’s a team where people are skilled and competent (in tech speak, engaged and committed to learning), the rest of the org can invest in other skills and domain knowledge.

You really don’t want to create specialized teams before you have evidence that not having them holds the entire organization back.

Let the product teams focus on the customer

A typical product team deals with infrastructure, tooling, or administrative work regardless of whether there’s any specialized teams handling any of those topics. The problem is, if there aren’t enough of those specialized teams, then that product team is going to deal with more and more infra, tooling, and admin work over time, because 1) the product gets more complex over time (at least internally), and 2) the organization gets more complex over time (and sometimes rapidly so).

The point of having specialized teams then is not to reduce non-production work in product teams to 0%, but rather to not let it go up while aspiring to make it go down gradually.

I found this to be a very important point. Usually funding a specialized team with the purpose of helping with organizational productivity happens with a promise of fixing some of the fundamental problems, sometimes such problems that no other org has manager to have solved (which is, in the very least, suspicious). Same for design system teams: be aware that some problems that lots of people wish were solved are still going to remain and only gradually get better over a very long stretch of time. Prepare for it.

Solving only (part of) the problem of organizational productivity

The first step here is to understand whether productivity, at scale of the entire org, is really a problem. Maybe it’s actually not?

You want enough signal on both good and bad parts of productivity among designers and developers. Every time a team gets stuck because they need to take a longer route to create something new or makes changes in the product, that what you want to see clearly. Are those changes related to design? Is the longer route a full cycle walking across design and engineering work? If people on the team saying “we can’t implement this feature, because we can’t show data abc, because we only made it to show data xyz”, that’s where you get a clue that creating and maintaining a more generic solution that can handle abc and xyz would justify the time spent.

You also want signal on product health. I’ve noticed that a digital product can survive remaining poorly designed much longer than people closest to production (so, designers and engineers) generally predict, but that’s not the point. It’s what teams need to go through that matters — let’s talk about why teams, and not end users, are important in this equation, and why design systems work should be considered as 100% inward-focused.

A bit of background on how non-product teams are funded in digital product organizations

Here (and pretty much everywhere on this blog) I talk about digital product companies. They are different in how things are prioritized and where the money comes from, compared to, say, technology service companies. At a sufficiently large scale, engineering organization in digital product companies starts flips to the point where having a specialized team working on internal tools and processes has a higher return per unit of cash spent when compared to having all engineers being focused on creating direct customer value but with whatever tools are available. Will Larson described the problem and the solution, which is funding specialized inward-focused teams past certain size of the org, in Productivity in the age of hypergrowth, and you might have seen it more prominently over years since.

Design systems work is inward-focused

At this point in my career, I’m pretty sure that design systems work is inward-focused, as in, the output of this work benefits exactly the same organization where the actual design systems team is located. Sure, the result of this work is, eventually, customer-facing: people use the digital product, they see it with their eyes, they hear it with their ears, they comprehend it with their brain, and it all is supposed to help them get their job done. But I’m yet to hear any of the actual end users of any digital products ever saying, “Yeah, I use ABC because their design system is fantastic” or “I enjoy using this product so much because it’s so designed and systematized”. I personally have been through a couple rounds of debate about who the actual user of the design system is, and who benefits from us building one, and at this point it’s gonna be really hard for you to make me think it’s about customers who pay money to use the product. While, simultaneously, I believe that a design system in an ambitious enough digital product org eventually ends up available to people who are not employees of that same company — third-party developers. But then again, those aren’t exactly the people who benefit from using the actual product in exchange for money.

Which leads to one very important point: the organization has to be past a certain stage of growth, to be in a certain state, for a design system team to make sense. A reasonable heuristic here can be, the moment you start thinking about reorganizing the entire department to eliminate the pain of messy cross-team dependencies and define clear boundaries (hello, domain-driven design) is a tad too early, but the moment you start spinning up specialized internal productivity-focused teams, — that’s when it’s time. YMMV here, but around 5–10 distinct teams is just about that.

Design systems work = design productivity work

This condition, when it comes to funding a design system team, should be favorable: just like a choice to fund a developer productivity team is reasonable, so is a choice to fund a — what you might call — design productivity team.

The question at the core is, how is it gonna scale? It might be okay for engineers to be messing around with tooling half of the work time when the org is small and people know each other by name. It makes you feel a completely different feeling when there are hundreds of engineers, and the cash burn rate encourages you to optimize the work in a way to, well, burn most of that for high-value activities.

And this leads to one very important point:

Design system is a byproduct, not the end goal

When I look at what Netflix and Uber are doing for the open-source community (check out Cadence, for example) and the tools they ship, my (very unsophisticated) line of thinking is: they made something internally, it turned out to be awesome, they open-sourced it, cool. It almost encourages me to think that the tool is what matters. But hey! Productivity of the organization is what really matters, and the tool is just a way to improve that, but it’s not the first tool, it’s not gonna be the last one, and it’s not perfect, and there certainly are challenges behind the scenes, where some teams aren’t trained enough to use it, some teams are rolling their own stuff, and most of the teams are unhappy with the functionality and would like to request this one little change that is gonna make them happy (and then, that it also is gonna make many other teams unhappy, is not of any concern yet).

It’s easy to make the same mistake looking at design systems. I certainly had made that mistake two years back, — which is properly documented (just as every costly and consequential decisions should be). My thinking was, hey, we’re gonna build this design system, it will be complete (i.e., fitting target state), and we’ll have achieved ROI. I thought the product — the design system — is what’s going to be a source of value, a monument for fundamental improvement.

A house is valuable in a sense that a family can live in it and make memories. A digital product is valuable in a sense that it converts problems solved into business growth. A design system is valuable in a sense that people who build a product are more productive. The actual design system then, — design tokens, pattern library, UI components, docs, Figma files, — is a monument for that value, but not the value itself.

Problem space

In concrete terms, design productivity is lost when

• designers have to reconcile their and their peers’ concepts of the same thing envisioned and designer slightly differently in different parts of the product
• engineers have to deal with cases of divergence: if the entire product looks one way, but new feature is designed in a way that it’s supposed to look and work even slightly differently, an engineering brain triggers a consistency check and throws an exception when things aren’t following the same pattern
• and, generally, teams recognizing that they’re about to spend time on something that could have been made generic enough already, so that changing it wouldn’t cost days-weeks of work

If it happens frequently enough, you might want to craft a mission statement for a future design system team, do some research on how companies hire and structure their teams specialized in that, and hire a few folks to get started.

Notice how it’s not about the look and feel of the product and how it’s not about the end user. Of course those things are important, but I learned the hard way that thinking too much about things that are out of the design system team’s direct influence is mentally challenging to a point where it can paralyze people and confuse them. So you really want to focus on just a few things, primarily inputs, all within direct control of the team. That’s why defining a problem space in a way that easily translates into what the team is actually going to be doing (and not some second-order effects like better user experience) is one of the key first things you want to do.