DEV Community

Cover image for "One TV with a number on it can be better than the best of managers."
Oryan Moshe
Oryan Moshe

Posted on • Updated on

"One TV with a number on it can be better than the best of managers."

Here at monday.com we are always excited to show off our dashboards to visitors.
No, seriously, it's like the first thing anyone that comes to our offices sees.

We have more TVs than we have employees, and we still fight on what to put on each of them.

A dashboard? Do you mean that thing in my car?


So I guess we should begin with what is a dashboard

dash·board

/ˈdaSHbôrd/

  • a graphical summary of various pieces of important information, typically used to give an overview of a business.

Nothing kicks off a good tech post like a bone dry dictionary definition, but the important takeaway from this definition is that it's wrong.

I mean, it's probably right if you search the dictionary, but it doesn't convey the true meaning of a dashboard.

Let me try it myself:

  • Important information displayed in a correct and engaging way in order to drive people to action.

Much better.

If the data is not important, then there's no reason to display it, and if it's not displayed correctly it's better not to show it at all, as incorrect data is even worse than no data, and if the data is important and correct, but doesn't engage people or drives them to action, what is the purpose of that dashboard to begin with?


All of my data is important!

So how do we define important information? How do we decide what belongs on a dashboard and what can stay in the database?

We have a term called KPI - Key Performance Indicator.
This is usually a number (or a collection of numbers) that everyone in the company understands, and are able to explain the changes in it over time (whether it improved, got worse, and what affects it in general)

We have a different KPI for every team and use case. Sometimes it's easy to define, sometimes it's hard and we have to use proxy KPIs (numbers that we know affect our main KPI in indirect way) and sometimes it's just "impossible" to find (more on that later)

KPI Engineering

Finding KPIs is a true artform, it takes time to hone that skill.
Some rules of thumb for a good KPI are:

  1. It should be measurable
  2. It should change frequently ("frequent" is a relative term, that varies from one business to another)
  3. There's a clear indication on which direction is better (should we drive it up or down)
  4. People in the company should be able to move it

Qualitaitve VS Quantitative


Sometimes it's simple to measure your KPI (quantitative), for example our Customer Success' team main KPI is their response time, and their goal is to answer a ticket under 10 minutes. Simple enough, just collect the data from Zendesk and calculate the Average response time.

But sometimes it's not as simple, sometimes your KPI is qualitative, meaning you have to deduce it from people's reaction to your work. This could be from high-touch conversations with them, reviews, or surveys they answered. This kind of KPI is not measured as easily and, as such, is harder to display on a screen. For example, my KPI is to make our marketing team work as efficiently as possible (officially we want to help them do 10 times what they were able to do without us), but it's not something we can measure or calculate, all we can do is sit with them, hear their issues and see if we were able to address them.

Proxy KPIs

Some KPIs take time to "mature" - meaning, if we change something in the system, we can only measure them after a maturity period passes.
For example, one of our main KPIs "Conversion to paying" which is basically the percentage of paying accounts out of the total number of accounts.

At first glance it seems simple enough, but the thing is, monday.com has a trial period of 14 days, and usually accounts don't pay until their trial is up.

So, if we changed something, and it hurt our conversion rate, we would only know about it after 14 days!

To solve that issue we have to find a "proxy KPI", a metric that matures faster than our main KPI, but has a high correlation to it.
One of those proxies in our specific case is the amount of content created in the system. After only 3 days we can know (with relatively high certainty) whether an account is going to convert into a paying customer or not.

Keep tuned for another post solely dedicated for KPI engineering!


Correct? Of course my data is correct!


Now, I'm sure your data is correct just like ours is! But the way you display your data is just as important as how accurate it actually is.

I can talk for hours on how to "hack" data and display it in a way where it shows something completely wrong in a very convincing way, but for now I'll settle for 2 examples of data hacking.

Before starting, it's important to reiterate that if you display your data incorrectly you're lying to yourself and your company, and it makes you think you're in a place you're not. If you don't display your data correctly, you might as well not display it at all.

Hiding data


The first, and most naive way to "hack" your data is just to hide the right stuff. Do you have a cohort of accounts that misbehaves? Just remove it from the graph!
Displaying multiple graphs of metrics and your churn graph is on the rise? Just remove that block!

Doing so will make you look better by hiding the worst things in your data. The problem is it'll hide those things from you as well, and you can't learn from your past mistakes if you bury them underground.

Axes scaling

Another, less obvious way to show your data incorrectly is by not locking your axes, the byproduct of which is increased vulnerability to graph manipulation you wouldn't even be aware of.

If you make your graph narrower, but not shorter, you will put more weight on to your Y axes, making smaller changes in your graph look much more dramatic.

Just in case I wasn't clear here are two examples, one of an incorrect graph, with scaleable axes, and another of a correct graph in a dashboard, where the axes are locked.

Here's how not to do it

And here's how to do it

Picking the correct visualization

Another part of displaying your data correctly is picking the correct visualization to display it.

Not all visualizations work on all kinds of data!
For example, a time series (continuous data where your X axis is time based) should usually be displayed in a line chart.
A stacked time series (where the Y values of multiple series can be summed up to receive a meaningful number) should be displayed in an area chart (just like line chart, but the area under the line is colored as well)

Categorical data is usually best visualized using a bar chart, but if all categories are a part of a bigger number then you should probably use a pie chart.

If you have more than 1 dimension to display (for example, displaying both the number of visits to a page, and how much they cost you) you should use a bubble chart. Or a heatmap! Speaking of heatmaps, those are also good at displaying a weekly time series and correlation matrices.

Bottom line, there are so many visualizations, each one fitting a specific use case, and if people don't understand your data at a glance it's a good signal you should rethink your chart types.


Engaging? How can numbers be engaging?


Here's the best thing about creating a dashboard. You have to make people care about it!
Creating an important dashboard, with the correct visualization just isn't enough. I created countless dashboards that aren't in use just because they weren't engaging.

Visual cues

Sometimes all a dashboard has to do to display data in an engaging way is just to find the right way to drive people forwards.

For example, one of our Customer Success' team main KPIs is having a response time of less than 10 minutes, so everytime there's a ticket in the queue for more than 10 minutes they see it on their dashboard burning in flames.

Or "The Grid", which displays both product and technical alerts for company-wide usage, that is usually completely green, but when something turns red it's immediately visible and can be easily inspected using our touch TVs.
This makes people want to keep The Grid green at all times.

Or our "Celebrations" overlay, which allows us to display a celebration with an employee picture, confetti and a short message whenever we want (for example, when one of our consultants closes a big deal with a customer.
Everyone wants to celebrate their successes, and that's a nice way to drive people to succeed.

Mobile responsiveness

Don't underestimate the importance of mobile dashboards!
Many people want to know they're current state on their way up the elevator, or between meetings.

Some people don't even have time to sit by a computer! If your dashboard displays an important metric that people would want to consume often (like "The Grid") it should look as good on mobile as it is on desktop. It also fuels the "addictive" nature of dashboards, which is awesome for you!

Sounds

Your TVs probably have speakers built in, and you can use them! Many of our dashboards make sounds whenever something important happens.
There's a "gong" sound when the consulting team closes a deal, music when a customer starts paying, notifications when someone starts deploying to production, or alerts when deployment to production fails.

It is important not to go over the edge though, as many people started muting the TVs after we started having many paying customers every minute, each making a sound. We had to decrease the frequency of those sounds.

Summary

In conclusion, dashboards are the thing that drives our company forwards, without them displaying important information in a correct and engaging way, we wouldn't be able to get to where we are right now, and I think any company that wants to succeeded should be data driven and make sure it has the right dashboards for the job!

Top comments (1)

Collapse
 
udiudi profile image
Udi • Edited

I read the description on Twitter and had a strong feeling someone from Monday wrote this. Well done :)