Signs You Are Using Data Visualization Tools Wrong
Signs You Are Using Data Visualization Tools Wrong
And What To Do Instead
And What To Do Instead
As companies collect and analyze more data every day to enable data-driven decision-making, more employees should be equipped with the ability to dig into and make sense of data. At the same time it’s unrealistic to expect everyone in a company to know SQL and be able to pull data from databases directly (wouldn’t that be the dream world?). Low-code or no-code data visualization tools come to the rescue; with the drag and drop functionalities and sleek visualizations, they are all the hype these days.
Looker and Tableau are the two biggest players in the low-code data visualization space. If you have used any of those tools before, you know they are extremely easy to pick up; users can get data aggregated by different dimensions without knowing how to do “group by” in SQL, get demand trends plotted on a map without knowing how to translate lat/long into a geo-point with code, and so much more.
Those tools are great…if you are using them right. But time and time again, I have observed data users, or even data scientists and data analysts, not taking full advantage of what the tools have to offer, and slow down consumption and analysis of data because of it.
Your dashboards contain endless variations of the same data aggregation (treating the visualization tool as a static report)
One of the most useful things most low-code visualization tools can do is being able to aggregate granular data into different levels — day, week, day of the week, you name it; switching from one aggregation to another usually takes only a click. This functionality should enable people who are not familiar with SQL to quickly explore the data on their own terms. But I have seen a lot of organizations using data visualization tools ONLY as static reports —data teams develop a daily view, only to be asked to develop a weekly one, a monthly one, and an annual one on top.
Don’t get me wrong, data visualization tools can definitely be used as a static reporting tool, but that shouldn’t be its ONLY use case. For most senior leadership members, static reports with multiple aggregations are the right way to go. But for the rest of the company, providing data users the freedom they deserve can save the data team and everyone else tons of time and effort and enable teams across the company to move faster.
What to do instead:
If you give a man a fish, you feed him for a day. If you teach a man to fish, you feed him for a lifetime.
Show the non-data-team users the basics of the tool so they are able to filter and aggregate on their own. This will not only give the users more flexibility when it comes to data exploration but also help build the data culture in the company.
2. You have only a small group of people developing dashboards
Point 1 above is a symptom of this issue. Because the rest of the company is incapable of using the basics of these data visualization tools, the development work falls on a small, capable group — usually the data team. This creates siloed tribal knowledge about the data and visualizations. Given the high attrition rate nowadays, the data knowledge can be in danger of getting lost at any moment.
It also defeats the very purpose of using low-code or no-code data visualization tools in your company, considering that their main innovation is that they make data exploration accessible to a broad user base with limited prerequisite knowledge.
What to do instead: On top of what’s already mentioned above, open up edit access to more people in the company; learning how to build dashboards in these tools can be a great stretch opportunity for someone on a less technical team. At the same time, you’ll want to have data experts on call in case someone new to the tool breaks something.
3. You have too much business logic in the tool
Most of the data visualization tools sit on top of data warehouses.
The tools usually provide a lot of space for customization, which means you can do data manipulation and build business logic on top of your data tables in the data warehouse before turning them into visualizations.
This ability to customize can keep teams agile in the sense that if they are familiar with the tool but not SQL, they don’t always have to wait for data teams to implement certain business logic in the tables in data warehouses; they can do it in Looker.
But this agility comes with a price — room for error and multiple sources of truth for the same metric.
To give a concrete example: Suppose there is a table in the data warehouse that has Uber trip information, and it has both trip duration (in minutes) and trip distance (in miles).
One team member creates a Looker view file that defines “average trip length” as the duration in minutes while another team member builds a customized measure “average trip length ” in another file as average trip distance. Both start to develop visualizations showing “average trip length”; their numbers definitely won’t match up and this is bound to cause confusion among people consuming those dashboards.
What to do instead:
Use Looker to test business logic or carry out one-time analyses. For business logic that should be used long term, it’s best to turn to your data teams and embed them into data tables in the data warehouse to ensure consistency.
This will not only ensure there’s a single source of truth when it comes to certain definitions, but it’s also very likely that there are other teams that can benefit from this implementation and don’t have to reinvent the wheel.
4. Your dashboards do not tell a story
I was definitely guilty of this one when I first started using the visualization tools. There was no holistic view or design to the dashboard; rather it was a hodgepodge of different graphs that were the result of constant stakeholder requests for additions and changes over time.
The result? It is incredibly difficult and time-consuming to identify the critical pieces of information.
A good dashboard tells a story, filled with insights and comments to direct users’ attention to the important places.
What to do instead:
Just remember one thing for this one — use comments. Use comments to group visualizations, tell a story and point out caveats. Even better, build in comments with instructions so users know how to explore/filter/navigate the dashboard without needing to slack the owner of it. And if the dashboard becomes too bloated because you keep tacking on additional views, it is worth taking a step back to redefine the purpose of the dashboard and cut down on the clutter (or split the dashboard into multiple ones with a narrower, more clearly defined focus).
5. You are not exploring the tool’s functionalities in detail
I get it, sometimes even for data scientists and data analysts who are familiar with programming languages, learning customization of the visualization tools can feel like a chore.
But I encourage you to give it a chance and read some documentation; you will realize they have endless functionalities to explore. If you cannot figure out how to do something in Tableau or Looker, it can be tempting to stick to what you already know and build the visualization in R Shiny, for example. But trust me, investing time in mastering these visualization tools will pay dividends as they are more powerful than they seem at first glance.
What to do instead:
Well, simple, don’t be afraid of learning new things and spend some time on reading documentations and becoming an expert in the tool. This initial investment will save you tons of time down the road as many things are much easier to implement in Looker or Tableau than to code from scratch once you get the hang of it.
Don’t know what to read next? You might be interested in the following data science-related articles:
5 Lessons McKinsey Taught Me That Will Make You a Better Data Scientist
towardsdatascience.com
Avoid These Five Behaviors That Make You Look Like A Data Novice
And be a trustworthy, likable data partnermedium.com