Are you a designer working on your first design system? Is there a lot of talk about the system’s adoption rate and how you can measure it, especially if it’s a brand new system?
I’m here to tell you that your system will never be fully adopted.
With YouTube videos.
A design system is, according to Wikipedia, “a comprehensive framework of standards, reusable components, and documentation that guides the consistent development of digital products within an organization.”
That sounds a lot like the systems that governments put into place for really big government products like roads, satellites, and things like that. Their design systems need to work not just for one user or one class of users, but for all the users both inside the country and outside of it.
The problem is that there are a LOT of relationships to manage when you’ve got that many people in the room. And not all of them are harmonious. And in some cases they’ve already tried wiping each other out eight or ten or a hundred times.
So just building the design system is going to take a LOT of time. Which means getting everyone to agree on how you’re measuring that time. Sprints, quarters, years….
Since the goal of a design system is to be adopted, so that designers and developers can efficiently build consistently products, we want those components to be as elegant as possible so that the designers, developers, and end users all feel like moving to the design system. That’ll get them to upgrade, right?
OK maybe not. Maybe those political things are still going to interfere with some of the people adopting the components. Maybe they’re not able to adopt the components because they have other influences — the budget isn’t there, or they’re in the middle of a different project that’s more important to hitting their business goals.
Whatever the reason, there’s a good chance that adoption is not going to take place all at once, or even all in one year.
There’s also a strong possibility that even when a team does convert over to the official design system, they may not actually use it the way you intended. I wish I could say that I had never seen this happen, but it is possible that once a team implements the components that your team spent months working on, adjusting, and getting to the point that they’re elegant and effective, the business units that received it still didn’t like it…. so they had their developers re-skin your components to look like their old ones. That way, they could convert slowly, there was no visual difference, and they could still say that technically they had converted.
(If you ever see this in the wild do yourself a favor and try to get them to re-skin their old components to look like your new ones instead of the other way around because every time I have seen this in the wild, the team that re-skinned the new components ended up abandoning that work and re-skinning the old ones instead.)
Officially, you can convert, without letting anyone know you did.
Migrating one company to one design system is not as hard as migrating a whole country to a single measurement unit, but it’s going to feel like it is. While on one hand the benefits are real — easier support, easier repair of bugs, etc. for those who adopt the new system — the power struggles, drifting timelines, and varying definitions of “adopted” will have you shaking your head for a long time.
Keep your eye on your goal: making the system available for the people who need it. Supporting it for the people using it. Measuring code changes and updates to show that something is definitely happening.
And also, when it comes to measuring adoption? Don’t set your goal at 100%. Just, don’t. Figure out some other way to show that things are getting better for the folks above you and accept that adoption is firmly out of your control.
Thanks to Tom Bacons (@TomBacons on YouTube) for the laughter.