Let’s begin…

The success of a design system hinges on adoption—it’s a flywheel. The more it’s used, the more consistent your product becomes. High adoption also enables iteration at scale, making it easier to roll out updates, new libraries, or expanded component usage.

Below, I’ve outlined key actions (in rough order) to help you crush your OKRs. I’ve included insights from my time at Atlassian and links to helpful articles along the way.

What are OKRs

Already know this? Skip ahead.

OKRs (Objectives and Key Results) are a goal-setting framework that combines ambitious objectives with specific, measurable key results to track progress and measure success.

If your company doesn’t have OKRs then you could apply this same logic to your org’s goal structure. If you have no org-wide goal structure then I would establish that first.

Learn more about OKRs

Decide the type of your OKR

First, nail down which craft is driving the OKR. Aligning with the business early is key since success metrics depend on who’s leading the charge.

At Atlassian, we had an OKR to boost adoption of spacing primitives in code—but they didn’t exist in design (Figma) but auto layout was almost the same as a space primitive. So we focused on auto layout and spacing tokens, knowing they’d pave the way for easier adoption of spacing primitives in future design and developments.

Recommendation: Make sure your OKR is attached to both design and engineering. A design-driven approach can be tough—it's hard to guarantee that a spec in design will translate perfectly to code without engineering driving adoption on their end.

Defining your OKR

Tips on Objectives

Aim high: tie your objectives to top-level org goals. A bigger carrot 🥕 means teams are more likely to make room in their roadmaps. Keep it too ‘local,’ and it might get lost in the noise.

Nail the narrative: your objective should explain the why and rally support. Themes like productivity, modernization, or a brand refresh are great ways to drive org-wide adoption.

Tips on Key results

Set adoption targets—percentages are the most measurable since its easy for people to know 100% = good but the tooling can be costly to get set up.

As an aside, there are alternatives to percentage like satisfaction.

This is great advice from Davy and it could be an easier and more manageable way to get an organization to think about design system OKRs. Even though I don’t have experience with satisfaction, I would ensure that the business is comfortable using this as a metric over something like adoption percentage.

Now back to percentages - the rest of this article will be focused on percentage as a metric, let’s start with some KR tips:

Define your score: figure out what’s realistic for your org. At Atlassian, we aimed for 95% adoption of foundational elements (color, icon, text etc) —100% felt too rigid since there are use cases for custom things like user generated content (UGC).

Start with foundations: check the health of your basics—type, color, spacing. These are easier to track and should already be table stakes for near 100% adoption or high satisfaction.

Focus on what’s ready: don’t set adoption goals for things still in the early stages (like alpha)—I’ve made that mistake. Make sure your KR’s focus on robust features with clear migration paths.

👉🏻 If you need more OKR inspo, Elsa has written a useful article with examples

Scoping your KR

Be careful how you define adoption in your design files and codebase. Not every file or layer should count—some just aren’t priorities.

We’ve found it helps to narrow the scope. In Figma, we focus on ready-for-dev sections to skip the cruft. In code, we define specific folders or repos to keep the analysis clean.

Getting the data

Figma doesn’t have built-in adoption tracking, which makes gathering accurate, macro-level data on design system adoption tough. You’ll need to either find your own way to measure it or use an existing tool (listed below). In code I believe there’s more open source tooling to available and the process is more straightforward.

If adoption is going to be a big deal and is a high level OKR for you you’ll need to find the resources to prep your adoption data. If you don’t have to invest this heavily in the data, you can use the plugins below in Figma and/or code - it will get you there:

• SystemUp: Design and code adoption

• Componly: Figma and code adoption

• Design system adoption: Figma only

• Omlet: Code only

• or if you have the time/resource you can build your own

Accountability

Be careful who’s seen as responsible for increasing your adoption numbers. When you’re the sole owner of adoption metrics, the buck stops with you—and no one else will care as much since their performance isn’t tied to it. I recommend having each department define sub-OKRs that ladder up to yours. This way, they’re accountable and more motivated to drive adoption.

Traction

Adoption isn’t passive—it’s an ongoing effort. Once your OKRs are set and you have buy-in, don’t expect the numbers to rise on their own. Driving adoption takes work. Here’s how to build momentum:

• Write an announcement blog and share ways for teams to track their progress

• Focus on a multi-discipline initiative to make progress easier to measure

• Get sub-OKRs or stakeholders outside your team to report progress regularly

• Record videos explaining why adoption matters and its impact

• Integrate your numbers into the culture and design workflow

Moving the numbers

Now we’re getting to the heart of the matter. Effectively adopting design systems in both Figma and code can be tricky, especially with legacy experiences that require mass migration. Investing in tools to help designers and engineers scale this process is key—it removes manual work and ensures higher adoption. Without proper tooling, the effort is too high, leading to low adoption. Here’s what’s worked for us:

• Linting in Figma: If you have the resources, build your own linter. We trained designers to run this on each ready-for-dev spec before handoff. It catches unadopted elements early.

• Linting in Code: Create ESLint rules. These rules flag low adoption in the codebase, helping engineers stay aligned with the design system.

❓ Linting is the automated checking of your source code/design file for programmatic and stylistic errors.

Achieving sustained adoption

Adoption is a double-edged sword—you need to migrate legacy designs and experiences while ensuring designers default to the new standard moving forward. This means tackling it from two angles: clean up the past and lock in the future.

Some tips on how to achieve sustained adoption:

• Ensure the entire design org knows about your metrics and ensure engineers are bought into and pushing these numbers too

• Make it super easy and clear for both designers and engineers to know their adoption numbers

• In Figma, focus on getting all key Figma libraries and their code counterparts to the highest adoption levels, then work on project files

• Create office hours and a help channel to make it east for people to request extra support

• Make adoption a must have in all specs moving forward

Good luck!

I hope my experience and learnings help you on your adoption journey. If you have any questions or would like to share your own experiences, please comment on the web version 💚

🤙 Any feedback is much appreciated

Further reading