Design systems are so hot right now.
Remember that time when single-page apps were new and hot? Everybody wanted one, devs wanted to build them, and pretty soon we started to see them being used in a lot of places that didn’t make sense (like content-heavy news sites that needed fast initial page loads and strong search rankings).
Things have settled down for single-page apps since then, but we’re at risk of being in a similar place with design systems. It feels like every article on design systems is advocating for dedicated teams, external repos, and documentation sites. These kinds of systems are impressive but they have real costs, and there are plenty of situations where they simply aren’t justified. Let’s talk about a few of them.
Your Development Team is Small and Communicates Well
Design systems are great at helping with team communication and product consistency, but does your team actually struggle with these issues? Many small teams don’t.
Small development teams often work in the same office, attend the same standup meetings, work off the same Kanban board, and share the same code repository. Work can be approved by a single product owner. The code can be checked by a single linting ruleset. Sure, mistakes still happen, but everyone knows what everyone else is working on, so it’s easy to make course corrections.
Building a design system in situations like this is a premature abstraction, and premature abstractions are risky.
Even as your team grows to support multiple products and codebases, there are less expensive ways to improve communication and consistency than building a full-on design system. Do you really need a design system, or do you just need better documentation? Will a strong Sass variables file suffice? Can you get away with an internal repo for your brand assets and guidelines?
This idea of building resources only in proportion to your needs is summed up nicely by this quote:
“I think there’s different scales to a design system. Not everyone should aim to do a Lightning Design System from day one. I feel like you can start with super small abstractions around your color system, your typography, a few things like this. And then if need be, if your company grows, if you have lots of stakeholders and people start having inconsistencies in the user journey, then you can start growing your design system, or at least your initial layer of abstraction.”
Kaelig Deloumeau-Prigent—Developer, Shopify
Your Team Isn’t Doing Much Active Product Development
Many of us who work in software are used to a constant development cycle, but lots of products don’t work like that.
Sometimes, a CMS gets built and the work is done. It gets used by content editors and is occasionally upgraded, but the development team and budgets are reallocated to other priorities, and the world moves on. This pattern is especially common with time-sensitive projects (event websites, marketing campaigns, etc.).
Design systems don’t make sense here because a design system demonstrates its value in times of active development. It’s when a designer is working on a new notification message and needs to know what colors to use. Or when a developer is building a new form and needs to see what field types already exist.
If you don’t anticipate a lot of new development on a project, then a robust design system may not make sense.
Your Business Has Limited Runway
Design systems require upfront investments that pay off over the long term. But if you’re a startup with eight months of funding left to find product-market fit, there may not be a long term. Building a beautiful, visually-consistent product that nobody wants is a quick way to go out of business.
Even if your business isn’t in survival mode, realize that a dedicated design system team is more of a cost center than a profit center. Their charter is similar to the internal tooling teams that many big companies have: They have to justify their existence by improving productivity for everyone else.
Designers and developers will likely be biased toward building design systems. It’s fun, visible greenfield work, which solves pain points for their peers. But at the end of the day, somebody has to make sure it makes business sense.
If you have business responsibilities, then look at your timeline and make sure the investment can pay for itself before jumping in.
The Biggest Risk
Our own Rob Harr likes to say, “The biggest risk for software projects is building the wrong thing.” Certainly, a robust design system is the right thing for some teams, but just because it works for them doesn’t mean it will work for you.
Take the time to consider the true costs and benefits of a robust design system. Doing this will help you see past the hype and know whether it actually makes sense for you.
Looking for more on design systems?
Sparkbox is dedicated to sharing our experiences and discoveries about design systems. Sign up to get updates on design system content including our annual Design Systems Survey!
