We know the drill. You have a Design System in place, but your design and development teams – whether they’re outsourced or in-house – aren’t using it. They’re still doing platform development ad-hoc, creating screens, patterns, and components from scratch every time. But scaling up calls for the sort of systematic approach that Design Systems are supposed to provide. So, not using it means you’re holding back your own growth. Why aren’t your teams using your Design System? Because there’s a problem with the ‘system’.
Guest blogger Christopher (Berry) Dunford of CollabSoft has been working with Yummygum to pinpoint why there is sometimes tension and disconnect between designers and developers. With poor Design System adoption a key factor, Berry looks at ways of repairing the system to increase adoption and, by extension, facilitate better developer-designer collaboration.
The importance of Design Systems
A Design System isn’t a product. It’s infrastructure necessary for your design and development teams to operate. But many Design Systems have become bloated and inefficient. The ‘system’ has gone wrong, so everyone stops using it. As a result, design velocity is low, design handoff is messy and time-consuming, there’s redundancy at the development stage, and your brand and user experiences become inconsistent.
When used properly, Design Systems protect your brand and increase the speed and efficiency of how your teams build software. They also act as a shortcut for junior and less experienced designers and developers, enabling them to build on the work of others.
So how do we get our Design Systems working again?
Get buy-in from leadership
A challenge for many companies is persuading top-level management that it’s worth investing time and effort in the Design System. If leadership can’t perceive the business value of the Design System, they’ll deprioritize it. But any system that doesn’t get managed or maintained properly will eventually start to fail.
I know this is why Yummygum focuses their efforts on leadership change when helping their clients to implement Design Systems. They have to persuade the decision makers first, by explaining how much time Design Systems save, the consistency they create, and how they increase design velocity and experimentation. Then Yummygum implements metrics to help managers visualize how their Design Systems are performing, such as success criteria and accessibility scores.
Managers’ decisions are guided by facts and figures. Although you can’t boil down the return on investment (ROI) of a Design System into a single number, there are ways of approximating the return so a manager can feel a bit more confident about investing the time. For example, Smashing Magazine devised a general formula for calculating Design System ROI and estimated the return to be 135%, with a $871,400 net gain over 5 years.
You could also look at surveys and experiments other companies have done to understand the value of Design Systems. For example, Bryn Ray, Head of Design Strategy at Bloomberg, did projections for a client and found that a Design System could reduce delivery time from 277 hours to 190 hours.
Once the managers are convinced, you’re half the way there, because they will be the ones pushing for the Design System to be used and maintained.
Create one system, not two
I’ve spoken to a number of developers who’ve told me that they have two Design Systems: one in Figma, one in the codebase.
I read an article that said this was okay, that Design Systems shouldn’t have a single source of truth because developers and designers are working in different places. They have different access points for the system and shouldn’t be forced to a single destination.
Nonsense. The developers I spoke to said having multiple Design Systems is the reason they fail. It’s because they’re not linked, so they regularly fall out of sync. For example, code components don’t match the Figma components, or there’s a component in the Figma Design System but no code for it in the codebase. It’s also very disorienting to have more than one reference point for your Design System assets.
Two systems are no system at all. Therefore, companies need to find a way of creating one system that bridges the gap between designs and code and is easy to sustain.
Figma’s code connect feature does this by mapping real-life code snippets from your codebase to your designs in Figma. That way, when a developer accesses a component or pattern in Figma, they can see that it’s backed by real code. In effect, you’re creating a single, unified Design System with two interfaces, Figma and code, which helps keep the two aligned.
Create your Design System in a neutral, central space
Figma’s code connect feature is great, but it does assume you’re using Figma as your Design System. Which many companies do. The question is, should they? Something to remember when building a Design System is that it’s not just for designers and developers. It’s for everyone. Marketing, sales, support, and management are all Design System users as well.
But Figma is a design tool. It favors a designer’s experience over other teams and a lot of non-designers, including developers, don’t have the expertise to navigate it effectively. The last thing you want is for the tool you use to create your Design System to be the very barrier to people using it.
Ideally, your Design System should live in a tool that’s focused on creating and storing general team documentation, like Confluence or Notion. Everyone's already working with these platforms, therefore no one is alienated or has to learn a new tool.
The key to a sustainable and effective Design System will be to make sure that the documentation tool you choose has integrations with your design and development tools. This enables you to make the documentation your single source of truth, with Figma designs and code snippets side by side. It also enables designers and developers to update components without manual duplication.
For example, with Figma for Confluence, designers can embed live links to Figma designs in Confluence pages, enabling users to view, inspect, and download designs directly from Confluence.
Key takeaways
Bad tooling is one of the main reasons designers and developers stop using the Design System and, consequently, don’t collaborate as well as they should. For a Design System to work and be sustainable, it can’t be spread across copious disconnected tools. It HAS to have a single source of truth.
This source of truth should be easy to access, use, and maintain, which is why it should live in a tool that doesn’t favor one team’s experience over another. This makes a general team collaboration platform, which integrates with your design and development tools, the ideal choice for building Design System documentation.
Only by streamlining your tools and centralizing your content will your Design System truly serve its purpose: to bring consistency and quality to your products and experiences, and cohesion to your teams.
