Benefits of a Design System
April 30, 2024
Jason Jajalla
When building digital products, a Design System refers to the set of tools, assets, processes, and guidelines used to produce solutions for users. Google’s Material, Shopify’s Polaris, or IBM’s Carbon are popular examples of design systems.
In this article we’ll review pain points you might see when working without a design system, the ways a design system can help deliver products customers enjoy using, and some things to consider when starting a design system for your team.
Not having a design system, or having one that isn’t meeting the team’s needs, means that effort is wasted by treating each problem as something to be explored from scratch every time. Imagine running a bakery without recipes or measurements and operating purely on feels.
Maybe some of these challenges sound familiar:
High effort-low impact work is a common result when there isn’t a clear system defined for how things should be done. This reduces the business’s ability to perform in competitive markets, and demoralizes teams by slowing them down.
Leveraging a design system for your product brings three main advantages:
Efficiency gains are achieved by reusing high-quality work others have already done.
There is a huge difference in effort between shipping a filtering mechanism when you have patterns, inputs, and templates ready to use, and when you have to define, design, and build everything on the page from scratch.
Having design and code artifacts ready-to-use, documentation to guide people when they encounter problems, and processes governing how to push forward are all ways design systems keep things moving.
Unless you’re working as a solo software building unicorn, chances are you need to work with other people to create products worth using.
Design systems help foster new ideas by making circular debates obsolete. Having yet another meeting to debate what side the confirmation button should go is an expensive waste of time.
Collaboration across teams using a design system could show up as:
Barriers between teams or individuals can naturally crop up when they’re isolated. Design systems help mitigate this isolation by acting as a common thread of assets, documentation, processes and governance that teams use to make their work more manageable. This common thread makes connections across designers, developers, product managers and other business stakeholders a lot more efficient.
UX dad Jakob Nielson says, “users spend most of their time on other sites, meaning they prefer your site to work the same way as all the other sites they already know.”
When users have to relearn how to use your software every time they’re performing a task, no matter how small that difference, it adds friction. These friction points can also exist between different parts of the same product, like a panel that opens from the left for one page, vs the right on every other page.
When users experience a disjointed experience, this can show up as more support tickets being submitted, more input errors, reduced conversion metrics, or abandoning the site entirely. Enabling consistency lets users learn the rules and build a mental model of how your site works, then apply those rules to other pages they interact with.
Design systems are perfectly suited to spreading consistency across a complex product where multiple disciplines are leading different areas of development. For users it means they’re using one tool, not a Frankenstein-ed product with different ways of doing things.
Imagine a company that builds tools for video creators. A newly formed team had been tasked with creating a dashboard reporting page that reports on video content engagement metrics. This new Dashboard team had gathered research through a series of user sessions and created low-fidelity wireframes to get early buy-in.
In this Design Systems Multiverse™️, our story diverges in two. One variant of this company hadn’t yet adopted a design system, but the other variant has. How might their journeys be different?
After validating their early concepts, the team without a design system saw their first minor hiccup: the development team wasn’t confident they could meet estimates because building all the required components exceeded their team’s limited capacity.
The designers weren’t phased because they could also use the extended timeline to design all the data visualizations, tables, and widgets defined in the requirements. All the UI elements would have to be created from scratch. Reusing work from other teams wasn’t seen as a serious option because the new team wanted to make a lasting mark in the company.
The systemless team were presented the opportunity to share their progress at the company’s latest all-hands. Their slide deck of static and highly stylized visuals impressed most departments, but the other product development teams were less enthusiastic.
The Plugin manager team and the Scripts team questioned why the Dashboard team created a third table style that diverged from each of their own approaches. The product managers and developers also tried to justify their own approaches and push their versions as the one each team should follow
The lack of alignment across teams has had an effect on morale. People said nope to the drama and left.
Ultimately the launch was delayed even further. Internal rumours hinted that company leadership was considering reorganizing all the product teams to break them out of their silos. One of their leadership goals was to encourage more cross-team collaboration. They contacted a sought after design agency to help them establish a design system practice internally.
The Dashboard team reviewed system documentation for the components they expected to use. They reached out to the Plugin, Scripts, and System teams to understand more about the components contributed, how to best utilize them, and any limitations when trying to adapt components in a dashboard context.
The Dashboard developers built the first iteration of their product ahead of schedule, using what they’ve learned in their team collaboration sessions. The timing of their first build conveniently lined up with the company all-hands. The dashboard developers presented a live demo of the product built in just a few weeks. The entire company was impressed, with the loudest cheers coming from the Plugin and Scripts teams. Woop woop!
While the Dashboard development team was setting up scaffolding and connecting data sources, the design team had been exploring new concepts not yet considered by the other teams or the design system. They contributed revisions to existing components that would meet their needs, and invented completely new patterns for their use cases.
The Dashboard product managers used design system components and created live prototypes with development to get early input from users. The team was able to include these unplanned enhancements without impacting the launch date.
The dashboard page was beta launched on time and with additional features. Early users have responded positively, posting their experiences online creating excitement for the new product. The actual launch exceeded expectations and the company had a record amount of converted users. Global warming was also solved not long after.
In the narratives we went through, we saw how design systems spread innovation and knowledge from one part of a product so they can be reused to uplift other areas.
If your team is embarking on a design system journey, one of the most important things to do is to understand where you are today.
Identify why you need a design system, what you already have that can act as the system seed, and the people who can actively contribute to building the system.
Chances are there is some type of ad hoc system in place, but it isn’t working well. Ask people what they think about the system today, what it helps enable, what it doesn’t do, when they use it, and how their work is eventually used by other people.
Then build, share, and repeat.
Create a component, document, or process. Let people know about it and how it can help them. After some time, talk to the team to understand how they’re using it. improve on the thing you built, and do it all over again with the intention of making things incrementally better.
Do a mini UX audit on your table views & find your trouble spots with this free guide.
Be the first to know about our upcoming release!
.webp)
.png)
