Beyond adoption — Using data in the design system lifecycle

In just the last year we’ve talked to hundreds of product teams at different stages of their design system journey. And in Omlet’s earliest days (like way back in discovery phase and beta), we were really focused on the challenge of surfacing data around design system adoption. Fast forward to today and that’s one of several ways teams love to use Omlet — to measure and track adoption metrics across their codebase.

As we learn more from our users, though, and also from design system leaders at Optimizely, Thomson Reuters, and Workday, just to name a few — it’s clear that design system data isn’t just about measuring adoption.

Data plays a role at every stage of the design system journey — starting from when you decide to build your first components, all the way to when you are retiring a design system and creating a new one. Omlet is useful across these stages, too.

In this blog post, I’ll talk about how teams at different stages of the design system lifecycle are applying data to solve their problems. In addition, I’ll highlight how you can do this in Omlet today.

Build Phase

We’ve all been there. Building something from nothing can be daunting, and the same goes for starting a new design system or component library. You want to make sure that it’s not built in a silo, but how do you make sure you are considering your company’s existing and future needs?

One way to approach the initial design system build phase is by first auditing your entire product and identifying existing patterns, which is what Hubspot’s product team did with Canvas, their new Design Language.

Heather Taylor, UX Designer at Sparkbox, describes a similar approach in her article Auditing as a First Step to Design Systems Planning. In it, she gives a step-by-step walkthrough of how her team decomposed a website to identify and organize elements for future use.

These examples demonstrate how to leverage your product’s historic and current data to validate future decisions. This same idea of layering data into your build phase is one of the top use cases we’ve seen among teams using Omlet:

• For teams with a design system, Omlet helps you audit components used in your code and customize your audit analyses in multiple ways, so you have the data you need to validate design system decisions.
• Even if you don't have a design system yet, you could set up Omlet to scan your production codebase and start getting audit insights to support any kind of production build or codebase improvement.

How to use Omlet in the design system build phase

We’ve found that when teams analyze their component usage with Omlet, they’re not just looking for a high adoption percentage (a way to check the box “yes”, the design system is being used). They’re also using it to tease out broad usage patterns across their codebase so they can choose the right next components to build.

For instance, in Omlet, you can quickly find out the most frequently used components in your entire code base across multiple repositories, and also search for components with similar names to identify similar patterns.

You can also drill into exactly where these components are used through the dependency tree view and view prop usage information so that you can understand what use cases your team is using the component for. Now, if you decide to create a design system component, you have a better view of how to design and build it.

Adoption Phase

If you’ve designed and built your design system components with your teams’ needs in mind, adoption should ideally come naturally. But we know ourselves, and also based on our conversations with design system teams, that adoption isn’t that simple.

Even if you tailor your design system to your team’s exact needs and there is some early adoption, the truth is that design system adoption isn’t a static measurement.

There will inevitably be a stream of releases across your design system, and this means you have to think about more than just “are people adopting the design system?” You have to also ask yourself things like:

How do I encourage my team to re-adopt components when they’ve been updated? 
Which teams are adopting which components, and are there any concerning trends? 
Why is adoption trending one way or the other? 
If teams aren’t adopting certain components, what are they doing instead?

You can use Omlet data to answer these adoption-related questions and drive decisions around two activities that relate directly to them: replacing similar components and migrating away from legacy or deprecated libraries.

Replacing similar components

Let’s say you’re looking into what components your teams are building as part of your design system work. Sometimes, you’ll come across new components that are notably similar to the ones in your design system, which leads to a couple of potential scenarios:

• The design system should have been used instead: When your team has created a new component and its clear they should be using a design system component but aren’t, you can reach out to them to investigate why that is and make recommendations to replace it.
• The new component intentionally deviated from the design system: You might find that your team has created components that deviate from the design system, but did it intentionally for experimentation purposes, or to achieve a specific use case. Rather than thinking of these as cases of non-adoption, you can use these customizations as input for how your design system can evolve and improve (we’ll talk more about that later).

Omlet gives you the data for both scenarios out-of-the-box. Omlet spots all recent component activity in your codebase — not just design system components — so you can quickly check what these recently created components are for and how they relate to your system’s adoption.

For many teams, replacing and migrating components go hand-in-hand with how their teams manage requests for new features and components. Andrew Holloway, a Lead Design Systems Engineer, is close to this process and finds that there’s a place for using data, particularly Omlet’s insights, both at the beginning of the process and well after.

Migration

You’re not always going to be starting a design system from scratch. More and more often, you’ll need to deprecate or replace legacy libraries or existing components with your new design system, and that’s really what many product teams are facing right now.

We talked about this in more depth at our recent panel, How design system leaders measure and boost adoption in their codebase, where Dan Mall pointed out the misconception that migration should be “all-or-nothing”. Instead, it’s more about prioritizing what’s most important for the business at a given point in time.

With Omlet, you can be more confident about your migration plans, and also better predict how much effort they might entail. Simply tag components that are part of a legacy library or deprecated components and look at how often they are used.

Using this data, you can then more easily assess and estimate the actual work required to complete a migration initiative and secure the appropriate resources to achieve your goals.

Continuous Improvement

Hooray! If you’re able to get adoption of your design system and see real impact on product quality and production speed, that’s cause for celebration. However, you can’t really celebrate for too long.

As we said before about adoption, your design system is not a one-and-done project. This idea really hits home for Henry Daggett, Design System Lead at Societe Generale, and it's shifted the way he and his teams think about their design system’s growth.

A strategy we’ve seen becoming popular among design system teams is creating a feedback program. The most common methods of feedback we've seen include regular surveys for design system feedback and requests, recurring “office hours”, and even an internal channel or forum dedicated to the design system.

But a challenge that both Alan B. Smith, Design System Developer at Workday, and our own Berk Cebi, Co-founder of Zeplin and Omlet, have observed is that sometimes these methods are geared too much towards the most vocal or active people. These may not be the folks whose input is most critical to drive design system improvement, such as those who are lagging behind in adoption.

How Omlet helps with continuous design system improvements

Here are a few ways our users use Omlet’s component usage data to continuously improve their design system over time:

1. Assess the impact of an update: When planning to change or delete a component, data helps you better understand its dependencies so you can assess the potential impact of that change. This objective visibility enables you to make more decisions more confidently.
2. Detecting and removing unused components: By tracking component usage, you can find unused or obsolete components and safely remove them, thus reducing code bloat and improving overall maintainability.
3. Simplify a component’s prop interface. Low or unused props are great candidates to deprecate to simplify the interface of a component. You can also catch unusual values used in a prop to uncover unmet use cases.

About non-design system components…

When you’re driving the success of your design system, it’s natural to want to focus on the design system components themselves and their usage. But the design system represents only a part of what your applications are built on. That means you can get a lot of value from analyzing your non-design system component usage, too.

That’s exactly what Daron Adkins, Staff Software Engineer at SageSure, and his team do as part of their design system strategy — they rely on Omlet’s component analytics to achieve broad visibility across their design system and non-design system components to drive continuous improvements.