I’m just back from Boston where I had the privilege of presenting two years of design system work at HOW Design Live alongside one of our long-standing customers. We covered in great detail the process we used to earn buy-in and get this system to a place where it now has a dedicated team and multiple subscribers across five brands. In addition to giving the talk, I was excited (and nervous!) to announce on-stage the release of our first blush at analyzing the results of our Design Systems Survey. This site is a great resource—especially if you’re looking to justify the building of a design system.
There are many reasons to build a design system. Do just a little reading on the subject and you’ll find a plethora of completely reasonable justifications for whoever signs the checks where you work. Our own research backed up the benefits of “consistency,” “efficiency,” and “accessibility”—which are good and true reasons to think more systematically. And there is another, less tangible one that might just be the best reason yet. Unity.
That Meeting
I know you’ve been in that meeting. The one where the people who imagine the experience are sitting with the people who implement the experience, and the tension is depressingly thick.
Design is focused on the visuals, development is focused on the performance, marketing keeps talking about the experience, and IT can’t think about anything other than how it will be maintained. The communications people are complaining that the technical team is shooting down their ideas. The technical team is complaining because the communications folks keep increasing the scope. It’s an age-old battle and one that still rages even in the most forward-thinking organizations working on the web.
Most days I struggle to understand why we separate these folks. After all, we should be working toward a common goal, right? We should be prioritizing our users, our customers. But finding a vision upon which these multiple groups can align is difficult.
Inward, Outward
Design systems have the ability to do for your team what web standards did for our industry.
The web standards movement was an inward-focused cause with tangible external results. Web standards were for you and me, the people who make the web. Before standards, we could still serve our users, but we just had a lot more work to do. I remember building a site once for Internet Explorer and once for Netscape, and putting a conditional clause in my code to serve the right code to the right browser. This was broken. This brokenness was what allowed proprietary solutions like Flash to become so embedded in our work. Flash felt like a valid solution to so many of us because all browsers rendered your Flash almost identically. It wasn’t until the web standards movement started uniting the people doing the work around an ideal—one that would bring browser makers to the table to solve these problems. And I’ll bet that first meeting with browser maker one, two, and three felt a lot like that meeting with your communications and IT folks.
A dozen years later and we’re in a completely different place. We have a set of standards. Browser makers sit down to work through this stuff. And sure, they don’t always get along. But we are still aligned by the bigger picture—that inward-focused vision that inspires because we know it’s the right way forward.
And who benefits? You and your team do, absolutely. But so do our users. We can be more productive now because we don’t have to fight these senseless battles. We have more creative energy to put toward solving users’ problems instead of struggling to get our designs to behave the same across browsers.
Your Team
I believe design systems can provide an inward-focused vision with tangible external results.
I’ve seen this unity happen in organizations willing to prioritize design systems. These projects give our teams a standard from which to design and build—they give us a common language to speak. They allow us to solve the small problems while creating building blocks to solve the big ones. They let us deliver faster and serve our users more effectively. But more importantly, they marry a designer’s passion for the experience and visuals with a developer’s passion for the process and performance. Design systems are unifiers, giving a voice to every expertise required to do this work. They build trust among those roles—instead of pitting us against one another.
If you think your team could benefit from a unified vision—one that focuses on how your teams work and has tangible external benefits for your users—a design system might just be for you.
Read the Design Systems Survey Report
