Design Systems: Are They Always Worth The Trouble?
After seeing a number of headlines recently popping up about design systems, I started to wonder: how large should an organization be before investing a lot of time into creating and maintaining a design system? Does size even matter?
Google has Material. Apple has its Human Interface Guidelines (The “Hig” as it’s lovingly referred to). Microsoft has Fluent. Salesforce has Lightning. Design systems are absolutely everywhere, and the ones that get the most attention are born out of larger organizations.
But what about smaller organizations? A lot of research, time, and effort goes into defining, creating, and maintaining these systems, and that effort can be difficult to justify for teams with limited resources. That said, design systems help teams maintain a level of consistency that not only communicates polish and professionalism, but it also makes later designs and development smoother by answering questions before they’re asked.
This topic comes up for me a lot at work, so I figured I’d jot down some quick thoughts and answers to questions I get regularly. Let’s take a very quick look at what a design system is, and then look at a few ways to lay the groundwork in a lean way (the best way for those teams without robust budgets and resources). And mostly, I’d love to hear from you readers — is a design system as important for small organizations as it is for a behemoth like Google?
(Oh, and a quick, relevant aside: The 2017 Design + Content conference will feature a talk about design systems, which I highly recommend checking out if you’re there. And if you’re not signed up for it yet, be sure to use our promo code uxbooth on the registration checkout to receive a discount. It’s coming up soon, July 17-19 in Vancouver, BC!)
Wait — what’s a design system?
At its most basic, a design system is an asset library of design components. It answers the question “how do we as an organization approach [specific design element]?” The following design elements are often included:
- Typography
- Layouts and page types
- Colors and usage
- Voice and tone
- Components (like buttons or error messages)
This is by no means an exhaustive list. Any recurring design element is right at home within a design system.
So should my team develop one?
Look. I’m not a Debbie Downer, I swear. And I don’t like to compromise quality or consistency with any product I work with. But as a consultant, I am constantly faced with stressed-but-dedicated clients, managing too-small budgets, with too-small teams with mixed skillsets. And there’s never enough time. Resource scarcity is a reality in my world. More frequently than not, design-related activities (such as building a system) compete with other research-related activities like usability testing.
This is typically my advice for small organizations: if you’ve got the resources and the time, absolutely invest energy into a basic design system, even if it’s not incredibly robust. Build a basic style guide. Define basic components like buttons, hover states, link treatment, etc. Communicate to other teams how this will make their lives easier—when simple design questions arise, developers and other creators won’t be blocked by a designer’s availability.
However. If your organization hasn’t already invested time and energy into usability testing, building a design system can be problematic. It’s important for the components in a system to be consistent, sure; it’s more important, though, for them to be usable.
There’s a lot more to say, but I’m curious to hear thoughts: when is a design system not worth the trouble?
