Measuring the ROI of a Design System

So you’ve successfully made the case for implementing a design system at your organization. Or, maybe you’re still building that case and know you need a way to prove the value in order to maintain support and funding for your design system team. Here are some methods for getting data to prove the value of design systems.

Start with User Journeys

In order to start measuring the impact of a design system, you’ll need to create an audit of your current user experience. Hopefully, your organization already has a shared understanding of your users and their jobs-to-be-done (JTBD) that has driven the creation of user journeys. If not, you will need to create user journeys in order to audit the fragmentation of your current experience to get everybody on the same page.

a user journey by Mad Pow
An example user journey by Mad Pow

Collect Analytics

Implement a granular analytics tool such as Heap that allows you to track targeted experiences as your users move through your product. This will give you a baseline understanding of their time on task, abandonment rate, and other indicators that they are having a poor experience with your product.

decorative - Heap dashboard
A Heap dashboard

The Three Elements You’ll Be Measuring

Essentially, there are three main benefits to creating and using a design system: consistent experience for users, consistent design patterns for designers, and consistent code banks for developers (See my previous article on why implementing a design system in your organization is a great way to tackle many challenges facing design and development teams). You can measure each individually to demonstrate the ROI of your design system.

Consistent Experiences

The primary market driver for adopting a design system is the promise of a consistent experience for users. The user journeys your team has documented and the dashboard of analytics on the efficiency of that user journey are your KPIs and OKRs for measuring the impact of implementing a design system. If you’re using A/B testing, implement one experience using the design system and one using your old code and test the time on task, time to completion, abandonment rate, and other indicators of task success.

a CES survey with emoticons. "how easy with it to complete your task today?" with smiley faces for easy and frowny faces for hard
A CES survey with emoticons from Grohawk.

Depending on the experience, you can implement a CES (customer effort score) survey for an indicator of customers’ happiness with your product before and after changes. Brag a little by socializing gains in that data in your organization to increase buy-in.

Consistent Design Patterns

The second benefit to having a design system is providing consistent design patterns to your designers. As your design team grows, you’ll realize it’s no longer viable to conduct design reviews of every project. At that point, you’ll need to provide teams with in-depth documentation on how to use to the design system independently.

For instance, if your designers want users to filter e-commerce products, are they using pills, checkboxes, a multi-select dropdown, or search? Without a Creative Director, Experience Design Director, or other design leadership oversight on their team, the patterns that your designers choose will become a bit arbitrary and the experience will become fragmented despite having the molecular components all look the same. This actually produces a worse outcome for your users, since they’ll learn one interaction pattern in one part of your site and another interaction in another. The gains in usability that you made teaching them how to use your components on the one hand will be undermined by conflicting usage patterns on the other. Do your users and designers a favor and provide a mapping of components > design patterns > user actions. A design system is more than just molecular components. It requires documentation on design patterns and how they map to users actions in order to be truly effective. The documentation you provide in your design system should help them understand when to use which component.

If your designers are part of an Agile development process and using a tool such as Jira or Agility to track projects, you can gather information on how long the design phase takes your team. Even if they aren’t, you can measure the effectiveness and efficiency of your design library by conducting an internal survey. Even the perception of efficiency can be a huge boost to morale and job satisfaction.

Consistent Code

The third main benefit of leveraging design systems is providing consistent code in a code repository that developers can quickly implement in products. There are two ways to measure the efficiency gain of your design system:

  • measure the time to complete tickets of similar points before and after implementation of your design system on a team
  • measure the number of bugs reported for a design system experience vs a similar non-design system experience

Design Systems Need Organization Support to Continue

The longer your teams use design systems, the greater the efficiency gains. It is essential, however, that your organization supports the effort. If they’re seen as additional work on top of normal work, or if they’re not mandated by engineering leadership, they will eventually lose momentum and stagnate. Designers’ and developers’ time will need to be dedicated to working on components and documentation. Your organization will need to set up a tool such as Invision’s DSM or Lingo to manage the documentation and link to your code repository. And finally, your organization will need to support it by providing governance on such topics as whether to make it product agnostic, mobile-first, WCAG-II or III compliant, and which teams are required to adopt and use components.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.