Design systems are a trending topic these days. A quick glance at Alex Pate’s awesome design systems repo shows that both big name companies and small start ups are wading into the design system waters. At Modus, we’ve helped several clients build out their design systems. Design systems are still relatively new, so we have run into plenty of challenges and iterated on our approach over time. We’ve compiled a list of the most common misconceptions we see when our clients take on a design systems project:
Misconception #1: “The design system is a side project”
The benefits of building a design system are straightforward and well known. It’s relatively easy to connect a design system to cost savings, scalability, efficiency, and consistency. However, despite the value design systems provide, many organizations fail to provide the resources necessary to make the system successful. Why? Usually because teams feel immense pressure to launch new features, and any resources spent on the design system will decrease velocity on the product that pays the bills.
For a design system to truly deliver savings, scalability, efficiency, and consistency, it can not be treated as a second class citizen. We have seen a design system fail to mature simply because it was treated as an afterthought, despite the teams growing need for such a tool. As the company grew, new teams began developing features, prospective customers asked for white labeled UI themes, and new product lines came into existence. Leadership looked to the design system as a saving grace — surely it would drive consistency across these new teams and products, surely it would allow us to quickly theme our UI. They soon realized that without dedicated developers, the design system had never matured beyond a library of sketch symbols.
At a glance a design system may just seem like a collection of symbols (more on that later), but it is actually a digital product in its own right. It has its own unique set of end users, who have their own unique problems and contexts of use. It requires thoughtful versioning systems, inclusive governance processes, and expert facilitation between stakeholders. In order for a design system to be successful, you should have a team whose only job is to work on the design system.
Misconception #2: “You need executive level buy-in before starting a design system”
Yes — building a design system is noticeably easier if you have support from the people who write the checks. But getting your c-level team to back your idea may be harder than you think, given the resources needed to build a truly valuable design system. In fact, Ryan Rumsey wrote an article about how the experience design team at EA garnered adoption for their Joystick design system before getting buy in. In the end, the design system’s early usage made a strong case for investing money and resources in its growth.
All you really need to get started on a design system is one designer and one developer who are passionate enough to put in some extra hours to get the ball rolling.
Misconception #3: “If you build it, they will come”
Again, the benefits of a design system are glaringly obvious; so you may be tempted to think that simply building a design system will guarantee your teams will use it. You also may think that, because a design system is an internal tool, you can just mandate that all teams use it. But remember, you are asking your designers and developers to change their behaviors — sticky behaviors they’ve formed over years. The design system shouldn’t provide value solely to your organization; it also must simplify the lives of the people doing the work. Otherwise, your team will continue to copy code from random corners of the product or create inconsistent designs.
To make your team members’ lives easier, you need to involve them in building the design system. Talk with designers, developers, marketing, and product managers to find out how a design system could help them. Sit down with a few people to truly understand their workflow. Once you have a prototype, ask designers and developers to use it to complete a task and observe the issues they run into. Just because a design system is primarily an internal tool does not mean you should not validate it.
Misconception #4: “A design system is just a component library or style guide”
While many design systems do showcase a UI component library and branding guidelines, a true design system includes so much more. If a design system is not integrated with the products it supports, then its value becomes severely limited. Many teams want to make a single update to the design system and automatically propagate that change to all products. Without this functionality, teams still have to manually search code for all instances of a component, and some components are inevitably missed. Thus, the design system falls short on delivering scalability and consistency. Treating the design system as the single source of truth is the holy grail of design systems. However, it also introduces a few complications.
First, if you change a component widely used across your product portfolio, you will want to test whether the changes have broken any layouts. Doing so requires an advanced automated QA approach. Second, some teams may not be ready to start using the newest version of the component (designbetter.co has a great guide on how to tackle this challenge). Not to mention, you don’t want just anyone changing components willy nilly. A design system must outline a clear process for introducing new components and patterns for changing existing ones. And this process should accommodate your company’s size, culture, and maturity. Small teams may get along with an informal, impromptu slack messages, while larger teams may need formal reviews and change requests.
Misconception #5: “We can only use components that are in the design system”
Eventually, your design system will reach what seems like a critical mass — it will include a large enough collection of components to satisfactorily solve most, if not all, design problems. But this is when we start to enter dangerous territory. Sometimes, design systems make reusable components too readily accessible. In other words, design teams can defer to existing components without considering how a new component might solve the design problem better.
Teams also tend to overemphasize the importance of consistency, opting for an inferior solution simply because it is similar to an existing pattern.
As designers, we must constantly ask ourselves whether a new component might solve the problem better — whether we are okay with simply satisfying the users’ needs. To lead the competition, we must push the envelope; we must delight users in ways that competitors do not. Obviously, this is a unique balancing act, since any software team makes tradeoffs between efficiency and delight as they iterate over a product.
Misconception #6: “The biggest challenge is getting people to use the system”
As mentioned, getting people to adopt your design system is hard. But for some systems, your biggest challenge will be getting stakeholders to agree on design principles and how components should work. Many teams we have worked with tend to overthink how a component should function, often because they want to accommodate scenarios that don’t exist yet. We have, regretfully, spent hours discussing components that haven’t even made their way into a single product yet. Maybe there’s a scenario where all buttons in a button group should be the same width? And maybe another case where the button should distribute their size to fill a container.
But remember, a huge point of building a design system is to make changing components easier. So if you find yourself having too many conversations about a hypothetical future, remind yourself and your team that you can iterate on the design system over time.
Misconception #7: “People will memorize the design system guidelines”
Design systems can be huge. Expecting anyone on your team to memorize every single guideline is a pipe dream, especially when the design system is in its early days. That’s why we recommend assigning a specific person, usually a designer, to enforcing the design system guidelines during the code review process.
Plus, the design system will change over time, and designers need to stay in tune with these changes. Think about including a change log in your design system or automating outgoing notifications to your team when changes are made.
Misconception #8: “New hires will magically discover the design system”
So you’ve built a design system and you’ve more or less convinced everyone throughout your organization to use it. You’re job here is done, right? Wrong. Design systems are especially useful for companies that are growing, so newcomers can quickly ramp up on coding and design guidelines. But if new employees never even see the design system, you’re in trouble.
To make sure new hires find out about the design system, build it into a formal onboarding process. Highlight the design system within your internal intranet or developer documentation. Make the design system and all of it’s terminology a staple of everyday communication.
Misconception #9: “Every company needs a design system”
Design systems are very useful for large companies with large product portfolios. However, if you’re a young company with a small team or a single product, a true design system may be more overhead than its worth. Quickly bringing your product to market may be more important than ultra scalability and flexibility. Also, with a small, tight-knit team, consistency is more achievable without a design system.
Conclusion
So, if you’re thinking of starting the long, yet rewarding journey of building a design system, keep these pitfalls in mind and try to steer clear. If you have a cautionary tale you’d like to share with us, let us know in the comments!
