The practice of Design Systems has grown over time and it's now common for technology teams to utilise one as a tool to drive consistency in their products and efficiency in their workflow.
Design Systems can be a game-changer — if you get them right. But after working on four different systems, I've learned they can just as easily become a time sink. Over the years, I've learned some smarter, lighter ways to approach them. Here are a few myths I've busted along the way.
Myth #1: It's something that Designers should own
Design Systems work best when Design and Engineering work closely together towards a common goal. The first time I worked on a Design System, our design team had set aside time to refine the component library and make sure that everything was beautiful in Figma — but there was very little buy-in from Engineering to prioritise the work.
As a result we had great designs that never really made it into code and Engineering was often just building interfaces from scratch anyway — not really the point of a Design System. Without Engineering buy-in, your Design System is just a Figma exercise. Bringing in Product early can also help drive adoption — after all, a Design System only works if the whole team sees its value.
Myth #2: You need coverage of all components
You don't need hundreds of components for a Design System to be successful. Teams often focus on maximising component coverage, but a great Design System isn't measured by the number of components — it's measured by how well it's adopted.
A Design System is only effective when teams actually use it:
- At a design level — ensuring consistency and efficiency in Figma
- At a code level — reducing duplication and speeding up development
Even if your system only had one component — say, a button — but it was used consistently across your product, that would still be a success. The real value lies in reducing redundant work, not in stockpiling unused components. Instead of focusing on quantity, measure success by adoption: how many components are being used, not how many you have.
Myth #3: All new patterns or UI elements have to be components
I remember early on, if I created a new UI element I would immediately try to push it into the Design System. Back then, I was much younger in my career and didn't understand the importance of balancing the effort with the payoff.
This is where a Contribution Model comes in — it's important for Design and Engineering teams to think about what's important for them to componentise and what's easier to be left as a bespoke or feature component in the feature that they're building.
It's a myth that when you start a Design System everything automatically needs to be constructed out of components. It takes effort and time for components to make their way into your product. A good Design System is flexible — it should serve your team, not the other way around.
Myth #4: Figma components have to cover all scenarios
I've fallen into this trap — making components too "opinionated". In a previous role, I spent heaps of time making a component of an e-commerce product tile in Figma that could display every single permutation for designers to use. It turned into the most complex component known to mankind.
Some of the downsides of this overcomplicated component:
- It never matched the coded component — Figma was always out of sync or a step ahead.
- It became difficult for designers to use — there were too many hidden settings and properties.
- Every time we needed a small design change, it was risky because the component was so complex that it needed extensive rework to accommodate the change.
In hindsight, I should have kept it simpler — focusing on practical approaches like component placeholders rather than trying to account for every possible scenario.
Myth #5: The more documentation the better
As someone who has created a lot of documentation, I've fallen victim numerous times to a situation where the effort put into creating documentation simply doesn't pay off for the team.
I once built the 'perfect' Figma component library, complete with detailed documentation in Confluence. But the Figma components didn't match the coded ones, so developers couldn't rely on it — meaning all that documentation was useless.
On another project, we kept documentation lightweight — just post-its in Figma and a single source of truth across Figma and Storybook. As much as possible, we tried to make sure that the components in these two repositories matched up. This minimal approach required little effort but had huge payoffs, keeping Product, Design, and Engineering aligned with minimal maintenance.
Good documentation is:
- Easy to maintain
- Accessible to Product, Design, and Engineering
- Focused on what really matters (not every edge case ever)
I've also learned not to pre-empt every possible decision or scenario. If your Design System builds on an existing library, many behaviours are already defined. Focus documentation only on what's unique to your use case, adding references as discussions arise.
So, how should we approach Design Systems?
Every organisation is different, and there's no one-size-fits-all approach. It's easy to look at the big players like Atlassian or Carbon Design System, but your system needs to be practical — maintainable with the resources you have and actually useful for the team it's built for. A good Design System should always be:
- Built in code and actively adopted by both Designers and Engineers
- Aligned across design and development — what's in Figma matches what's in code
- Sustainable and accessible — with a payoff that outweighs the effort of maintaining it