Design system and inbound requests

A design system team can’t handle the massive scope of work on their own, they need to work with the rest of the organization. Inbound requests are one manifestation of that: if people need the design system to give them something, they should be able to just ask for it.

The whole idea of building a design system is to create leverage: invest some amount of effort tokens and, if we’re smart and lucky, expect a multiple of that in return. If you look at this through the lens of the organization, it will mean that the team behind the design system should not only be less than the entire org, but also grow slower than the rest of the org. For every n new engineers in the design system team, the org should be able to afford hiring m > n engineers elsewhere.

There’s a few caveats though, let’s walk through them.

People don’t like tickets

I can hear “but it’s only an assumption!” from the back, yes, from you, young man manager. But the vast majority of people here are nodding in silence, and some just pulled up their phones to tweet about it. People just don’t like tickets, man. It’s busywork and it makes people anxious. But there’s a point where it’s important to start doing that.

The thing about tickets is that they are deferred. You don’t have to be online and respond to people’s inquiries about the new UI component or that deprecated lib. Instead, you deal with such inquiry — written and packed with metadata — at your own schedule. This schedule can’t be too loose, of course, but it definitely can be more focus-friendly.

So, what do you do?

There’s no easy way to get people write tickets. You need to make this task as enjoyable for them as possible while still getting all the information you need.

Free-for-all rich text input? Not gonna produce consistently good results: some people are terrible at writing their ideas down for others to read, be it too short or too lengthy (talk about the length of this post, huh?).

Multi-field form? Maybe. But to a respondent, it feels like passive interrogation, with required fields and such.

There’s another way that is still unexplored but that I’m bullish on: super short screencasts. Think Loom or ZipMessage. Get people shoot a short video where they explain — visually and verbally — what they want.

To make this experience awesome for everyone, train people to do that: include this in the onboarding walkthrough, provide good examples, and encourage this by continuously giving praise to those who do it right.

Once you’ve reached a good enough state, there’s the next problem: people wish for local optima.

People mostly see local optima

As someone on the design system team, you are responsible for the entire design language. In a way, what the entire product looks and feels like is associated with the design system, and therefore with you. That’s a lot of responsibility to handle! Let’s see how this can lead you to trouble and what you can do about it.

In an organization big enough that a design system team makes sense, there’s probably many teams, if not many products each backed by many teams (many of manies!). In management world, breaking down silos and bridging gaps is never out of fashion, but down on the floor we all know that people are busy with their stuff. It’s actually hard to keep up with everything that’s happening beyond what the team is working on.

As a result, your team might get inbound requests about things that could perfectly fit the use case of the team that’s requesting it, but that be it. For all the other teams, it might be useless. Or, it might break some use cases in the product that are way out of the author’s area of concern. And you might want to point that out. This is a peculiar dance that deserves a separate discussion though.

Your goal isn’t to tell everyone that they only see what they’re concerned about, while the reality is bigger. This won’t make you any friends, and it’s not very actionable. You’ve entered the game, and the ball is on your side of the court now.

A solution that Andrew Couldwell describes in his book, Laying the Foundations, is to create a special role in the org that would be embedded in the product teams — all of them! — and have a responsibility to maintain two-way communication with the design system team. Such role would not only bring the latest, hottest changes from the design system to their product team, but do the same in the opposite direction: whatever the product team has discovered that might be useful for the design system, forward that early. It makes sense for one very important reason: by the time an inbound requests, that is likely still locally optimal, reaches the design system team, they’ll be informed about similar things going on in other teams. And with a sufficient number of teams, there’s always going to be something going on. That’s a smart way to have not only decision-making power, but the context to exercise it, ahead of time.

This way, you won’t need to educate every single person on principles and practices of design decision-making at scale. Instead, you’ll be prepared to make choices for them — in a methodical way.

Alright, you’ve got the process going, and the information flow is good, but there’s one more thing to pay attention to.

You need to grow the skills on the team

One mistake that I regret making is not crafting job descriptions for the design system team early enough. But good thing is, there’s a lot of you can borrow from ops and SRE practices. You can’t just tell first-time design system folks to do certain things, even if they have been amazing software engineers or product designers before, — you need to either hire for the skills or train them within the team. In practice, both.

What exactly the skills to hire for? Among others, you want your team members to be on call — sort of. Handling inbound requests is a lightweight demo of being on call, and you want people on the team to get the basic work done and to continuously reinvest in the tooling and docs. Those are skills that are very different from the skills that are required to write working software, so take time to think in-depth about how to craft a job description accordingly.

Another thing, the negotiation and conflict resolution skills. Sometimes an inbound request comes in with a lot of stress attached, and it’s important that the person handling it doesn’t give in to the emotional component of the conversation. If a product team is approaching a big release, and suddenly they need a special case of a button (happened to you, too? a couple times?!), it’s the beginning of a discussion, not the end of it. There’s always a way to resolve it in such a way that it won’t disturb the scope and pace of work for the design system team and, simultaneously, won’t give you the reputation of being an utter jerk.

Finally, seeing big while seeing small is a special skill that is super rare. Every role, every single person on the design system team can benefit a lot from being able to think big and small, zooming in and out fluently and frequently. Design system is big, it impacts the entire product, but it consists of many small parts, because that’s what makes it useful to individuals and product teams: small, tangible, high-impact blocks that can be put together within clearly defined parameters.

---

This post doesn’t give all the answers, but I really needed to write it to have a point of reference for future ideas, lessons learned, and in-depth exploration. If you have experience in building and running platform teams in rapidly growing engineering organizations, hit me up on Twitter! I’m really looking forward to hearing any opinion and getting any piece of advice from people who’ve been through similar things.