DEV Community

Cover image for Tips on Designing a Million Dollar Dashboard
SeattleDataGuy
SeattleDataGuy

Posted on

Tips on Designing a Million Dollar Dashboard

In the past few weeks, we have watched Tableau be purchased by Salesforce for 15.7 billion dollars and Looker for 2.7 billion dollars by Google.
Why are these companies so valuable?

Why are so many companies willing to pay for the services that Tableau and Looker provide?

The truth is dashboards can be expensive wastes of time and resources or they can provide insights that are worth exponentially more than the original investment. In fact, creating dashboards is a very lucrative business.

I worked for a company whose business model revolved around selling dashboards and insights to external customers. We only had four dashboard products. That was it, and yet, this company has existed for over a decade.

This is because they were really good at creating dashboards that provided impact continuously. These weren’t dashboards that you use for a month or two and forgot about. Instead, the dashboards they created were concise, clear and helped directors make decisions quickly.

They were able to do this by creating dashboards that followed a few basic principles. We wanted to share some of these basic tips below. Who knows, maybe your team will build the next million dollar dashboard.

Don’t Bury the Lede

When developing a dashboard, you need to first entice your audience with a high-level metric. This could be the total amount of money lost in insurance fraud for the year, a ranking that highlights how well a company is doing, or perhaps a trio of specific metrics.

The point of these high-level metrics is to pique interest. It needs to capture the audience and force them to ask questions and keep digging deeper into the dashboard.

Specifically, you want them to ask questions like why is the number so high or low and what are the factors driving this number?
Let’s walk through an example (see the dashboard below):

Alt Text

Source: Tableau

This dashboard is actually pretty well done. It is clean and provides very succinct information.

However, there is no initial draw. There is no distinct sign of whether the company’s income is bad or good.

So why should I be interested? I don’t really have any questions off the top of my head because I wasn’t primed to do so by any driving metric or dollar figure.

Having the dollar amount that depicts how far off target the net-income is in the top-left corner along with the percentage would have been a good design decision. This set of numbers would drive me to ask the right questions. Specifically, why is the net profit above or below what is expected?

This would then drive the end-reader to look into the charts below. Net profit exists on this dashboard, but it is hidden in the corner. Essentially burying the lead.

The most important information should be prioritized to the top of the dashboard.

Focus on Substance and Style

Creating a great dashboard is like working as a chef in fine dining.
If you focus too much on the aesthetics and not on flavor, your food will taste terrible. If you put no focus on aesthetics, your customers won’t see the value in your $50 salmon and carrots dish.

It can be tempting to create very flashy dashboards with all the bells and whistles. Similar to the way it was tempting in the early 2000s to throw foams, spheres, and gels on every dish in the fine dining world.
But bells and whistles don’t tell a story.

They can accentuate it, but they can also distract the end-user and make it more difficult to make a clear decision.

So focusing too much on style will hinder rather than help.

On the flip side, presentation is important too. Presentation can entice an end-user to pay attention, even if you have bad data. For example, let’s look at this beautiful dish below.

Alt Text

Created by @chefjacqueslamerde on Instagram

…wait…thats just celery, peanut butter, and raisins…

But, somehow, it looks like so much more. Even bad data can sometimes be forgiven by a beautiful dashboard (this is not encouraging bad data!).
We are trying to accentuate the fact that design plays a role in how we perceive information.

As data professionals, we can sometimes focus solely on the numbers and metrics. Numbers alone don’t capture peoples interest the same way it might capture ours. Capturing peoples attention is where design principals come into play.

Again, if we look at the net income dashboard, it is clean and has a very simple style. It is pretty clear to get what is going on in each chart. Often people assume that having lots of bells and whistles make a beautiful dashboard.

It is actually usually the opposite. Keeping a dashboard simple with only the data required makes the message clearer. If you have too much going on you muddy the message and could confuse the end-user.

It’s almost like a dashboard’s UX should be treated like a website’s UX.

Don’t Hide Too Much Behind Interactions

We have mentioned a lot about avoiding bells and whistles because they often deteriorate the message you are trying to tell with a dashboard.
One more specific feature most dashboards allow for are filters and tool-tips. These are great in some ways until you put too much information behind them.

Requiring too many interactions from an end-user to get to data could dilute the message you are trying to depict.

Rule of thumb: If you can’t print your dashboard and tell your same story, then you have too much information hidden behind tooltips and filters.

One example of this is providing one too many filters that might interact with varying widgets on your dashboard. This forces the end-user to need to flip through multiple states of each widget to get the message you are trying to tell them.

Sometimes our desire to over-inform only further hinders the message. Dashboards are about prioritization of information. You should only be showing the most important information that can help an executive make a clear decision.

Most directors will want lots of options to slice and dice the data, but that doesn’t mean that you should do it. Too many interactions may push them to continually analyze new configurations of filters vs. making a decision. This means you will have to push back for a better design.

Provide Context

When you create dashboards you can often create them in vacuums. Teams often create dashboards or metrics and don’t realize that other companies or teams might not know what is going on. Especially when you start to create custom metrics.

This is why we recommend providing context for the metrics, the dashboard purposes, and the axes.

The metrics

Regardless if you assume your metrics are well known or esoteric. Defining what the metric represents in a clear and concise manner benefits everyone. This also forces teams to use metrics that are easy enough to explain to an end-user. Some teams might create super complex models to calculate metrics, but this often abstracts the value a metric can have. Instead, you should focus on simple metrics that you can explain to anyone.

If you can’t understand a metric, you can’t make decisions.

The dashboard’s purpose

The first time an end-user experiences a dashboard, they might not know why they are looking at it. Putting together a few sentences of what a user is looking at can help better frame their understanding. In many ways, you should strive to not require a summary, but it’s always good to have. Similar to documentation with code.

Good code should require little documentation, but that doesn’t mean you shouldn’t document your code! Always document everything.

The axes

How you define the axes isn’t always straight-forward. You want just enough tick marks that end-users can understand what the line charts and bar charts mean, but you don’t want so many ticks that it is confusing. This comes down to good judgment. For instance, when you are using a sparkline, you will often limit the tick marks, but if it is a main line chart, you will probably provide more context along each axis.

The Devil is in the Details

High-level metrics usually provide the “what” but not the “why”.

The high-level metrics push users to look for answers.

What is driving the high-level numbers like net profits?

Thus, the next level of your dashboard should help answer these questions.

This means you need to look at the top metric and think about what questions an end-user might have looking at it. At this step in your dashboard development process you should try listing out what questions you would have as an end-user. It is helpful to have a member or two of your team who hasn’t seen the dashboard yet write out their questions. That way you have a fresh pair of eyes.

Based on these questions you can start to create secondary dashboards that provide the required insights.

Tableau has a great feature called actions. This can allow you to create easy drill-downs that go to more detail specific dashboards.
The goal here is to provide high-level metrics and low-level details that can help directors make concrete decisions.

Conclusion

These are a few great tips we have learned from working for a company whose sole purpose was creating dashboards to provide value to external customers. We hope it helps you create amazing dashboards that can create value for your company. Remember to focus on creating dashboards that don’t bury the lede and allow directors to make good decisions easily. That is how you make a million dollar dashboard.

To contrast, too many bells and whistles and poorly designed dashboards can lead to bad decisions or no decisions.

If you have any questions feel free to send them our way!

Also, feel free to read some other posts
Hadoop Vs Relational Databases
How Algorithms Can Become Unethical and Biased
How To Improve Your Data Driven Strategy
How To Develop Robust Algorithms
4 Must Have Skills For Data Scientists
SQL Best Practices — Designing An ETL Video

Top comments (9)

Collapse
 
alanhylands profile image
Alan Hylands

Great post. I'm hoping to see greater design practices evolving for dashboard creation as the tech (and business use of them) grows.

Too many times I've seen everything bar the kitchen sink (and sometimes the sink as well) being thrown at the one dashboard. All that leads to is information overload and the dashboard gets consigned to BI purgatory.

Keeping it simple and to the point is half of the battle but easier said than done when a committee room full of interested parties start chipping in with their demands.

Collapse
 
seattledataguy profile image
SeattleDataGuy

I have seen many a dashboard in BI purgatory. It is sad when you realize that there are hundreds of thousands of dollars spent on each of these dashboards that just overwhelm the end-user.

Collapse
 
adityamenon profile image
Aditya M

You know what would be cool? If (cough) someone (cough I wish I could) build a real-time dashboard visualising the key metrics of the Roman Empire (as the leaders would’ve seen it) in a modern UI 😃 it combines my two favourite things: technology and geopolitical history!

Collapse
 
adityamenon profile image
Aditya M

How would I even go about doing that..? I mean it would be nice to have a “roadmap” laid out for a junior data dev that I could follow... maybe a data science or BI book’s project can be repurposed - any suggestions?

Collapse
 
alanhylands profile image
Alan Hylands

Start small. Have you got a data source to work from? Plan it like an actual business project where the Roman Emperor is your customer.

What would Julius Caesar have wanted to see on his weekly dashboard in terms of KPIs for the Empire? Then build that up one step at a time. Even start with something static in Excel to get a framework together and move it up to Power BI or Tableau when you have a clearer picture of what you want to be looking at.

Sounds like an interesting project, be sure to share it with us when you get started.

Thread Thread
 
adityamenon profile image
Aditya M

It's quite intimidating and out-of-the-way in terms of what I'm doing with my career right now - but if I ever do, I certainly will :D thanks for the info!

Thread Thread
 
seattledataguy profile image
SeattleDataGuy

It would be cool to see! If you do happen to develop this you should share it on Tableau Public or in a blog post.

Collapse
 
adityamenon profile image
Aditya M

That’s a great post @seattledataguy ! I always wondered about dashboards and BI and the idea finally “clicked” :)

Collapse
 
luispa profile image
LuisPa

Amazing post! Thanks for sharing.