Design system success through empathy and intention

Think back to all your working relationships with designers or developers. What did you all accomplish when the relationship was great? What about when the relationship was strained? How well a designer and developer teams collaborate can make or break a product. This is significantly more critical when scaling a design system for adoption.

Empathy and understanding other people’s intentions regarding the design system are just as important as ensuring the components are designed and coded.

At the core, it’s about establishing and fostering trust. When you trust someone, you believe they’ll keep their word and can be relied upon. Building that trust doesn’t happen overnight, and it might be harder to do if previous experiences eroded that trust. While building trust seems daunting, it doesn’t have to be. Taking a small step and building off that can quickly build momentum.

Here are a few ways you can start building trust that has worked for the teams I’ve been a part of.

Get to know each other as people.

If you’re in-person, going out for a team lunch is a great way to get to know your teammates better. Talking about things outside work is an excellent way of learning about a person and finding things in common. When you find commonalities, you start to build some trust.

If you’re a distributed team, you can still gather virtually. You could host a team lunch/breakfast/dinner (depending on people’s time zones) and make it purely social. Ideally, the company can cover everyone’s meal. If your teams are large, consider creating breakout rooms of 6 people or less. This will allow for better conversations.

Socializing might not be everyone’s priority, so you might need to ask management for support.

Once you’ve met, continue nurturing the relationship to help establish trust. You can try other ways of engaging teams. For example, you can host a game hour (Gartic phone is a favorite), try hot sauces, or participate in hackathons together.

While this path to building trust might feel slow, it does work. At a previous org, our design and dev team went to lunch together every 2-4 weeks. And despite it being awkward at first, we all looked forward to these lunches. Those connections ultimately paid off in the long run. Later on, we were on several chaotic projects but knew and trusted each other for us to weather the challenges together.

Understand intentions by building empathy

It’s easy for people to make assumptions based on previous experiences or our own biases. However, not all our beliefs are true. If you’re a designer building trust, it’s helpful to understand what developers need or are looking for and vice versa. This understanding allows everyone to help each other come up with solutions that benefit everyone.

Building this understanding is a lot easier than you think. One exercise I like to conduct is the “Pains and Gains” mapping activity from Gamestorming. With this activity, you’re asking the different roles of what makes them successful (gains) and what stands in their way of success (pains). You might hear some stuff directly related to design system work, which you might be able to change or influence directly. Sometimes, you might hear of things unrelated to or adjacent to what you do. You’ll often learn something new that corrects your assumptions. This context helps you understand how your work might impact their bigger picture. Are you helping them succeed elsewhere? Or are you increasing friction or adding more to their plate?

If you want to take things a step further, you can host a workshop to understand their pains and gains more deeply. For example, you might want to see if the design system documentation is helpful for developers. You can ask them to look at a few screens and provide feedback on:

• what’s working with the content
• what’s not working
• what’s missing, and
• what could be improved to make their work easier

This is also an excellent opportunity to understand the full context of how things on their end work. Years ago, when we delivered more static designs and had to redline our work manually, the design team combined all the redlines – spacing, color, typography specs, interactions, and localization examples into one design. It was difficult for the developers to parse out the information. We could ask them what they think about coding designs and why. This was a tremendously helpful context and allowed us to determine that we needed to organize our redlines into separate sections to allow developers to focus on one task at a time.

Build with intention

As you listen to your design system’s contributors, viewers, and maintainers, make sure you’re making decisions with the right intention in mind. This means thinking about decisions before jumping in and making the change. It might also mean asking for feedback before implementing anything. And most importantly, it’s considering the feedback you heard and creating improvements based on that.

The power of empathy and intention

Demonstrating how we were open to feedback, willing to improve, and following through helped establish more trust. This benefitted us as we scaled our design system to the broader organization. The design system team had a good track record with development, so getting buy-in and working on workflow and product changes were easier to do as we were scaling.

If you’re having trouble having productive design system conversations, adoption, and buy-in, try building empathy with your peers and understanding the intent behind their work. It might not get you to a quick solution, but it’ll help pave the way for (re)building and establishing trust.

Where have you struggled with building trust? What have you done to improve having empathy for other designers and developers? Are you having trouble right now? Consider joining zheroes, our zeroheight Slack community! We’re a friendly bunch, always willing to help people navigate their design system challenges.