Data visualisation framework
Overview
First, here’s a peek behind the scenes, if you’d like to explore the full design system.
Market research runs on data, but data only matters if people can actually understand it. When I joined Cint, it was clear my data visualization experience was part of the draw. As Cint’s products grew, so did the need for data visualizations—but we faced two main problems:
Designers and product managers weren’t sure which charts best represented their data or how to style them.
Developers struggled with custom design decisions, slowing down development.
The timing was perfect—most of our products were either in development or set for rebuilding next year. It was the ideal moment to introduce a standardized approach.
Success meant clear adoption: product teams consistently using the new standard, reducing decision-making effort, and speeding up the design process for data visualizations.
Research
I had a hunch that we needed two things:
A chart selection framework accessible to designers without data viz experience.
A library of ready-to-use templates, built with the design system team.
But I wasn’t going to jump into solutions without talking to stakeholders. Even though my main stakeholders were fellow designers, assuming their needs matched mine would miss the point.
Through conversations with stakeholders, I built personas for Product Managers and Designers, surfacing key frustrations:
Uncertainty about best practices and which charts to use.
Not knowing if similar charts already existed within the product.
Repetitive design work due to missing components.
Feeling restricted by the limitations of the current data vis framework.
To ground my approach, I audited all products, documenting existing visualizations and identifying gaps—like the ones shown in the audit snapshot below.
Solution
The solution had four parts:
A framework for chart selection
Best practices for all charts—covering formatting, accessibility, and color usage.
Best practices for each chart type—detailed guidelines tailored to specific charts.
Flexible, responsive Figma chart components (If you’re a designer, you know how crazy ambitious this is).
The idea was simple: once designers knew which chart to use and understood the basics, they could dive into specific guidelines for each chart type and use ready-made components instead of designing from scratch.
I started by building a chart selection framework for the most common scenarios (Figma link).
Then, working with the design system team, I created guidelines covering general best practices, including formatting, accessibility, and color usage (Figma link). Next, I developed detailed best practices for each chart type—providing designers with clear instructions on how to use each component effectively (Figma link).
The real challenge was the Figma components—the most complex I’ve ever built. Collaborating with the design system designer, we brainstormed how to make them both flexible and responsive. Figma nerds, this one’s for you.
Everything was built on a grid system, with each chart type having its own components (like bars for bar charts). This setup allowed us to have a single, responsive master chart component with easy control over chart type, legend, and header. And the best part? Every chart type was customizable while maintaining visual consistency.
Impact
The data vis framework was fully adopted by the product team, and the engineering team adjusted their setup to make these components work seamlessly. Before long, data visualizations started appearing across our products—dashboards, complex tables—all guided by the framework.
What surprised me was the positive feedback from outside the tech team. People creating presentations loved it—they didn’t have to second-guess their chart choices, and everything they used was visually consistent with the brand’s look and feel. It made their presentations clearer, more polished, and more impactful.
