Immediately, the community used it. And, immediately, they needed help.
What kind of help? Oh my goodness did those requests fly! Fix your defect. Add a feature I want. Answer my question. Approve my proposal. Set up my files. Train us. Review that we used the system correctly. Link our library. On and on and on. Over eight weeks, 100+ incidents (or cases, in tech support speak) inundated the team in Slack, email, tickets, and more.
Gulp. We hadn’t anticipated the demand. Cases felt unceasing. Responses flew haphazardly. It was all quite chaotic. We figured it out, and we gained our customer’s trust. And, along the way, I learned a lesson.
Design systems must be ready to resolve emerging and at times urgent needs of designers and developers. This requires upfront investment in process and ongoing commitment that isn’t handwavingly trivial. Instead, a design system team must understanding and what types of cases it supports, in what channels they arise, and who’s responsible to manage and resolve each via a well-defined workflow.
Support is a concept interpreted in many ways. Two come to mind: “What are our supported browsers and devices?” (features) and “Do we have enough people on our core team to support the program?” (team capacity). For this article, I define support as:
The direction is inbound and the relationship usually individual, triggered by someone who needs something and expects a response from the system. This distinguishes support from outbound efforts that enable customers like communications, adopter outreach, governance and training events.
Design systems always resolve cases when a designer or developer needs to…
These needs—and expected system response—is immediate. Lacking understanding or a defect may block someone from getting work done. If a system team isn’t responding to such needs, it strains the relationship and erodes trust.
Other requests require more deliberation, such as:
Here, customers need to know “What can the system do, by when?” rather an immediate outcome. While these requests aren’t thought of as “support,” they do flow through support channels. As a result, a support workflow will triage and route each to be declined, activated or settled into a backlog.
Finally, support often invites more generic interactions, such as:
Support cases originate from sources formal and informal. Design systems typically promote formal paths in documentation and communications like:
Support requests arise informally, too, amid interactions between system team members and those throughout a community. Encountered by any team member, they include:
Takeaway: Be thoughtful about which channels to open and monitor, and don’t support too many. For formal channels with high activity, optimize data collection, response time and response quality. For informal cases, ensure staff can put requests in the right place and gather just enough information to move things forward.
As a result, many requests are more “How do I do my job?” and less if at all “How does the system help me do my job?”
Such overlaps distort expectations. Should the design system team answer any question about Sketch, React or Angular because support other teams? Opinions are mixed, but my willingness to offer a helping hand has grown over time. This is consistent with creating a collective, nurturing environment and building trust in the system program. However, I’m also at the ready to admit “You understand your context more than I do, and I’m not informed enough to give you good advice.”
Takeaway: Be prepared for questions that are outside the scope of simply using a system. Depending on your capacity to do so, consider offering a helping hand as much as you can. However, know your role. Establish reasonable boundaries and expectations of what the system is and isn’t there to help with.
I’m not an authority on customer service workflow. That said, for design systems, I start simple and refine over time how a team intakes across channels, triages and routes requests responsively, and flows the work into existing scrum / kanban workflows as needed.
Not every case needs to be formally tracked, and many resolve immediately. An answer in a meeting, a quick Slack chat, a rapid email. All are best resolved quickly and informally. This means no heavy form to complete, no new ticket to track in Jira, no notifications when resolved.
However, these “immediately resolved cases” are still support. The work demands attention and takes time away from other tasks. To ignore this effort is to ignore what might be consistently 20% or up to 50% of designer or developers job day-to-day.
Takeaway: Make easy-to-resolve interactions light and effective, resolving each with no loose ends. In doing so, don’t ignore—instead, recognize and plan for!—the time staff needs to handle these conversations properly.
Not all cases require an immediate response. Sure, a system should be able to rapidly release fixes, respond to feature requests and proposals “in the flow” of work. But not every case warrants stopping everything and getting whatever they ask for done. Customers may have unrealistic expectations about how a system prioritizes their needs. Imagine a request like:
Um, no. That’s not how most systems work. Instead of scrambling to respond to and resolve that demand, a response could be:
Design systems play the long game, incrementally adding features relevant for everybody by collaborating with everybody. A responsive support workflow shouldn’t be confused with a willingness to rapidly release complex features on a day’s notice.
Takeaway: Gauge how much your design system is coupled or decoupled individual and imminent product delivery to production. Generally, the larger and more diverse an adopter ecosystem, the less likely the system team is release features or even fixes to douse a single customer’s fire.
When a case isn’t resolved immediately or is submitted independently, you’ll want to collect the right—and just enough—data. Prioritizing, managing and resolving a case is made easier with:
For defects, you’ll also benefit from:
For feature requests and contribution proposals, don’t go overboard. Keep it light and deepen afterwards through conversation and transitioning it to formal inquiry (such as a [DISCOVERY] task). Here, questions could include:
While you could collect so much data, avoid making things complicated. Forms with useful but onerous inputs, task templates, and specialized properties in task management software to improve data consistency yet also increase a submitter’s effort. Additionally, autoresponders to forms and incoming emails can ensure requesters feel heard, set expectations, and point to helpful materials but can also feel noisy.
Takeaway: Identify what to collect and where to track it. Collect only essential data and be resilient to missing data.
Habits across teams vary. However, most teams route cases into project management rituals and tools, like:
Ensure you’ve identified that place place and monitor it routinely. For teams with sufficient capacity, there’s people assigned to triage and assign cases in real time as they flow in during business hours. Other teams wait to discuss and assign cases in regular ceremonies like daily standup or—at most—biweekly planning.
Systems earn trust by responding quickly. A first response of “We heard you, we’re working on it” is different from “Your case is resolved.” At a minimum, the requester should feel heard and trusts that you are on it.
Feedback from design system colleagues indicates that most design system teams promise to respond in a day or less.
I encourage teams to reveal a response time — the “service level agreement” (SLA)—in formal support channels. Advertising a SLA shifts a team to take support seriously and orient capacity to meet that commitment. Teams unprepared for support omit an SLA at their own peril, and this can’t last forever. A refusal to fluidly support your customers is a terrible signal to send. What tool(s) should we use? Scale tools to suit demand.
System teams often mature through three or four stages of growth:
Most established teams end up in task management software like Jira, while those handling a high case load turn to tools optimized for their scale.
Takeaway: Systems built to last include tool(s) to manage support tasks and integrate and make visible those tasks on a daily basis. A spreadsheet managed in solitude on a shared drive isn’t enough for large-scale efforts.
Larger system teams benefit from project managers / scrummasters whose job it is to route tickets and manage workflow. For system teams not at that scale, designers and developers are saddled with the responsibility. Whether junior or senior, such practitioners tend to be less interested in triaging and routing support tickets than their core mandate: design and code.
So who should monitor support channels, triage requests, and route assignments? Different design system teams take different approaches:
*A single person. Whether a lead, project manager, or practitioner, a single person may be responsible. Their day-to-day routine may be to monitor chats, inboxes and form submissions, and trigger the workflow as a result. The tradeoff here is efficiency and decisiveness with “single-point-of-failure” for responsiveness if busy with meetings, out sick or on vacation. *A defined subset of the team. Usually pairing a lead and project manager or practitioner, there’s few enough cooks in the kitchen that coordinate who owns what is easy via backchannel chats and st andup. *Anyone on the team. Should anyone respond to anything? While more responsive, it can miss cases, lead to chaos and requires consistent answers and workflow across many people.
Decomposing the challenge a bit more, does everyone monitor Slack but designated individual(s) monitor an email inbox and ticket submissions?
Takeaway: Most bias towards using an entire team or a defined subset. My experience suggests that formal channels benefit from a single person accountable to route cases and ensure each resolves. On larger teams, everyone can’t do everything. So chalk up my vote for balance. Align a few to operate the workflow, coordinate in the backchannel, and unburden the rest of the team. Also, consider making support triage an impermanent tour-of-duty so that team members rotate and don’t get burned out.
Some designers and developers relish back-and-forth problem solving and the connectedness provoked by support. They welcome bouncing in and out of resolving requests. Positive vibes emit from their pores as each interaction accumulates the intrinsic reward of helping others.
Others? Nah. Not so much. First, not everyone can bring the patience, curiosity, and positive attitude needed. Also, many find context-switching disruptive, friction-filled, and far from the designing, coding and documenting they enjoy most. I’ve seen team members assigned enough support work that they unexpectedly leave a team. That’s sad and avoidable. Support isn’t for everyone.
Takeaway: When starting support and preceding assignments, consider frank and individual discussions with each person. You can cover topics like preferences, comfort level, flexibility, attitude, confidence, and capability. Once you are confident they are the right person for the job, away you go!
If more than one person can respond (usually in chats like Slack or Teams), then two or more staff members may swarm to respond simultaneously. This sometimes works, and certainly signals you care. Yet, swarming risks crosstalk, splayed directions, and conflicting advice. Avoid overwhelming those in need, align answers, and coordinate activity when one respondent suffices.
Takeaway: Telling some team members that they can’t or shouldn’t talk to customers is a signal to avoid. Instead, establish expectations that team members coordinate in a private backchannel before inundating a requester with feedback.
Confidence and authority matter. While a design lead may be more knowledgable of brand and organizational nuance, others lack that context. A tech lead knows how to balance constraints, frameworks, and approaches; other developers lacks experience.
Takeaway: Incorporate moments to review responses prior to sending.
Tools should permit visibility and collaboration between a requester, responder, and those managing the process. A less structured Jira board visible to all three participants is better than a spreadsheet or souped-up ticketing software only accessible by a responder alone.
Takeaway: Most system teams lack the scale to need ticketing software. However, a dependable case workflow through assignable and measurable task management is a hallmark of operations that take support seriously.
EightShapes can energize your efforts to coach, workshop, assess or partner with you to design, code, document and manage a system.