Growing Pains: How We Scaled Our Design System Support

If you're building a new platform team, your customers are going to go through many changes. In the case of a design system, tools, hacks, and practices that made your team wildly successful are also the cause of long term design and technical debt. Making corrective changes to mitigate these problems with a platform can often mean taking away these legos. Although this is positive, you're playing with feelings and agency. And the way you communicate these changes and support people in the transition can be the differentiator between success and rejection.

We saw this as the Twilio design system was incubated and eventually scaled organization wide. Here are some of the ways we scaled our support, helping our customers and ourselves through these stages.

Stage 1: Support as incubation

In 2018, we didn’t have a design system at Twilio. This meant that the most efficient way to express a UI solution involved copying older implementations and adopting popular code snippets and packages. In and of itself, this was fine: however, it did create situations where a UI compromise was necessary.

Since we were just incubating and weren't fully staffed or bought-in by the organization, we took small steps. One such step was the creation of a *help* slack channel. Here, no matter what your UI question was, we'd attempt to solve it. What's more, we wanted to solve it quickly. While this approach didn't allow for the best answer for each experience, it did allow us to take diving catches that built trust with designers, PMs, and engineers.

This support model worked as intended. Over the years, engagement in this slack channel increased. Front-end engineers and product designers organically found community and the best possible way to solve a problem. This whet the appetite for a design systems team, and provided enough evidence to make key hires could actually build a system.

Stage 2: Support as we scaled

Fast forward about a year, and Paste was at the foot of a steep adoption curve. Unlike our legacy libraries (which had larger, more complex monolithic components), we had moved to an approach of small, accessible, and composable pieces of kit that could be mixed and matched. Designers and engineers were beginning to use the system in their UIs. As they went about this, there was a lot of learning and undoing of old habits that was necessary. We started getting a lot of questions around component usage, accessibility, composition, UI reviews, etc. Answering these questions took some time, and as we saw 20+ questions a day, the four person team began to feel it.

This was a good problem to have: customers were buying in to the design system at a pace that was greater than anticipated. However, this meant that we were increasingly devoting more time to support rather than new development. This put a dent in our shipping velocity but more importantly affected team health: support is hard and often a thankless job. To mitigate these problems, we investigated why our support model was failing at scale:

• The immediacy of Slack meant it was easier for people to get answers to their questions through a Slack message than go to the doc site to look for an answer.
• Slack messages are ephemeral and teams around the world would routinely wake up to a host of new information that they’d just not see, leading to repeated questions.
• The quality of incoming requests was affected by the medium: “My build broke, can you help?” instead of “My build (screenshot attached) failed, I am currently doing x, and tried to do y”

A change was necessary: we needed to evolve our discussions from "What's fast and cheap?" to "What's right?". To address the rising tide of support questions, the team stepped back from answering every question and made some changes:

• We improved documentation structure based on feedback. This included a greater focus on examples and do's and don'ts.
• We began a rotating helper model for the team to lead support conversations through the week. This allowed the majority of the team to focus on work, while mentally preparing our weekly support helper to embrace conversations with service mindset.
• We also made a big change to how we support teams by moving all conversations from Slack to GitHub discussions.

The last change was particularly significant: moving the support model from Slack to a new platform was more than a minor inconvenience. To many, it was a breach of trust that the system was founded on. Managing how our users felt about this change was an important criteria for success. We’d need to inform people of the change, and then remind them of it enough till the habit was broken and remade. And we had to hope that in all of this, they still trusted us.

Making the support change

How we announced it

We made the support official at an All Hands meeting. But, keeping this change from unraveling meant a consistent change in team and customer behavior: we’d need to be persistent. We had to politely, but firmly say no to every request unless it came from the right channel. This also made it a feelings management problem: it was hard to have a team that had once routinely said yes, and to every request, now point to an external URL for any help.

Enter the automations

We addressed new users first: using Slack’s Workflow Builder, I built a bot that DM’d anyone who joined our Slack channel for the first time with a greeting, important information, and link to our support and documentation. While this helped, we still had hundreds of people still active in the channel with a previous social contract.

To guide our existing customers, I built another bot: this one was a little less discrete. For every new question that showed up in Slack, it posted a response suggesting the user redirect this question to a support channel.

We sweated the details of this bot's message and tone. It had to be polite, sufficiently firm, and also provide reasons why we were making this change. For example, the bot responded to a slack reaction that's used company wide to positively promote the value of better documentation. We also included an escalation path for the truly rare request that needed urgent intervention: while the chances of needing to hit this button were extremely rare, it gave customers peace of mind in knowing that a short circuit still existed.

We called this bot the Paste Concierge. It launched two months ago and we paid keen attention to how customers might react to it. Our largest customer persona (front-end engineers) took to the GitHub model easily. However, it took a while to convince designers and other users to sign up for GitHub just to engage with the system. We held firm with this new support model, and here’s what we’ve observed so far:

1. Slack support requests have dropped from 20+ a day to ~1 a week. Some of these are redirected to GitHub, but others are managed directly.
2. GitHub discussions did not proportionally increase to 20+ a day, which was a net-win for ticket deflection 🎉. One hypothesis for this is customers are more willing to try a few things out if the immediacy of Slack is not available.

While the Paste Concierge clearly helped, there's still more work to be done with design system support at Twilio. In the year ahead, we hope to:

• Make support more conversational, and less transactional: each support question should influence the design and direction of the system.
• Our conversations are still mostly public DMs, and not true discussions. This isn't ideal: like any design problem, involving diverse perspectives usually leads to better outcomes.

Closing thoughts

Perfect customer support doesn't exist. Also, there's no single or linear way to scale for it. Jennie Yip nailed it when she said:

"We don’t often talk about how much we get beat up being on a #designsystems team. The leads have to be strong + resilient to protect the focus of our team and for the system to be successful. I am deeply grateful to my passionate and empathetic team. But damn, some days are hard."

(Source)

The UX and UI that we ship is dynamic and changes with time. So should our support models. Healthy design systems respond to the world around them— whether it's making space to switch off when we're sheltered in place, time off for direct or political action, or surging for important deadlines like launches. In each of these cultural situations, consider the success of your support to not be about the answer itself, but the process in which your customer gets there, and how your team feels about it.