Simple Steps for Better Design

A lot of blog posts and conference sessions focus on the technical aspects of Tableau.  How to utilize Fixed LODs, the basics of Table Calculations, how to implement Set Actions and Parameter Actions are all common topics that you’ve probably read about or attended a session on.  Some technical aspects of Tableau may be very complicated or difficult to learn, but generally, it is relatively straightforward to teach and write about them: what is the use case, why would you want to do this, and how do you do it.  In fact, 95% of the blog posts on flerlagetwins.com focus on the technical aspects of Tableau. 

There are some aspects of Tableau that are, in my opinion, much harder to teach and much harder to learn.  One of these aspects is DESIGN.  In fact, search for blog posts or videos on design using Tableau…they are not easy to come by.

When I was young, my favorite classes were math and art.  I had a natural talent for both of them.  When we were young, Ken and I did not do math in our spare time (as we do now), but we loved to sit and draw.  We did it constantly; we drew Transformers, Mad Balls, Disney cartoons, we drew everything, and we were good at it.  In fact, that’s how Ken first described Tableau, “It’s the closest thing to sitting down and drawing like when we were kids”.  (Below are a couple drawings from when we were younger.  I drew Pinocchio and Ken drew the Grinch).

  

Over the years, I’ve had numerous people ask me “how do you draw like that?”  That’s a question I’ve never quite been able to answer.  How do you teach someone to draw well?  When you think about it, I guess it comes down to some natural talent, but more importantly, it probably comes down to practice and watching others. 

Now that I’m older and fairly established in the world of Tableau, I often receive a similar question, “how do I improve my design?”  Again, tough question.  But similar to drawing, I guess it comes down to some natural talent, but more importantly practice and watching others.

Before we get started, please open up the associated viz (companion viz) on Tableau Public.  We will reference this workbook throughout the blog post.  There are very few photos in this actual blog post, so it is important to open the viz.  To navigate through the workbook, simply click through the tabs at the top.  Each tab is labeled in the same way the sections below are labeled.  Go to the first tab and you’ll see that each worksheet provides you with an example of poor design (red and thumbs down) and an example of good design (blue and thumbs up).

This blog post (and associated viz) is dedicated to design.  My definition of design is used relatively loosely and will cover some aspects of color, layout, alignment, aspect ratio, size, and several other topics.  This blog post and viz is not intended to teach you everything about design, but is intended to provide you with some simple steps to improve your design.  I will not get long-winded in this blog post; I will simply reference each tab of the workbook and add a bit of commentary as to why I think that something works and why something doesn’t work. 

I intend to speak very little about chart selection, analysis, etc.  I will focus solely on design.  Please also remember that these are best practices that work in the majority of situations - they are guiderails.  These are NOT hard and fast rules as there will always be nuances in your situations, which will affect the decisions you make.  Oftentimes, as Andy Cotgreave says, "it depends". 

Before I move on, I want to give a special thanks to Ken Flerlage and Sarah Bartlett for helping me brainstorm on ideas for this blog post.  I also want to give a HUGE THANK YOU to Jeff Shaffer who spent a ton of time working with me on the content of this blog post and the viz; it would not have been possible without Jeff.  That said, please note that the information contained consists solely of my opinions, which may not align perfectly with Jeff, Ken or Sarah’s views. 

If you’ve not already done so, please open up the associated viz and go to the Titles tab (again, simply use the tabs at the top to navigate through the workbook). 

1.     Titles

This one is pretty simple: add a title to your viz.  It’s important that your readers / users have some context.  They should immediately have some understanding of what this visualization represents.  There are many suggestions of how to use titles; you can ask a question as a title, you can provide an insight as part of the title, or you can simply provide a topic.  I’m not here to suggest than any one of these are better than the others (although I’d probably say it depends), all I am suggesting is that you include one.

2.     Grid Lines

Grid lines can be useful to help readers understand your chart and the values it represents, but don’t use them in a way that they distract from the visuals.  I recommend that grid lines be made very light in color and width or removed completely from the visualization (especially when labels are being used).  If you choose to utilize grid lines, use them sparingly.  I also rarely use both horizontal and vertical grid lines at the same time; I prefer to show just one or the other based on the orientation of my visualization. 

On the Grid Lines tab of the associated viz, I chose to utilize a small number of very light grid lines.  This helps provide context to the user and balances the text by using axis labels versus labeling each of my 17 bars.  (Should you need more precision, you may opt to label each bar or simply label the highlighted bar).

Have you opened up the companion viz yet?  If not, you probably should...this blog post will make a lot more sense with it open 😏

3.     Hex Map Shapes

This is a common problem that I see with many Tableau developers – they use the wrong hexagon shape in their hex maps.  This is all about making your hex map look nice.  If you utilize a horizontally oriented hexagon shape, your hex map will not tessellate (fit together) properly.  The reason for this is very simple…the original X, Y coordinates developed by Matt Chambers doesn’t use horizontally oriented hexagon shapes, it uses vertically oriented hexagon shapes.  You could, theoretically, develop a new set of X, Y coordinates to allow you to use horizontally oriented hex shapes, but why?  Simply use the vertically oriented hex shapes that the X, Y coordinates were designed to utilize.  In addition, please ensure that you are using an equilateral hexagon shape.  If you do not, then you will have the same problem as you did with the horizontally oriented shapes.

As a side note, this is not a problem when using shapefiles.  For a full history of the hex map with links to a variety of hex map options, please check out my What the Hex blog post.   

4.     Hex Map Spacing Part 1

Don’t leave a ton of space between the hexagons in your hex map.  Honestly, it just looks weird!  It also wastes space and seems to cause the labels to not center properly.  I always advise people to make the hex shapes as large as possible within your space, without overlapping, and ensure that there is equal spacing around every side of each hexagon.

5.     Hex Map Spacing Part 2

Don’t leave more vertical spacing than horizontal spacing between your hex shapes.  Honestly, it just looks weird! (Deja vu).  I see this all the time and it just looks a bit sloppy.  As mentioned in the previous paragraph, ensure that there is equal spacing around every side of each hexagon.

6.     Rotated Text

Rotated text is difficult to read.  Many studies have proven that it takes much longer to read rotated text.  Therefore, it is generally best to avoid using rotated text. 

Look at the “bad” example in my workbook.  In order for me to read the text, I literally have to turn my head counterclockwise about 90 degrees.  Why make your reader work so hard?  In most cases, you can utilize horizontal text, even if abbreviated, and you can utilize an additional discrete pill to provide additional context.  In my “good” example, I abbreviated the months to a single letter at the bottom and added year at the top.  Not only is this chart much easier to read, but is also much cleaner.

7.     Floating Bars

Don’t float your bars, but rather, give them an axis to sit on.  This piece of advice comes directly from Jeff Shaffer and is one of the first things I remember him telling me when I first started working for him.  Ryan Sleeper suggested the same thing in his Beautiful Bar Charts blog post when he said, “add a solid foundation for the bars to sit on”.  Some people may disagree with this concept and that’s okay, but it’s become something that I do with most bar charts that I create.  One of the few exceptions is when I use bar charts for marginal histograms. 

8.     Categorical Colors

When you have a large number of values, don’t use a different color for each of them.  It’s not helpful at all.  Look at my “bad” example.  What do the additional colors offer you?  Sure, it gives you a different color for each sub-category, but the sub-categories are already labeled.  So I’ll ask the question again, what do the colors offer you?  The answer is nothing.  They don’t help a thing; in fact, they make the chart more confusing as the different colors suggest some type of meaning, when they actually have none.  Ultimately, this wastes people’s time trying to interpret why the difference in color exists and to be perfectly honest, it just looks ugly. 

Please note that there are certainly times when using color for different categories makes sense.  As mentioned in the prelude, these are not hard and fast rules that apply to every single situation, they are simply guiderails; they are best practices that work in the majority of situations. 

9.     Color Deficiency

Much has been written about color usage in dataviz as it relates to people with color deficiencies.  To be quite honest, there is absolutely no reason for me to reinvent the wheel with this one, so I will simply encourage you to read Jeff Shaffer’s blog post Designing Color-Blind Friendly Visualizations. 

I will make just a few notes as it pertains to the example in my workbook.  Red and green colors are often discussed and can be a major problem, but perhaps an even bigger problem is using similar color tones, such as the red and brown in my “bad” scatter plot.  Generally, blue works well with most colors (like the orange I used in my “good” example). 

With all of that said, you should always use a color-blindness simulator when choosing colors for your visualization.  My favorite is Coblis.  It allows you to upload an image then check how those colors work for a variety of color deficiencies.  Below are some examples of what the red / brown and blue / orange scatter plots look like through the eyes of people with various color deficiencies.  You’ll see that the red and brown colors are barely distinguishable in most of these views, but that the blue and orange are very easy to distinguish from each other in every view.  Please note that the two most common types of color blindness are deuteranomaly and deuteranopia.

Normal:

Deuteranomaly:

Protanomaly:

Tritanomaly:

Protanopia:

Deuteranopia:

Tritanopia:

10.  Highlight Tables

I commonly see very wide highlight tables and heat maps.  Unless you are using long labels, this practice is generally a waste of space and makes it more difficult for the viewer to make comparisons across the table.  And from a personal design perspective, I just don’t like the way wide tables look. 

For highlight tables and heat maps, I advise designers to make the cells square or nearly square.  It simply looks cleaner and saves space.  As a side note, in most cases, I would typically add marginal histograms to provide additional context to heat maps and highlight tables (note that this is not shown in the associated Tableau workbook).  For more information on marginal histograms, check out the marginal histogram blog post from The Data School.

11.  Stacked Bar Charts

The overall problem with stacked bar charts is that it is difficult to compare all values with the exception of the values nearest the axis.  In my “bad” example, it is easy to compare bookcases across each quarter and it is easy to compare overall sales for all sub-categories.  However, it is very difficult to compare accessories, appliances, and binders because they are not aligned with one another – they start at different positions. 

I tend to break by stacked bar charts into multiple bar charts instead.  This makes it much easier to compare values as each set of bars is on its own axis.  If you are interested in the total, you can add a grand total bar chart as well.

There are numerous other ways to redesign stacked bar charts for easy comparison by implementing interactivity.  Steve Wexler wrote about one method in which he allows users to move values to the axis for comparison.  For more information, check out his blog post “How to take the “screaming cats” out of stackedbar and area charts”.  As a side note, this blog post was written over two years ago before parameter and set actions existed.  When speaking to Steve, he told me about his intention to update this blog post to utilize these features, as they are much more efficient.  Ryan Sleeper recently released a blog post that addressed just that, how to reorder stacked bars on the fly.

12.  Pie Charts

Pie charts…good ole’ pie charts.  There has been so much written about pie charts that I won’t go into detail here.  However, if you choose to utilize a pie chart (or donut chart), try to keep it to no more than three slices, preferably two.  Also, remember that a pie chart is a part-to-whole visual, which means it should be expressed as a percentage.  (If using one, I recommend that you also add labels - at least add a label for the slice you are focusing on).  With all of this said, in nearly every case, I prefer a bar chart. 

For more information on why a pie chart is a poor dataviz decision, check out this great article from Robert Curtis: Friends Don’t Let Friends Make Pie Charts.

13.  Radial & Waffle Charts

First, let me say that radial charts are rarely best practice in a work environment, although they certainly have use cases.  That said, this is not a blog post about chart selection, it is focused on design.  Should you choose to use a radial chart or waffle chart in your personal or professional life, then don’t squish them.  By squishing a radial chart, the length of the measures are distorted (it doesn’t have the same impact on waffle charts, however).  In regards to design specifically…squished radials and waffles simply look yucky! 

When using radial charts or waffle charts, try to maintain an aspect ratio of 1:1.  This means that your radial chart will be a perfect circle and your waffle chart will be a square.  They will be easier to interpret and will look much nicer.

14.  Labeling

Many designers tend to over-label their charts.  Adding labels for every value will often clutter your viz to the point that it is illegible.  It isn’t needed at all. 

Take the “bad” line chart in my example workbook; this chart has a y-axis showing the values as well as labels on every point.  If you show an axis, then you most likely don’t need to show any label at all, after all, that’s the purpose of the axis.  For line charts specifically, I try to trim labeling down to just a couple of values such as min & max, line ends, or values you would like to highlight.  In fact, in my “good” example, we probably could get rid of the y-axis all together and just utilize the two labels (or do the opposite and remove all labels and leave the y-axis).  In general, try to remove clutter by removing unnecessary labels and axes.

15.  Icon Usage

When using icons in your data visualizations, consistency is key. Don’t mix and match styles within a single viz.  For example, don’t use a mix of filled icons and outline icons in the same visualization.  In addition, keep your icons simple; don’t use icons with intense detail. 

To be perfectly honest, there is no reason for me to dig into this any further, because Chantilly Jaggernauth did an incredible job explaining it at TC19 in her presentation Design Secrets for a Non-Designer.  Check out her video at the 23:41 mark where she speaks in detail regarding the usage of icons.

16.  Maps & Backgrounds

Maps can be so beautiful, just go look at the work of Jonni Walker.  But a lot of maps don’t look beautiful and one common reason for that is the due to the background.  In my “bad” example, the map looks like one big square.  It does not blend into my dashboard well at all. 

I recommend that you try to get your map to blend into your dashboard as much as possible.  One technique is to remove all layers including the base layer (as shown in my workbook).  This will yield a map of everything in your data, but nothing more.  The problem is if you have gaps in your data, for example, if you don’t have data for several US states, you’ll have holes.  (Check out the Minimalistic Maps blog post from Jeff Shaffer that discusses this technique). 

Another technique is to use a map style that matches your dashboard background color more closely.  As an example, if you are using a white background, you can use a light map with minimal layers to blend it better with your background.  You’ll still get some “blockiness”, but it will blend it much better.  In general, I still prefer to remove the base layer when possible (as shown) to get cleanest possible look.

17.  Transparency

A common problem I see in data visualizations is lack of transparency in charts with overlapping marks.  When no transparency is used, it makes it very difficult for users to distinguish marks from one other and it is impossible to see the density of marks when they are stacked on top of each other. 

For charts with overlapping marks (scatter plots, jitter plots, etc.) it is best to apply some transparency (reduce opacity) in order for individual marks to be seen.  In addition, I typically add a light border to the mark (I like to use a border that is the same color as the background).  Transparency in conjunction with a light border allows your users to see the individual marks and mark density much more easily. 

18.  Diverging Colors

Tableau comes loaded with a long list of color palettes.  Some are diverging color palettes and others are sequential color palettes.  Diverging color palettes consist of two colors on each side of the range with a lighter color in the middle.  Sequential color palettes consist of one color that fades from light to dark.  Below are examples of both:

Diverging: 

 

Sequential:

The rule of thumb is that you should only use diverging color palettes when there is some specific value in which the data should be compared.  For example, you may compare figures to zero, to the average, or to a target.  Generally, there must be some natural midpoint.  If no natural midpoint exists, then a sequential color palette should be used.  If the data you are visualizing does not contain a natural midpoint and you choose to utilize a diverging color palette, your visuals will do nothing but confuse your audience. 

Check out the examples in the companion viz.  The bad example is very hard to understand quickly.  How are sales for Texas?  It takes too long to interpret.  The good example is easy to understand immediately.  You can quickly see that Texas is somewhere in the middle as compared to other states.

19.  Wide Charts

Earlier, I mentioned some of the problems with very wide highlight tables and heat maps, but the same applies to just about any chart.  Making a very wide bar chart, for example, rarely provides any additional context and actually makes them more difficult to read.  Reducing the length of your charts will typically provide the same context while increasing readability and saving space. 

20.  Number Precision

Don’t go overboard with number precision.  Unless you are a NASA engineer, you probably don’t need to your percentages to extend out to four or five decimal places.  In most situations, one decimal place (or even zero) will work perfectly fine and in turn, will increase the readability of your numbers – compare 38.1382% to 38.1%.  The same concept applies to very large numbers.  If you are dealing with figures in the millions of dollars, it is unlikely that your audience needs to see the figure down to the last dollar, i.e. $8,682,317.  In most cases, you can simply use one decimal place and then use display units (thousands, millions, billions), i.e. $8.7 M.

As a side note, I often display my figures with less precision as a BAN and provide a tooltip that shows the exact figure with additional precision.  I wrote about this in a recent blog post.

21.  Color Encoding

Color may be a dataviz practitioner’s most powerful tool, but with great power comes great responsibility.  As Eva Murray states in her Forbes article, The Importance of Color in Data Visualizations, color can evoke emotion, highlight, create associations, and much more.  Color is powerful. (Note: this is a fantastic article and you really owe it to yourself to take the time to read it in full).  

When we use color in a data visualization, it should be used in a way that ties elements together.  For example, if sales is reflected with a blue BAN and profit is reflected as a green BAN, then the associated chart should not show sales in green and profit in blue.  The BANs teach us that blue = sales and green = profit.  If done properly, you allow your user to understand information much more quickly than if it were in black and white.  The problem with color encoding is that if done improperly, it comes at a much higher cost. 

Take the “bad” example in my workbook.  In this case, I encoded the corporate segment in yellow and the consumer segment in light blue.  In a second chart, I encoded the furniture category in same yellow and office supplies in the same light blue.  If these charts are near each other (as they are in this example), we will most likely confuse our reader as they have been taught that yellow = corporate and light blue = consumer.  Modifying the colors for furniture and office supplies immediately removes that confusion.

I should state that, like everything in this blog post, it depends.  If charts are clearly labeled and separated to some degree from one another, I think it can be okay to utilize the same colors.  In addition, I wouldn’t want you to use 20 different colors in a single data visualization in attempt to make everything a different color. 

22.  Map Zoom Control

If you are using a map that is focused on a specific region or area, be careful when allowing zooming.  The issue is that one false swipe of a mouse wheel will blow up your map.  To see what I mean, hover your cursor over the “bad” map in my workbook then scroll the mouse wheel.  You’ll see it move all over the place!  This is a problem because so many people use this mouse wheel to navigate throughout a viz (I personally do) and when they hit the map, it blows it out of the view you intended for the reader.

If you are using a map that is focused on a specific region, just turn of the Pan and Zoom map options to ensure this accidental movement does not occur.   

23.  Element Alignment

When you go to the Element Alignment tab of the workbook, you’ll quickly notice the misalignment on the left-hand side.  Unfortunately, this is a common problem with Tableau dashboards.  It is key that you design to a grid.  

One way to control this is to tile your workbooks.  If you add padding to your charts (which I almost always do to create some white space), then ensure that you use the same padding for charts to ensure that they are aligned.  If you are using floating elements, you should go to Dashboard and select Show Grid.  From there, use the Layout tab to adjust the position and size of your floating containers to ensure that they align to that grid. 

24.  Buttons

Buttons were introduced in Tableau about one year ago in version 2018.3.  Buttons allow you to easily navigate from one dashboard to another.  Buttons can also be used to show and hide floating containers (collapsible containers). 

As a general rule of thumb, I never use the standard buttons provided when adding a dashboard navigation button or show/hide container button.  These buttons are far too generic and provide no information as to what you are interacting with.  In addition, I personally don’t like the way they look. 

I typically create a very simple button in PowerPoint, which consists of text and a rounded rectangle.  At times, I will also add a small icon.  Custom buttons allow you to provide additional information to the user (you can tell them what the button is used for) and they simply look a lot cleaner than the standard buttons.  For more information on how to create buttons in PowerPoint, please see my Tableau & PowerPoint blog post.

Daniel Caroli has some fantastic designs for buttons (especially for collapsible containers).  Check out his example viz here. 

25.  Fonts

Fonts are a common problem when publishing visualizations to Tableau Online or Tableau Public.  According to Tableau: “Tableau Public and Tableau Online support fonts officially licensed for our Linux servers. Other fonts cannot be guaranteed to display as expected, since browser rendering of fonts depends on fonts being installed on both the server and client devices.”  A list of these supported fonts are shown on the “good” side of the Fonts tab within my Tableau workbook.

In general, if you don’t use a font from this finite list of supported fonts, you are not guaranteed that it will render properly for your viewer.  In my workbook, I used four custom fonts that I had downloaded onto my laptop.  The four fonts are shown at the top of the “bad” side in my workbook.  I published this viz to Tableau Public then viewed it on my home computer.  All of four fonts rendered completely differently on my home computer – you can see how they looked at the bottom of the “bad” side.  They look nothing alike. 

It is recommended that you simply stick with the web-safe fonts (on the good side).  If you must use custom fonts on Tableau Online or Tableau Public and want to guarantee they will always render the same, it is advised that you bring that font into PowerPoint, save it as an image, and then bring the image into Tableau.  For more information on how to do this, please see my Tableau & PowerPoint blog post.

Tableau Server is a bit different.  You can install custom fonts on the computer that is running Tableau Server in order to guarantee the font renders correctly.  For more information, see the Use Custom Fonts in Tableau Server.

26.  White Space

The lack of white space in a visualization simply makes it difficult to read.  In my workbook, I removed most of the white space from one of my past Tableau Public vizzes.  You can see how messy it looks and how difficult it is to read when the elements run together. 

Ryan Sleeper has a fantastic article about white space.  In the article he says that white space provides three major benefits of:

(1) helping you as the dashboard author prioritize content

(2) helping your end user focus their attention during their analysis

(3) adding some professional design polish which will lend itself to better credibility with your audience. 

In the article, he also walks through how to declutter a visualization by utilizing white space (negative space).  Just like every single one of his blog posts, this is a must read. 

Now take a look at the “good” example in my workbook.  With some added white space, you can see how much easier it is to understand the flow of the visualization, how much easier it is to read, and how much less work it is to engage with the visuals. 

Although our personal projects will likely differ from what we do at work, Hesham Eissa, Robert Janezic, and Samo Drole are absolute masters of utilizing white space in their personal work.  I encourage you to check out their entire Tableau Public profiles.  However, some of my favorite examples of fantastic use of white space are Hesham’s Global Journey of Refugees, Robert’s MusicMemories, and Samo's Rhino Poaching.

Summary

Okay, that is 26 different simple ways to improve your design.  Please remember that these are best practices that work in the majority of situations and there will always be nuances in your situations, which will affect the decisions you make. 

To continue to learn more about design in dataviz, I recommend two excellent sessions from the 2019 Tableau Conference:  Design Secrets for a Non-Designer by Chantilly Jaggernauth (which I mentioned previously) and Beyond Design by Lilach Manheim & Mike Cisneros.  Samo Drole also presented on the topic of design as part of the Makeover Monday webinar series (which was released just days before I published this blog post).  I'd strongly encourage you to watch this as it comes from the perspective of someone who was a designer first, before he even began working in data visualization.  

And that’s it.  I hope you enjoyed the blog post and I hope it has a positive impact on your design.  As always, if you ever have any questions or comments, please feel free to contact me at any time. 

Kevin Flerlage, March 2, 2020 | Twitter | LinkedIn | Tableau Public