Data Visualization Design Best Practices
Introduction:
You’re in the home stretch: you've defined the requirements, collected use cases, gathered data, completed the data modeling process, and now you are ready to build a dashboard. Being so close to the finish line is exciting, but it is often this last mile that can be the toughest. If you stumble here, end users will find your dashboard ineffective, and all the behind-the-scenes work you did will be for naught.
Here are some tips on Dashboard Visualization Best Practices to avoid that outcome.
Color:
Use color sparingly. Bar, pie, and line charts need to have colors differentiating the categories you’re displaying, but you can also use color to drive actions and decisions. Using red, yellow, and green sparingly can drive users to action. A KPI tile for an underperforming metric displayed in red both gives the user information (this metric isn’t meeting our goal) and can prompt them to action (drilling down to see why). Use those “signal” colors too often, and you desensitize users to action indicators. The signal gets lost in the noise, and your dashboard looks like a Christmas tree during the holiday season.
A good practice is to work with your marketing department to implement an organizational color scheme. This serves two purposes. First, the pages of your dashboard look like the organization owns them natively because they are in line with the look and feel of other company assets. Secondly, it narrows your use of red, yellow, and green because you already have a color palette defined in a style-guide.
Adding company logos to the very top left or right of the sheet (or in a header) can really help your pages look polished without sacrificing space better used for data visualizations. The background of your dashboard sheets should be neutral. You want the focus to be on analytics, not the artwork behind your charts.
Consistent Design:
Users may not say it, but boring is useful. Keeping your Dimension filters on the left and Calendar across the top isn’t inventive, but it is standard. Users become accustomed to the positioning of these navigation and filtering functions. Permeating this design across all sheets in all apps can bring a sense of familiarity to the pages and sheets as well as increase the usability of your apps. Users notice when these items are not where they expect them, and it can lead to confusion, frustration, and change request. You can see this standardization in use by major shopping sites. Anywhere you shop online has a similar location for their navigation, and that design is the same for all pages whether the department is Kitchen Appliances or Books.
Your chart objects should have a similar internal design as well. Keeping titles left-justified or centered and using the same fonts is just a start. Ensure label size and font, date formats, colors for dimension values, etc. are consistent. For example, you can code customer colors to be the same in all bar charts, whether analyzing sales, margin, or receivables. This creates a unified experience for the end user and reduces visual “stress” between apps.
Audience:
This piece is often overlooked, much to a developer’s detriment! Building a dashboard with charts and graphs that the user audience understands is critical. My best advice is to keep it simple. Bar charts, pie charts, and line charts are the most underrated visualizations but also the most easily understood by the end user because they can be interpreted quickly and correctly. Heat and tree maps can look impressive, but they’re also easily misunderstood.
Two great references for further guidance on this are “Visualize This” by Nathan Yau and “Say it with Charts” by Gene Zelazny. In these books the authors get into not only when to use certain chart types, but why. For example, time series analysis is almost always best suited for a line chart because the eye subconsciously follows the line as it traverses the axis of time. It is so natural, you probably don’t realize you are doing it. Well-designed visualizations should feel natural to interpret.
Definition Page:
Adding a sheet, page, or link to a reference document isn’t design element, but it is excellent practice. What should the definition page include? Definitions of your dimensions and measures and the data source. Having a central location where users can go to reference how measures and dimensions are defined has two benefits; the first is to serve as a reference for the user. How is a margin calculated? How is a discount defined? You can also include classifications. For example, what is a “returning customer”? Is it a customer that orders multiple times in a calendar year, or multiple times in a rolling 12 months? Is Gross Sales calculated before or after discounts? Your definitions page can answer those questions for the user, which means you field fewer of them!
The second benefit is that it gives developers and analysts a document to reference when a new dashboard is requested with some of the same measures and dimensions used in your app. Maintaining a consistent vocabulary and definition of measures and dimensions is critical for standardization and continuity. It creates confidence in the data with users because the definitions are set, so it creates a shared understanding for anyone using the app. It also removes ambiguity for developers and analysts, because no discussion of definitions is needed.
There are a few ways to deploy a definitions page. Most simply, add a sheet/page in the dashboard after the sheets with actual data visualizations. It should be aptly named, so there is no confusion on what it is, or the info contained within. The simplest way to execute this is to create a spreadsheet with several appropriately named columns, like Type (“Measure”, “Dimension”, “Classification” …), Name (“Margin”, “Sales”, “Returning Customer”…), with the definitions is a good starting point. There should be two different definitions: a business-friendly definition for non-technical users and a technical definition, for developers, analysts, and other technical folks, that may need more precise definitions.
It is easiest to keep your spreadsheet in a central location where it can be updated and maintained, and your Data Visualization platform can access it. Another way to store this type of document is on a shared site, like Sharepoint or Teams, and then presenting that page in your Data Visualization app. You can also simply present a link to the definitions document. If that’s the route you take, you should find a consistent spot on each page of the dashboard and reserve that spot in every app to link to your definitions page. Choose a spot where it can be noticed, but out of the way. The lower right corner can be good for this, or in the page headers or footers, if there’s space available.
Conclusion:
Creating an analytics Dashboard can be challenging for the developer, but we want using it to be easy for the audience. These best practices can go along ways in creating a simple and easy to use dashboard. Using color sparingly can bring attention to items that call for action, while not desensitizing the audience to what the colors signify. Consistent design won’t be noticed by the end users, but inconsistencies absolutely will when they can’t find that filter they’re looking for! Focusing on the audience and creating a dashboard that is easy to interpret will drive adoption and improve decisions, which is paramount in a data-driven organization. Lastly, having something for the users to reference definitions can give them confidence and independence in the data.
