ABCDEFGHIJKLMNOPQRSTUVWXYZ
1
Thanks for your interest in The Question!

Sign up to participate in future questions here.

This file is the raw data from Episode 9, deep dive hosted on Jan 25, 2024 with Noelle Lansford.

There are 55 answers. The question this week was:

-----

Noelle and I have both been doing a lot of thinking about what it means to have a person or team adopt a design system. The way I hear it used, the word “adoption” could be replaced with the word “usage” most of the time—adopting a design system is using that system. But if that’s all it is, then why do we call it adoption?

Here are three definitions for the word “adoption”:
• “the act of legally taking a child to be taken care of as your own”
• “choosing or taking something as your own”
• “accepting or starting to use something new”

Now we’re getting somewhere… Looking at these, it’s pretty clear that adopting could certainly mean more than just using it. These definitions include “accepting” it, maybe even “taking it as your own”.

With all of this as context, here is the week’s question:


Are you confidently tracking the adoption of your design system?

If you answered “yes” tell us how you do so and how your adoption is going. If you answered “no” tell us why and share a bit about what you’ve tried.
2
Question 1: Are you confidently tracking the adoption of your design system?Question 2: If you answered “yes” tell us how you do so and how your adoption is going. If you answered “no” tell us why and share a bit about what you’ve tried.
3
YesDesigners and Engineers are contacting the Design System Team for advice, help, and contributing new code components.
4
YesCurrent DS is supporting a single product currently and so it is easy to work with, track, and collaborate with the team using it. It’s also being mandated at a C-Level that all products must use it moving forward so as we scale to other platforms we anticipate full adoption. But with a smaller product org for this one, it’s doesn’t require large tracking methods.

In the past we’ve used spreadsheets and manually tracking for some of the larger global enterprise organizations, although only tracking who was using, not who was not.

One note regarding meaning of adoption is that we always run into confusion between the difference between integration of the DS vs adoption. We defined that through proper integration of the DS you would then adopt the system. That distinction has helped in conversations, especially with development teams and product leadership. Teams sometimes thought that by styling it like the DS they were adopting so we had to clarify that was not adoption.
5
NoLimited visibility with the codebase.
6
NoWe are currently in the build phase for our DS so its something we are looking into but havent yet understood how best to get it done. Mostly we would be looking to track more the definition of usage as well. Since the components will still be owned by the DS team, i dont think we would consider teams taking things as their own unless they are using the components to create local components or patterns.
7
NoThis is something we're actively looking into. Our first big move is to get our Figma Org better suited so component analytics work better. We have loosely looked at some tooling to use for internal dev use but haven't made a move on anything yet. I'd love to hear how others have setup dev tracking — the tools you've used, hurdles encountered along the way, etc
8
YesConfidently' is subjective here, and I would say I'm not 'confident' in our mechanisms. We are tracking through various analytics, feedback channels, and new product consumers. I'm sure there's more we can be doing.
9
Nowe shared figma UI libraries and we regularly update these. Each time we update, we send out a chat notification into our official design teams chat. And also upon sync meeting we show the new changes. However, the topic does not seem to interest all of the relevant designers, so its often overlooked... our designers do not need to use the system daily, we also spent a lot of time designing workflows (mostly in miro) so its more like putting post-its and boxes next to each other, but no UI design is needed. if there is no UI design, then the relevance of a design system based UI kit is less.
10
YesWe use some scripts to detect use. On paper it looks good, but adoption doesn't equal conformance so it can paint an inaccurate picture. For example, a team could use a button where a link should've been used. This looks good for adoption, but isn't conformant to the component use. To that end we're thinking through how much we rely on adoption and how we can better track conformance.
11
NoWe've tried auditing production experiences or UX work for design system compliance, but its incredibly time-consuming. We have also tried searching for how many repos are pulling in our npm package, but can't tell from that how "much" is being used. Finally we always do an annual survey, but it's limited to who actually fills it out.
12
YesYes! We've had some hiccups in terms of adoption--our company has multiple different design systems for different platforms or workstreams, so it is hard for teams to fully commit to using all of our components. This past year we have not had much tech support which made it harder to make the case for designers to want to adopt. The main issue we are running into is when designers already have made a design and will have to completely rebuild their component or when they have modge-podged their layouts pulling from 3 different design systems and build a custom component as well. With greater backing from the company and more widespread knowledge and guidance I believe it can be better!
13
YesAdoption is a huge topic for us, since we're building a DS that will serve as the new front-end infrastructure for dozens of existing products. That requires a massive mindset change. We track adoption (focusing on usage %) to know if we're moving in the right direction.
Our working assumption is that now that we've "survived" year 1 with 18 early-adopter products, if we continue to build what people need and it's of quality, it will be used (adopted as the way to build UI).
We're measuring "coverage" within front-end code (% of DS components out of overall components) for any new project or a redesign of existing interfaces. A high % in code means that everything that led to that moment (designers using the DS, quality and accessibility is good, product is happy, etc) is working well.
14
YesThe early adoption of design systems requires a lot of hand holding, training, and making sure that all the teams involved understand how and why it works. Cross-functional teams will need to understand the benefits so that they can be advocates for you. Getting their buy in requires early buy-in on new features. This means that Design system teams should be meeting with them frequently to try and understand their needs. Engineering should be your primary advocates. Understanding the tech stack, blockers, and needs of the live system is the only path to success.
15
Noat the moment it's technically difficult to track properly but we want to look into it.
16
No
17
YesOffice hours attendance metrics , code adoption, tokens patches added, slack channel support requests.
18
YesI have a very small shop. My design system was created by me, implemented under my instruction, and is in a state of entropy because I'm not spending as much time as I need to keep it up to date with changing scenarios and use cases.
19
YesWe scrape internal code repositories and count how many times each of our assets are imported. This not only give us a count of how many teams are adopting us but it tells us how deeply they are.
20
NoWe're a small company and adoption isn't an issue. Engineers already understand the benefit, realize it's easier to use what exists, than to roll their own. For Designers, though, it's only slightly a problem where there's still lots of copy/paste designs from years old library that doesn't match or sync to the eng side. However, eng is typically observant enough to match old components to new ones.

We do, though have a mechanism in our QA environment that can turn on highlighting areas that are not specifically DS components. But this is mostly for us to find and replace legacy components.
21
NoWe're in the process of measuring usage right now, so we need to get a baseline and then observe over time. Also parts of our system are brand new, so again we need that baseline to measure against.
22
NoIn my experience, tracking DS doesn't just happen by adopting components from a shared Figma library. Challenges occur when several frameworks are being used in conjunction with a Figma library. Some experience includes a code repository and platform content. Tracking each of these is very messy and sometimes do not provide meaningful insight into usage and adoption.
23
NoWe track design adoption through Figma and on the engineering side manually by who has adopted. Trying to find a more efficient way to track through automation.
24
NoI would say we're actively setting up ways of putting adoption tracking in. For design, we use Figma analytics to monitor usage in the files. Next up is monitoring Engineering usage, but we are having to rely on manual monitoring as we lack the automated tools to do so. It's something we are actively looking to fix and wanting to hear how others are solving for it.
25
NoWe have been trying to get our Eng team to build an internal tool to track and measure, but have very little capacity for them to take this project on. We are currently manually tracking adoption.
26
We're at the very beginning of building our DS
27
NoThere is no organisation level wide dashboard of teams, projects, sites or pages, and no definitive list of code repos which we can even turn our automated tooling on to check on a rudimentary way which teams are adopting the system, or to what extent.

It's going to be a really laborious effort to track this information down, and frankly a waste of time from my perspective - but the hierarchy is demanding some figures to track, so despite all the caveats about pursuing this brute force binary adoption metric, it will have to be done.

It will tell us nothing about how *well* teams are adopting the system, or the reasons they might not adopt it, or certain aspects or components. But it can tell us what range of parts of the system they're using, and what version they're on.

In the past, we ran an adoption survey, but this was not compulsory and patchily responded to. We will need to either do a forced survey, or a proactive outreach series of interviews, to fully map adoption at the level of the individual designer.
28
YesLOADED QUESTION! We track design adoption, code adoption is the responsibility of our tech manager. We send out surveys quarterly. We ask for the % of the product using the system VS the % of the product that COULD use the system. We then math that out to assign an adoption %.
29
NoThe key word here is "confidently". I'd be highly suspect of any team if they unequivocally believed they were confidently measuring adoption of their design system.

I don't think adoption is fully quantitative as much of it comes down to *how* a token, component, pattern in used. I've yet to see any solution that comes remotely close to in-content measurement of proper usage.

Measurement is great, but I also think a healthy skepticism of any metric is key to them providing value.
30
YesIn Figma, I look to see if the # of uses of my components is rising. In Github, I look to see if the # of downloads is increasing.
31
YesFor our team the answer was "yes", because we didn't have a team for the design system. So, all the product team members were design system developers/designers. Therefore, we took care of how we would use it ourselves, cause we had to use it.

Also, I was working with a different team which decided to use Bootstrap as their design system. Bootstrap cares a lot about adaptation of their system, right? They have clear and good looking documentation with all the examples. Despite this, nobody from the team cared of how Bootstrap meant to be used. Neither developers nor designers. Everything was rewritten or hardcoded above Bootstrap elements. For example, nobody used Bootstrap variables to change some value, just css above. Nobody cared about component variants, just css above. Bootstrap principe Mobile first? No, thanks, we have backwards css above from desktop to mobile. Nobody cared about any principles, cause it was "faster" for the team.
32
YesStarted using Omlet to track usage. We can easily see % of code in a project that is coming from DS or not, as well as individual component usage.

We have some insight into how code projects == products/teams, but not exactly 1:1. We are also relatively small, so it's easier to grok than a giant enterprise org.

I was pleasantly surprised to see we had high adoption, if you count adoption as "# of projects/teams using it."
33
NoOn the design side we’re using Figma’s analytics which basically just tell us who is not using our design system at all (in their design files).

We’ve just upgraded to enterprise and are looking into what Pinterest did with the REST API but haven’t had a chance to free up dev capacity to work on it yet
34
Yes and no, we don't have metrics in our system, but we know we have strong adoption of the system through the product and our engagement with product teams.While we don't have adoption metrics in place at Wise, when we went through the rebrand, it was critical to get teams on board with the design system; otherwise, our launch would have been a failure. During this process, we had detailed spreadsheets, partnerships and workshops with teams and regular catchups to measure who was using the system and what was needed to support them cross-platform to move over if they weren't.

Our sales tactic for this process was 'Use the design system, and get the rebrand for free' — this ended up being incredibly powerful to get us where we needed to be. Post-rebrand, we really need to start tracking metrics for ongoing maintenance, but given these metrics are usually used to showcase business impact, this is a lower priority at Wise at this stage.

There are other metrics I would love to put in place so we can better measure our system and where/how we can improve it outside of adoption.

---

At my previous company, where we started a design system from scratch, we had metrics in place across our react and react native components, and we would track insertions cross repos to measure adoption over time. This allowed us to measure our business impact through unique component adoptions per repo.

I have always wanted to get metrics in place through Figma, but their out-of-the-box solution just doesn't cut the mustard, and creating customised plugins for this has never been at the top of our priority lists.
35
YesI answered yes but I'd love a "sort-of" answer option :)
We currently track adoption through two means- first being code usage statistics. This is very useful but has some limitations in that it is only semi-automated so for the moment we rely on product teams to tell us they have new projects using the design system when we reach out to them.
Second- we only measure code usage, we have no stats on design usage apart from the analytics in Figma which only tell a tiny part of the story.

Our second means is through fact gathering during meetings, interviews and general chats with our subscribers which is collated then to give each project and team an "adoption level".

We currently have 5 levels-
0- Non adopter - not using system and no progress made in modernisation required to use DS
1- Plan & dependency- Modernisation has occurred (pages built in React), stories using DS designs and components planned or in progress
2- Visual Style- project is using the basics such as colours, typography, icons and theme in design and dev.
3- Base components- basic components and one or more complex components in use. Commitment to replace custom components and reducing design debt, contributed back to library at least once. No more than 3 months being latest minor release
4- Complete library- all suitable components are from our DS. No custom components without justification i.e. snowflakes. High % of design debt removed. Regular contributions to the library. No more than 2 months behind latest minor release.

Currently we don't have any projects at Level 4, but 35% of projects at Level 3, 29% at Level 2, 12% at Level 1, and 24% at Level 0.

As the information which informs these levels is gathered through meetings and interviews, it only gets updated once a quarter and sometimes not even at that. However it continues to be useful I just wish there was more automation to help with gathering these stats.
36
NoI'm not personally close enough to our analytics to know the specific ways we are tracking our adoption rates. I'd like to see our what we are tracking and our trends more frequently (starting internally on the DS team).

On top of tracking, we also send out consumer surveys. But in order to keep them short enough to get answers, our critiques are often broad like, "We'd like more components." I'd like to build closer relationships with product teams to understand their specific needs better so we could do more with their feedback.
37
NoWe are still a small system with only a single team using it actively. As we start expanding to other internal teams we'll be brainstorming how to properly track this metric.
38
YesWe are able to scan for usage of a system component and from this perspective, adoption is going ok. However, we would like to start tracking more meaningful metrics such as the amount of work saved by using the system (code coverage rather than component import), commonly used patterns that are not in the system and business impact on the design side of projects.
39
Not really working on design systems. Have only helped establish some but not a lot of maintenance or coming in to one that’s ready established Have not had to monitor long term of design system. Mostly new clients and starting to establish a design system.
40
NoWe’re not confidently tracking adoption, because we have nothing in place to track with. Our Figma library analytics could plays a certain role in this, but it’s not a fair metric covering overall adoption in both design and code. There’s also many platforms that our design system doesn’t yet support so the adoption metric will always be sort of skewed. Another challenge is how to actually tackle adoption when the design system started out as a product built by the design system team with very little user research and then all the product teams were just expected to use what was made available. Measuring adoption is probably not one of our biggest challenges right now, it’s getting people to actually adopt.
41
YesI built a tool in Node.js to find component instances in product. So, we were tracking design system components vs legacy non-design system components. A big milestone was when we crossed the 50% threshold (meaning more system components were in product than legacy components).
42
NoI think it’s a bit of a yes and no answer. Our design system is complex in that it’s linked to another design system so that causes some complexity.

We’re doing a lot of work to improve our design system and a challenge we face is getting it well understood and adopted.

We’re on that journey to explore how we go about doing that now. So is our design system fully adopted, nope, but are we confident that we can get it there… maybe.
43
I am a consultant, so nothing is “mine”.I answered NA above.
44
NoFigma library analytics are the easiest free usage metric, but there's so many external factors that affect usage that the numbers mean very little in relation to adoption:
• The size of the team
• The number of products a team works on
• How often a team redesign
• Copy and pasting of files
• How designers structure or "hand off" their Figma files.
• Is the design actually in coded production?

So I would disagree that usage is a synonym for adoption. High usage doesn't equal high adoption.

I see adoption as the adoption of the design system into a team's culture. The problem is nobody in our organization has yet worked out a way to measure that at scale. The thing that keeps me up at night is that I still don't think I could provide concrete evidence to the person with the money that this is still worth the investment.
45
No-
46
Still getting started. Haven't quite defined the brand and UI direction for our product.

Also we're a small start-up so I'm the sole designer. However I should plan ahead and ensure the foundations are right.
See above
47
NoI can build design systems but I’m not great at it. It’s probably my weakest UX skill
48
NoThere is a little yes and a little no for us. And a whole lot of squishy points on this topic.

Yes - we can track who has loaded/is using our system from the tech perspective and see how many folks are using our Figma assets. And, we use Google analytics on our documentation site.

However, it never seems totally clear if they are fully using the system or using multiple systems (we call this "quilting" pieces from various systems to meet their need). And, our system is very incomplete - so this is understandable.

We've had a lot of stops and starts, so we have not gotten to put as much focus on an ideal way to track adoption.

And, we've seen leadership throw out goals of "100% adoption" and our team finds that hard to believe as truly achievable. This is especially challenging when there is not the same directive to sunset existing alternate systems. And, we know everyone loves their own thing (at least in our particular corporate culture).

Then there is the notion that some folks have adopted an older version, that is no longer supported - but are they adopting?
49
It doesn’t apply yet. We’re in redesign mode and will begin measuring adoption once the new iteration of the system is released. I’m pretty new to my team and I’m still learning what the true reach of the system is. I’m also trying to put a plan together for how we can measure adoption when we’re ready
50
I’m a design system consumer, not a core team member.NA
51
NoIt's sticky. It's easy to automate from the code side; they can just write a script that determines what packages are being pulled and implemented, but we don't have an easy way to automate it on the design side. Ultimately (in my opinion), that shouldn't matter, but for some reason there's appetite to measure that.
52
Our DS is being built, so implementation and adoption is not yet a reality. We are working on adoption of the IDEA of a design system in the interim, with positive results. Some designers are very familiar with design systems, while others are learning about them.
53
NoWe haven't released our design system to the full organization yet, it is still in beta, but I think this is something we could really improve on.

Currently adoption consist of a lot of handholding with different departments to help them get started working with the system. We embed designers/developers into each project to ensure they are implementing it correctly. This strategy currently works while only a few departments are consuming the design system but as it roles out to the broader organization we will need to find better ways to make sure adoption can scale.

We have implemented resources like a robust documentation site and will be offering office hours once the system is released to better serve our users. We will also try and monitor usage through Figma and analytics through our documentation site.

I'm excited to hear what everyone else is doing!
54
NoTracking adoption has always been a "white whale" in design systems. I can be difficult to get a handle on. In my first design system, it was such a monumental task, that we didn't even really try to track.

In my second design system, we've really focused on getting started, delivery and partnering with groups to get components adopted. But tracking can feel intimidating and feels like a luxury item for more mature design.

However, recent tools have made it promising to track easily. We're looking at exploring those tools to see if we can reveal how much our design system is being used. They may solve a huge paint point. And if so, it'll reveal a bunch of ways to create strategy going forward.
55
Nomy system is caught up in a massive IT system upgrade so we are stuck in a weird limbo between old and new components and code. We are exploring ways to measure future adoption, I am excited about this session.
56
NoWe have announced all new websites must reach out to central marketing before doing a redesign. However, it is up to that unit to do the communication/confirmation to us. This hasn't been happening each time, whether it is intentional or unawareness.
57
YesThe adoption at the moment is very simple, but would love to see how to improve it, here are the files, and here is the documentation on how to use it, contact me if you have any issue.
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100