Developing a Data Viz Design Library

Figma Design Toolkit and Guidelines
Winter 2020
Role(s): UX designer, technical writer, data viz expert

In December 2019 I began a contract with Microsoft as a UX designer. One of the first projects I was assigned to was a series of data insights for an Azure product. As I was onboarding, the team informed me that they didn’t have consistent rules for how charts and graphs were applied to their products, but they were eager to draw from my background in data visualization to assist them. Over the next two months, I learned how to use Figma, produced dozens of UI wireframes for the insight reports with placeholder data, and simultaneously produced a toolkit of chart and graph elements that I later backfilled into those reports.

Problem: The Azure Data team was producing UI mockups with inconsistent charts and graphs. Without a toolkit, every graph was custom-made and every change was tedious.

Design Process

One thing to note about this project: I didn’t go into this knowing my task was to build a whole toolkit. My original objective was to build UI screens that involved graphs. I quickly realized that the design needed a more systematic overhaul. To do that, I had to dismantle the existing data viz framework (such that it was) and then create new, formulaic building blocks that could work consistently into a cohesive design language.

Another thing to note about this project: I was originally only supposed to advise on the data viz best practices. I collaborated with a few other designers on this and got a quick expert-level Figma lesson from another, but as the other colleagues got pulled into other projects, I found myself making a lot of the decisions, answering a lot of the questions, and writing a lot of the documentation on my own.

Understanding the design problem

Initially, it was a challenge even to understand why there was a problem—graphs already existed across Microsoft products. But this particular group straddled a few different sides of the Microsoft platform, each with their own design languages, and our graphs would need to “fit” our aesthetic without being too much of a jump from the others. I performed a sort of competitive analysis within the company to see how other groups handled their data viz guidelines.

*Some examples of one other team’s data viz guidelines*

The next step was to look at our current designs in progress and determine what was lacking. My team had already been producing mockups before I joined, but there were many inconsistencies. I quickly experienced these problems when I was asked to edit some graphs to show 5 categories instead of 3 and found out that every single bar/line/wedge was its own element that needed manually moved and spaced. When your scenario involves 15+ screens, those minor changes can take hours to update. So I took note of what rules were missing from the existing mockups and what should go into the guidelines.

*My initial notes about what was wrong with the current UI mockups and what I could change in the guidelines*

Creating the Guidelines (First Attempt)

It seemed so simple—just create a new version of the charts and graphs that the other teams used, make some decisions on when and how to use them, and call it our own guidelines. I wish I could tell you it was that easy.

Image of an early version of the data viz guidelines showing the rest state, hover states, and click states for a stacked column chart — My first attempt at new guidelines. These lacked a proper component library so they weren’t helpful.

Figma is a great design tool. It’s very intelligent and flexible, but it takes some prowess to get the most out of its features. For example, a set of guidelines is only useful if the graphs inside are coming from a component library. And those graphs are only going to be extensible if their bars and lines and axes are individual components.

Building the Component Library

I didn’t know where to begin. Should I base a component library starting from the big pieces or the small pieces? How far down would I need to go? My co-worker James introduced me to the Atomic Model of Design Systems and then helped me get started building “atoms.”

It took some time, some careful crafting, some trial and error (note: lots of error) with constraints, and plenty of iterations, but James and I created a full library of chart and graph elements.

Once we had our initial “atoms” and “molecules” in place, we could start building our “organisms”—the cards on which the graphs would live and align with the shell webpage framework. These cards themselves underwent many iterations. They needed to scale to the many sizes of graphs we had as well as handle edge cases like extra legend items and external links.

Image showing the variety of graph types, sizes, and card layouts that can be used in any data visualization mockup — Sample cards for the design library. Designers can now go to this page of the toolkit, copy the card they need, and edit the details according to their scenario.

Documentation and Guidelines (Second Attempt)

The purpose of this whole project was to maintain consistency within the team. Writing out the guidelines was a test of my own internal consistency and I found myself making small edits here and there to make sure everything complied with my own made up rules.

Sample page from the design guidelines showing the layout of a card for a basic column chart — Example page from the guidelines

One thing I learned here is that if building the library was a lesson in visual design, defining the guidelines was a lesson in interaction design. My decisions had to be thorough enough that other designers could apply the rules to their own needs, but flexible enough to still provide an answer for unpredictable edge cases. Every graph needed an example of how it would behave on mouse click and hover. Every card needed an example for 4, 8, and 16+ legend items. Tooltips needed to come in multiple flavors based on the graph and data types.

Image of the Rest State, Hover State, and Click State for a clustered bar chart — Excerpt from the Interaction States section of the guidelines

I also learned that the more internally consistent and predictable my rules were, the less prescriptive I had to be. The guidelines could have stretched on for infinite use cases, but by choosing to keep consistent block sizes and text margins, designers can make educated assumptions if I left anything open-ended.

Conclusion

Building a design language, library, toolkit, and implementing all of it in mockups for active projects has been one of the most monumental projects of my career. It taught me the ins and outs of Figma, how to manage many moving parts at once, and how to seek help when I need it. There were more stories, situations, challenges, and decisions than I could cover in this work sample, but this was also one of the most rewarding projects I’ve undertaken.

As a result of this new data viz toolkit, our team of 10+ designers continues to use these Figma components across dozens of products and features. What once required tedious changes to align graphs and edit legends is now nearly instantaneous by swapping components.