The 4 Stages of Building a Data Visualization Design System
Most companies today use design systems, and UX teams rely on them to bring consistency to buttons, typography, layouts, and interactions. But one area that’s often left out is data visualization. For modern, data-driven companies, that gap matters—because charts and dashboards are often where the most important decisions happen.
I partnered with The Trade Desk, the leading independent demand-side platform (DSP) in the advertising industry, to design and develop a data visualization design system. What started as an audit of existing charts quickly grew into a set of principles, components, and practices that made their visualizations more consistent, accessible, and effective.
Here’s how the process unfolded across four phases: Audit, Establish, Execute, and Evolve.
Audit: Finding the Patterns
The first step was understanding the landscape. I conducted a thorough audit of all the visualizations currently in use across the platform. This revealed not only inconsistencies, like different treatments for axes, legends, and labels, but also the most common use cases across teams.
From this work, I built a best practices document that outlined what was working, what wasn’t, and what we could standardize. This audit phase was crucial: rather than guessing, we grounded our system in the real-world needs of our users.
Establish: Setting the Foundation
With the use cases in hand, I started defining the core design elements of the system. These included:
Color palettes tuned specifically for data visualization and tested for color blindness accessibility to ensure inclusivity. Luckily, I didn’t have to start from scratch. The Trade Desk already had a robust corporate palette. I defined color for categorical and diverging data sets. From the audit, I knew that some colors, like yellow, already had an established meaning and therefore had to be used sparingly to avoid confusion. If a company doesn’t have an existing color palette or has one that is limiting for charting, don’t be afraid to create a data viz specific one!
Typography and font sizing for chart labels and annotations. I got lucky again that the design system already had fonts and colors appropriate for chart labels. It’s important to use a monospace type face for numbers otherwise decimals in your table will be misaligned and hard to scan.
Gridlines, legends, and axes rules that reduce clutter while guiding the eye toward insight. The audit showed that users found gridlines useful, but I created guidance to make sure they weren’t overused and distracting.
These decisions created a consistent visual language and act as the building blocks for all visualizations.
Execute: Building the First Components
Instead of trying to cover everything at once, I focused on the two most common chart types: line charts and bar charts. I created reusable components for both, along with clear guidelines for when and how to use them.
This experience reinforced a core principle: build for the most common needs first, and resist the temptation to design for every edge case. Add charts to the library after you have a use case for it. If you tried to guess what the ideal heatmap should look like for your platform you would likely be missing out on real-world constraints.
Evolve: Adjusting for new use cases
No design system is ever complete—it’s a living framework. In the early months, for example, I realized the initial font size I chose for axis labels looked clean in mockups but was actually too small in practice. Adjusting it was a small change, but one that improved readability across the board.
An important question in building any design system is: how much flexibility should the components have? At first, I erred on the side of building in too many options. For example, my initial line chart component allowed designers to easily toggle between 7, 14, and 30-day date ranges, as well as control the number of lines shown.
But after observing usage, I realized that most designers only ever needed the 7-day view, and rarely used more than two or three lines at once. All that extra flexibility was creating unnecessary complexity.
So I shifted focus. Instead of making the component endlessly configurable, I refocused the complexity on areas that mattered more—like ensuring the chart could be resized fluidly in all directions. This made the component more useful in practice, while still keeping it lightweight and easy to adopt.
As new use cases come up, I’ve kept that same mindset: don’t be afraid to adjust. The system should be flexible enough to expand to new chart types and interaction patterns without losing its core principles
Supporting Data Literacy
A design system is only as effective as the people who use it. To help with adoption, I led several workshop sessions where designers and developers could get hands-on experience with the new components. These sessions weren’t just about learning the guidelines—they were also about building data literacy across the team. We talked about why certain choices matter, like when to use a bar chart over a line chart, or how to avoid misleading users with scale.
By framing the design system as a tool for storytelling, not just standardization, I saw stronger buy-in and more thoughtful usage across teams. Out of this audit, I created a best practices document to identify common pitfalls and outline recommendations that would anchor the design system moving forward.
Lessons Learned
Start small. Beginning with line and bar charts gave us a strong foundation without overwhelming scope.
Let use cases guide you. Real-world scenarios from our audit and workshops drove every guideline we set.
Leave room to evolve. Systems thrive when they’re flexible enough to change as new needs arise.
Componentize with care. Extra configurability isn’t always better—focus on what designers actually need most often.
