Tableau is one of the most used BI and data visualization tools, hence it attracts a lot of attention – both good and bad. Being such a popular tool, there is little chance that somebody from the data domain did not hear about Tableau. This won’t be another post about how bad it is, but our experience using it for one of our projects.
The project goal was to develop a self-servicing BI tool that could be used by non-technical users for easier tracking and monitoring of business processes, insights sharing, and data-driven decision making. These projects often include ETL processes that pull the data from external data sources, process it, and then load it to a data warehouse. The final step included the creation of data marts that are used as Tableau data sources by users. That way users receive relevant data and are able to put all their efforts into dashboard development.
Except for self-servicing, the project included some pre-built dashboards which all users could make use of. This is the part where things become interesting when talking about what Tableau is (not) meant for. We noticed how fast and easy it is to create intuitive and simple charts. Take a map chart for example. Anyone, without any technical background, can create a map chart in a matter of minutes. When compared to the effort the same person would need to put into the development of similar charts by doing it in some programming language data visualization library, it is obvious that Tableau is more suitable for the job.
However, this does not mean it is always better than custom-developed dashboards. As soon as we scratched under the surface and tried to build something more complex than prebuilt Tableau charts, we faced the same kind of issues. All such solutions required unintuitive hacks, out of which some required strong Tableau knowledge and a lot of time and effort to create. The good thing is that a lot of them are well documented on the official Tableau knowledge base. Also, there are a lot of available video lectures on how to create more advanced charts that you can use for faster development.
One of the reasons we did not enjoy working with Tableau is the tedious clicking sequence you need to follow to get the desired output. This is not something that a person from a programming background is happy to do.
Take a doughnut chart as an example. It requires two pie charts overlapped by using the dual-axis option, where one of the pies is resized to fit the inner portion of the bigger pie, and colored the same way as the background. If you think that this is something not to worry about, try creating a gauge chart instead.
This has shown us that Tableau cannot replace the tools we use for our data exploration tasks, as they require much more flexibility to meet specific needs.
Another example has taught us that Tableau is not meant for data preparation and unification. In this case, we had geographical data from multiple data sources which we wanted to visualize on the map. As some data sources had geographical coordinates and others only had city-state labels, Tableau could not visualize all of them on the same map chart. Instead, we decided to upgrade our data preprocessing steps and generate coordinates for each city-state label. This way we unified the data that Tableau knows how to interpret and visualize. Simply said, it’s best to keep Tableau data sources simple and put all of the preparation complexity in ETL and SQL.
Our experience with Tableau has led us to the conclusion that Tableau is not a Swiss army knife for data visualization that will serve as an exploration tool. If you need to create complex charts and you come from a technical background, you would probably want to stick with your favorite programming language data visualization library.
What is your experience with BI and data visualization tools? Which one would you choose for your project?
