Successful design system teams need to build trust with two layers of customers. Internal customers are potential system adopters who want to be more efficient, competitive and generally happy in their daily work. External customers want products that are easy to use and add value to their day. But in order to bring that value, we’ve gotta build some trust in both layers.
You have to trust the belay to climb higher. Photo by Charis Deitemeyer on Unsplash.
Let’s talk about trust
Internal customers need to trust the system to prioritize adopting, updating and extending. They need to choose up front migration work over a rush to ship new features in the short term. External customers need to trust apps and sites to use them over the competition. It’s important to define the differences between these two customer groups while also looking closer at the connection between them.
Customer trust is especially important in the financial industry as products and services are used on a regular basis to manage finances. Finances enable people to live the lives they desire or prevent them from that same desire. The risks and benefits come with strong emotions both positive and negative.
Vicious (and virtuous) circles
Design system adoption and impact is either a vicious or virtuous circle, largely differentiated by trust. From what I’ve seen, there’s very little space for middle ground. Trust gets the value of the system into the hands of external customers, and broken trust stifles progress. The circles are paralleled by similar circles for external customers as they experience products and either build up or lose trust.
Vicious circle 😤
If an adopting team has bad experience using the system or getting support, they lose trust quickly. Because of that, adoption halts and that cycle will take a lot more effort to restart. Depending on how bad this experience is, they might even become detractors who can sway other teams away from adoption. Best case scenario, future adoption conversations will be difficult and should start by addressing that vicious history.
When the resulting product is shipped, it’s often disjointed, non-performant or slow to get fixed or enhanced. All of this degrades external customer trust and keeps us from being competitive in the market.
Virtuous circle 🥳
If adoption goes well, trust builds and the team is willing to upgrade and extend, which results in more trust. When done well, this is a continuous, virtuous circle. If things go really well, the team may even decide to contribute, make some bug fix merge requests or even champion adoption with other teams.
The resulting product is high quality, provides deep value and is easy to use. This causes a similar virtuous circle with external customers who enjoy a more trustworthy experience. We’ve built trust internally, which powers external loyalty and trust.
How can systems build internal trust?
Start with empathy to understand what is valuable to potential adopters. What are their biggest pain points and how might the system address them? It isn’t enough to make a strong system; the users of the system also need support, collaboration and guidance. This takes time and energy, and if it’s not clearly planned, bridges may be burned early in the adoption journey. Here are a few ways to build trust inside the company…
Build out in the open
When our design system governance model is visible, adopters will be able to challenge foundational thinking or have a better understanding of what to expect. Sharing the values that guide decision making will build trust with the community. This is why industry leading systems like Carbon and Spectrum share their guiding principles. Likewise, sharing roadmaps and objectives will help set expectations with the community and also give another way to gather feedback to examine whether design system priorities align with the biggest internal customer needs.
Build with quality
If it doesn’t work, people won’t use it. To promote a virtuous circle of adoption, make components and tools that work. I know, I’m blowing minds here 😉. Beyond working, the tools they system provides have to enable new ways of working that are startlingly better than the past. Teams should reach new levels of efficiency and innovation by using the system.
Accessibility is a great lens to look through. Teams can meet each new WCAG requirement much faster if they’re building on a deeply accessible component set. Updating a component package and retesting is much faster than having to do the ongoing maintenance on the components themselves (if we’re doing our jobs right). Build trust by providing the fastest path to all forms of compliance.
Build with the community
Even if your system is totally centralized to a single team, the community needs to be involved in shaping requirements and informing roadmaps. Common support questions can shine a light on missing documentation. Components that are being reused outside of the design system indicate gaps to be filled. Workshops and reviews can easily include the right stakeholders from across the organization. Build the system together to make adoption easier, more enticing and even addicting.
Beyond creating feedback loops in component sprints, design system teams can also take an active role in formalizing the governance and quality standards of reusable things built on top of the system. Often, it’s not realistic for one team to own the design system from the ground all the way up to higher levels of complexity. Owning form components is realistic, but owning templates for application flows might present a few problems. Larger flows often need to be iterated quickly based on feedback and usage metrics, and that happens more smoothly in product teams freed from the burdens of library maintenance. The system team can multiply their impact by setting the community up to build on top of the system and share effectively. They can quickly grow the larger reusability ecosystem by teaching, sharing templates and giving consultation to help teams create reusably.
Build by demonstration
As creators and experts of the systems, we’re the right people to show how the system works. This can look like training sessions to roll up the sleeves and apply the system together. It can also look like workshops to help teams size migration work realistically. The team might also create a proof of concept to illustrate how quickly building goes and how much coverage the adopting team can expect in their specific product.
How can systems grow external trust?
To put it simply, to pick us, you have to trust us. It’s true for any digital products. Because every app has competition, trust is important no matter who you are. If an app changes interaction patterns, lacks consistency or is generally hard to use, people will struggle and trust will degrade. It might be hard to measure, but design systems can have direct impact on building external customer trust. Here are a few ways to grow external customer trust through the design system…
Grow with durability
The system should provide the right building blocks to make durable products. Again, accessibility is a great example. Solid building blocks help make things work as expected for users of assistive tech like screen readers and anyone who prefers navigating a form via keyboard. In many cases, better accessibility means a better experience for everyone. Building accessibly from the ground up might be invisible to most users, but the benefits are widespread. Durable systems can stand up to the rigor of assistive tech and user settings to deliver experiences that are tailored to the individual.
Grow with consistency
Through token systems and partnership with brand teams, design systems can also bring a company’s brand to life faster and in richer ways. Again, the visual brand application might not be noticed outright by a large group of the audience, but the subconscious impacts build trust. If buttons change size or shape unexpectedly, an external customer might not notice the exact detail, but they’ll smell something wrong. The same is true for consistent voice and tone and broader patterns. Inconsistency causes an uneasy, microscopic pause to figure out if a link went to a new site or different product. Consistency causes comfort and a deeper state of focus.
Grow across device types
When it comes to supporting multiple tech stacks, teams can face nitty gritty questions about product strategy. Design systems provide a way to make those decision once, and canonize them. These types of decisions become the foundation of a strong system. If that decision is not formalized and documented, it will be repeated with differing results. To the external customer, the resulting experiences will feel like they came from different teams with different marching orders. No surprise, this degrades trust.
A team might decide to make things more custom to align directly across web and native. Or, they might choose to reduce custom work to take advantage of what an operating system provides. Both approaches have their merits. Either way, this strategy needs to be defined once, documented and acted upon consistently to avoid the bad kind of chaos.
Trust is a result, not the root cause
Who or what do you trust most in your own life? Probably the people who have been there for you without fail. Maybe a few of the products that work consistently and make your life better or easier. Just like any relationship, positive experiences and consistent action build up a strong track record of trust. But negative experiences and a lack of action degrades trust.
Trust is really a result of a system or product that can be depended upon. If a system team is struggling to grow adoption or wants to change community behavior in any way, they have to start by building empathy with their community. Find the opportunities to show up for your community and demonstrate dependability. If we connect the system to the needs of the community, we can improve work lives and shape more competitive organizations.
This article is based on a conversation I had with Michelle and Tim on the Beyond the Button podcast with Zeroheight. Thanks team! 🤗
Building customer trust with design systems was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
