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):
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.
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.
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.
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.
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.
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!
If you enjoyed this video about software engineering then consider these videos as well!
142 Resources for Mastering Coding Interviews
Learning Data Science: Our Top 25 Data Science Courses
The Best And Only Python Tutorial You Will Ever Need To Watch
Dynamically Bulk Inserting CSV Data Into A SQL Server
4 Must Have Skills For Data Scientists
What Is A Data Scientist
Software engineers spend a lot of time gaining skills for interviews by practicing leet code problems and perfecting resumes.
Once they finally get that job at a start-up, Google, Amazon or another corporation you might find the skills they used to get the job don’t tend to match the ones you need in your everyday work.
Our team was inspired by the 7 skills of highly effective programmers created by the TechLead and wanted to provide our own take on the topic.
Here are our 7 skills of effective programmers.
Read the rest here!
We are a team of data scientists and network engineers who want to help your functional teams reach their full potential!