On Design System Support

Having a Support Mindset

Overview

We spend a lot of time supporting teams, and I think it’s one of our design system’s biggest strengths. Specific processes often are tied up in institutional contexts that don’t translate well, but I‘d like to share a bit about having a support mindset as a Design System Engineer. Having great support is one of the key reasons our design system engineering team has been so successful at Workday. We listen to developers, we understand their concerns, and when they need help, we take care of them. I thought of four key aspects that drive how we think about support.

Side note: If you were hoping for information about processes, you won’t find much here. But I don’t want you to leave empty handed. If you haven’t read Nathan Curtis’ post on Design System Support, I’d highly recommend it.

We Start with Empathy

Imagine you’re a developer.

You’re using our components, code you didn’t write, to build a new feature. Maybe you’re familiar with our library, maybe not. You’ve tried to make it work on your own, but something still isn’t coming together. Maybe you’ve read the docs, looked at our source code, but you’re still stuck. You had dreams of being productive during your heads-down time today, but this is a blocker. You finally reach out to the design system support channel, and hope someone can help you sort through it.

Starting with empathy means we start by thinking about how a developer got to the point of asking a question. We understand that feeling. And now we have an opportunity to turn a confusing, frustrating situation into something good where they feel supported, productive, and maybe learn something new along the way.

We Celebrate Questions

Our support channel is our primary catch-all for teams. It provides a safety net when our design system docs, code, or specs fail our consumers. Maybe we omitted some key material, or made a bad assumption, or created a counter-intuitive component API. Our support channel provides a bit of coverage for those problems, but it only works if people reach out. If they don’t ask, they’ll resort to either hacking something together, or building something from scratch. Either creates more work for everyone down the road. We want to encourage people to reach out and ask questions. And when they do, we want to make sure they know we appreciate them asking.

• You found a bug? Thanks for raising that!
• You don’t understand the docs? Appreciate the feedback!
• You don’t know how to build with our components? Let’s work it out!
• You created a sandbox and filed an issue? You absolute legend!

Giving people a small nudge encourages more of the behavior we want and helps us build a more sustainable system. They made the right choice reaching out to support; let’s be their biggest fan.

We Build Community

Support is about more than answering questions — we’re building a community around our design system. Part of being connected to the system means teams have access to our docs, design specs, and code that they would otherwise have to create and maintain themselves — that’s huge on its own. But it also means that when they have a problem using our system, we have their back. They’re a part of the tribe along with all our other consumers, and we have a collective responsibility to make sure everyone succeeds. One of my favorite things to see is when teams help each other work through problems together. Support resolves individual issues, but it also continuously reaffirms this pact we have with our consumers.

We Work on Two Levels

As systems thinkers, we handle support on two levels: addressing the immediate concern, and adjusting the larger system forces that caused the issue. How we go about both is important. An example might be helpful to illustrate:

Over the past two months, several developers from different teams have raised questions about how to customize icon colors

The immediate concerns are:

• Understanding their use case
• Verifying the solution makes sense
• Showing them how to customize icon colors

The larger system concerns could be:

• Assessing how well our docs explain how to customize icon color
• Updating our component to make icon color modifications more intuitive
• Understanding why product designers are opting for custom icon colors

These two processes often begin concurrently, but they are handled very differently. Consumers will likely only care about the immediate concern, and it’s our job to resolve that efficiently. But we also have to think about the larger system concerns if we want to create a more sustainable system.

Addressing the Immediate Concern

This is always our immediate focus. Someone is blocked, or feels blocked, and we need to figure the best path for them to move forward. Whatever questions or objections we have about the larger system forces that created this situation are irrelevant to the person currently stuck. That said, once you understand the issue, it’s always good to pause and ask whether this should be done instead of rushing into solutions for how it could be done. Developers are often the last to know about what’s coming down the pipe, and sometimes they get stuck having to implement unfortunate product and design choices. Sometimes to be supportive, you need to hold your nose and help a developer through that less-than-ideal situation. But there are a few hard stops:

• This would create an inaccessible or non-inclusive experience
• This would create something completely divergent from our design system
• This would create serious technical limitations for other consumers

Outside of those situations, our job is to find a way to resolve the immediate issue efficiently, in a way that aligns with our standards, and creates the least amount of technical debt for that team. Once you’ve resolved the immediate concern, you can raise larger concerns that created the issue with that team.

Addressing Larger System Concerns

Almost every issue has at least one larger system concern behind it. While you need to somewhat ignore it to help someone move forward, you can definitely use back channels to highlight the issue as an anecdote for a larger, internal conversation. Addressing bad system behavior with a system-level solution is more effective, but it also typically takes much longer to resolve. Think of this as a non-blocking, asynchronous process. We can start the internal conversation now, but we don’t want it prevent a team from having resolution, if possible. We have the ability to shift the system, they have to work within it and deal with it as it exists today.

Conclusion

Your design system will likely never be in quite the shape you or your consumers wish it was. Great support systems can be a safety net to cover those gaps and help teams feel supported. My experience has been that processes always evolve with your system, but having a support mindset is a constant.

Thanks for Reading!

I wrote this to help solidify my thoughts, but I hope it was helpful for you as well. If you enjoyed this, you might also enjoy following me on Twitter.