Charts are often seen as the gold standard for data visualization. They are visually appealing, intuitive, and easy to interpret at a glance. Meanwhile, tables are sometimes dismissed as dense, dull, and overwhelming. But is this perception fair? This article challenges the notion that tables are less valuable than charts and highlights their unique strengths in data analysis. —-

Tables have unique qualities like no other data representation.

Tables organize information into columns and rows, where columns define data categories, and rows capture individual records. This structured format makes tables uniquely powerful in data analysis.

Classic table layout.

Unlike charts, which summarize data visually, tables preserve the full dataset, allowing for precise comparisons, in-depth exploration, and direct access to individual values. Their structured nature provides:

Precision and Detail Unlike charts, tables allow users to see exact numbers, making them crucial for financial reports, operational dashboards, and compliance data.

Flexibility Tables enable sorting, filtering, and drilling down into data, providing a dynamic way to explore large datasets.

Context and Completeness A chart may highlight a trend, but a table provides the complete dataset behind it, ensuring a full understanding of the numbers.

Precision, Flexibility, and Context.

When Tables Outperform Charts?

While charts provide quick insights, tables are often the better choice in situations where precision and depth are required. Below are key scenarios where tables excel:

Financial Reporting Investors, accountants, and executives need to see precise numbers rather than approximate trends. A profit and loss statement, for example, demands clear, structured tables rather than a simplified visual representation. Financial reporting must adhere to strict standards such as GAAP (Generally Accepted Accounting Principles), IFRS (International Financial Reporting Standards), and SEC regulations, all of which require detailed, transparent, and auditable records. Even small discrepancies in revenue, costs, or margins matter—something a table presents without ambiguity.

Regulatory and Compliance Reporting Many industries require structured, auditable data records to meet legal standards. Regulations such as SOX (Sarbanes-Oxley Act) in finance, HIPAA (Health Insurance Portability and Accountability Act) in healthcare, and GDPR (General Data Protection Regulation) for data privacy mandate detailed reporting, where tables ensure accuracy, transparency, and compliance.

Large Data Analysis When working with extensive datasets, such as customer transactions, inventory records, or operational KPIs, tables allow for sorting, filtering, and drilling down into details. A chart may provide a high-level summary, but only a table can display the complete breakdown necessary for deeper analysis.

Summary

Tables play a crucial role in data analysis, offering clarity, accuracy, and depth that charts alone cannot provide. Rather than viewing them as secondary to charts, they should be embraced as complementary tools. The best data storytelling comes from balancing both — using charts to highlight trends and tables to provide the full picture or the lowest level of granularity.

#Articles

Welcome to Source of Knowledge (SOK), a series where I share a variety of materials to help you grow in the fields of UI/UX and BI. While preparing this series, I saw it as a great opportunity to read some classics I’ve never had time for. This pilot post features the well-known book “Storytelling with Data,” which I first read after 13 years of experience in the field, and I found it still very insightful.

“Storytelling with Data” by Cole Nussbaumer Knaflic

Published in 2015, “Storytelling with Data” is a handy A5 format book with a soft cover, perfect for those who prefer physical books over digital ones. It’s easy to read, with a decent amount of content per page, and is written in a non-academic language. Despite being almost a decade old, the book remains relevant. The concept of storytelling with data takes the regular optimization of data visualizations even further. Instead of just ensuring it serves the data in the easiest way to digest, it focuses on emphasizing key insight(s) coming from it.

Why you should read “Storytelling with Data”?

The key takeaway from the book is a set of techniques for visually explaining decisions to be made, surfacing relevant information, and emphasizing data points that lead to specific conclusions. One example that stood out to me was a visualization showing the attrition of directors in a company. It was altered in such a way that the audience couldn’t ignore the gap between the required and current number of directors. To illustrate its impact without infringing copyrights, I’ve recreated a similar chart below in the context of the PPT slide:

Potential PPT Slide with a data storytelling graph. Inspired by an example from the book “Storytelling with Data”.

The data labels were shown only for the items related to director-level missing in the organization. In the original example, many details were subtly altered to affect perception and reading patterns. The book explains precisely these design decisions and their expected audience reception. The number of examples is more than satisfying, and until the last three chapters, you will rarely see the same example revisited to unveil new techniques.

Content review of ”Storytelling with Data”.

The book is well-planned and kept me intrigued enough to maintain a steady reading pace. The chapters cover almost all aspects of data visualizations and storytelling in logical and easy-to-comprehend chunks.

Here is the Table of Contents:

1. The importance of context.
2. Choosing an effective visual.
3. Clutter is your enemy.
4. Focus your audience’s attention.
5. Think like a designer.
6. Dissecting model visuals.
7. Lessons in storytelling.
8. Pulling it all together.
9. Case studies.
10. Final thoughts.

The first five chapters form the core of the book, providing general concepts without delving into every detail of each topic. One great aspect of the book is that the author frequently recommends other books to explore specific fields further. Some of these titles I’ve read and would also recommend regarding each topic. Chapters 6, 8, and 9 were challenging for me as they focused on case studies, sometimes covering all elements learned from the book. Chapter 9 was the most intriguing, exploring cases not covered in the core chapters. Chapter 7 is a bit of a mystery. It’s interesting and much different from the others, exploring theories on storytelling, story structure (in different forms), and techniques to make it engaging. However, it felt more like a scriptwriting class, which could be summarized in two pages for data visualization context. I suggest switching the order of chapters 7 and 8 for better coherence. Maybe this reversed learning experience will help you grasp the benefits of storytelling theories that can be applied to data visualizations more quickly.

Final Thoughts on “Storytelling with Data.” as a book and visualization concepts.

I highly recommend the book as it succinctly encapsulates many aspects of my work, particularly the impact of visual attributes on the audience’s reception of data. It provides numerous additional reference points, ensuring you are not left without guidance after reading but rather set on a well-defined learning path. The only aspect I’m uncertain about is whether all the knowledge and methodology can be applied in the BI industry context.

Even the author differentiates types of analysis, stating that this book focuses on explanatory rather than exploratory analysis. BI tools I know focus on exploratory/discovery analysis. While manually designing and developing a storytelling dashboard is feasible, doing this daily would require hiring a designated “data bard” for each department to prepare data-oriented stories.

AI will help in this, but it raises the question: are we moving away from exploratory analysis at all and will relying solely on AI-generated business data excerpts? It might actually be quite efficient, like hiring a super-wise expert who completes the analysis in matter of seconds and delivers a set of next-step recommendations along with data visualization justifications.

#Articles

The following list highlights three problems related to dummy data and provides rapid solutions for each.

Problem 1. Dummy Data is Detached from the Business Context

When designing a website or a BI Dashboard, it is important to consider the content and business objectives. Dashboards should provide the necessary information for decision-making and support the overall operation of the business. Unlike real data, dummy data lacks the relevant business aspects. It does not reflect true key performance indicators (KPIs), and products/services, or provide meaningful information for decision-making

A dashboard design with plain use of dummy data.

If you share the above design during corridor tests, people will only be able to evaluate its style. If you share it with stakeholders, who are not familiar with the concept of “dummy data”, it will bring confusion about what information it represents. For them there is no chance to make content validation or check how this will support business decisions. That’s because all the names are very generic: dimension labels, metrics names, amount of content, and items in the graph legends.

Solution 1: Dummy Data connected to the business case

Understand the end-users business processes and the information they analyze. Use real names for metrics and dimensions in your designs. Go beyond labels and consider the expected number of items in each section and the relationships between dimensions. This will immediately make your design more understandable for end-users and stakeholders.

Below is a corrected example with just subtle changes in regard to this solution: Design with implemented solution.

Problem 2. Dummy Data underestimates the importance of screen real estate

Wireframes should primarily demonstrate the functionality of the end product. However, visual aspects, such as realistic sizing and element positioning, should not be overlooked. Neglecting these aspects at the wireframe stage can make it impossible to address them in high-fidelity mockups. The examples provided in the document are closer to high-fidelity mockups than wireframes but still have sizing issues.

Top KPI’s

For instance, the numbers “Sales,” “Cost,” and “Margin” are randomly placed at the top of the screen without any context. With realistic data, these numbers would typically represent sales in USD or units, cost in monetary value, and margin as a percentage or monetary value. Additionally, if the top KPIs aggregate at the company level, they would not be as small as shown in the example, and end-users would prefer more precise values.

However, when we attempt to make this information more reasonable, suddenly no items fit within their placeholders.

Updated KPIs and element names to reflect probable length and units.

Solution 2. Reasonable dummy data.

Validate units, number of digits, and decimal places in every visualization. Double-check the spelling of labels. If you use business-specific names, such as product names or lines of business, ask the client for sample data or a query that includes the longest names. This due diligence is necessary when transitioning from wireframes to high-fidelity designs. Also, consider if any abbreviations are acceptable, such as using “CY” for “Current Year” or “Emp.” for “Employee,” as this can help optimize the design.

All labels and visualizations are fixed

Problem 3. Dummy Data are missing alignment with calculations, dashboard logic, and business definitions.

While it may seem excessive to be extremely precise in the design phase, it is important to consider the expectations of stakeholders and end-users. They may not tolerate examples with incorrect data calculations. Therefore, it is crucial to ensure the mathematical accuracy of your designs. For instance, it is impossible for the cost of goods sold to have negative values. Therefore, the profit should not be five times greater than sales.

Top KPI have incorrect calculations or at least unbelievable.

Equally important is the logic of information. If a dashboard is designed to display data up to the current month (let’s say June 2023), the data points should not extend beyond that month. If the data points show information beyond the specified date (let’s say till the end of the year), end-users may become confused or make false assumptions that it is a forecast.

Reporting month and the graph are not aligned. The graph shows data beyond June 2023.

Furthermore, it is essential to align your designs with business definitions. If you are using thresholds in your dashboard to indicate a positive or negative impact on the business, make sure to verify that logic with your client. Although in many cases, an increase in a parameter corresponds to a positive impact on the business, there are exceptions. For example, consider the time required to achieve something, costs, or the number of items that require action or generate a loss in sales.

Business logic is not correctly applied. Dropping costs is a positive change for the business.

Solution 3. Dummy Data that reflects logic and calculation of the final product.

When inserting data into wireframes or hi-fi mockups, it is important to be meticulous. Consider researching KPI calculations, it can be helpful to visit resources such as the Investopedia Financial Terms Dictionary or similar references. If you’re unsure, don’t hesitate to verify the calculations with end users. Business measures can vary between companies or even within different regions of the same company, therefore it’s ok to ask and verify. The same applies to thresholding, when proposing any iconography or color coding based on KPI values, ask for verification. Be very consistent and follow your agreements with the client on what information to include. For example number of data points in time series, level of data aggregation.

All calculations, information, and business logic are corrected.

Summary

Effective dummy data creation involves thoughtful consideration rather than random generation. Stakeholders’ needs should guide the process, serving as a basis for design decisions and functional validation. Key principles for creating smarter dummy data include:

1. Reflect Real Business Measures: Incorporate actual business metrics and dimension names to align with the client’s business case.
2. Randomized Yet Reasonable Content: Anonymize data while ensuring it remains reasonable, including units, digit count, and decimals. Consider here the impact of this random content on design sizing.
3. Ensure accuracy and Coherence: Meticulously verify the mathematical accuracy and business coherence of data representations. Consistency with agreed-upon dashboard information is crucial to prevent client distractions during the design process.

In conclusion, the purposeful creation of dummy data, tailored to stakeholders’ needs, enhances the effectiveness and validity of design.

#Articles