Storytelling and the Taxonomy of Visualization Methods
Prerequisite Knowledge
This lecture builds on the following concepts from earlier lectures. If any feel unfamiliar, review the linked notes before proceeding.
Previously Covered in This Subject
- Clutter, pre-attentive attributes, and visual hierarchy — covered in Lecture 2
- Exploratory versus explanatory analysis and the chart cheat sheet — covered in Lecture 2
- Storytelling as a design concept — covered in Lecture 2
- Tableau hierarchies — covered in Lecture 1
3.1 Recap: Cluttering, Pre-Attentive Attributes, and Visual Hierarchy
3.1.1 Cluttering and Pre-Attentive Attributes
This session opens with a fast recap of the ideas we built in the earlier classes, because everything today stands on top of them. In the first session we learned the difference between exploratory analysis — where you poke around data freely to find out what is there — and explanatory analysis — where you present what you found to someone else. Last session gave us a chart-selection cheat sheet — which chart or tool works for which scenario. We also covered cluttering, the pre-attentive attributes, and a few design concepts for keeping a viewer's focus.
Why recap before storytelling? Every concept in today's storytelling work — the hook, the conflict, the resolution, the choice of chart — depends on the same toolkit we built earlier: less text, pre-attentive attributes, no clutter. If a chart is cluttered, no amount of story structure will save it; if the most important point is not visually prioritized, the audience will look at the wrong thing. So the recap is not review for its own sake — it is the foundation of everything that follows.
Cluttering is an excess of too many things on a screen, where the user struggles to find the core message. That definition is the whole point: a cluttered screen buries the message under visual noise.
Clutter — the definition to remember. Clutter is an excess of too many things on a screen, to the point where the user struggles to find the core message. Three words carry the meaning: excess (there is too much of something), struggles (the viewer has to work hard), and core message (the one thing the chart should say). A screen is cluttered when the visual noise — extra gridlines, too many colors, crowded labels, redundant decoration — competes with the message instead of supporting it.
Think of a cluttered visualization like a crowded desk: the important papers are somewhere underneath, but finding them takes time. The fix is not to remove information you need, but to remove the noise so the important papers sit on top.
Pre-attentive attributes are the features we notice unconsciously, the things our eyes and mind latch onto immediately without effort. Orientation is one — that tilt, any orientation that is different from the others, gets noticed. Length is another: if one length is very different from the rest, it jumps out. Width, size, and shape behave the same way. These are the attributes we can use smartly in a data visualization to direct attention before a viewer even starts reading.
Pre-attentive attributes — what your eyes notice before you think. A pre-attentive attribute (an attribute = a property of something) is a visual feature that the eye processes unconsciously, in a fraction of a second, before conscious reading begins. The classic list from the lecture: orientation (tilt), length, width, size, and shape. Each one works the same way: when one element differs from the rest along that attribute, it pops out automatically.
The everyday proof: imagine a bowl of green apples with one red apple. You spot the red one instantly — you do not scan and count. That red apple wins on a pre-attentive attribute (color, more precisely color hue), and the same mechanism powers orientation, length, width, size, and shape.
In a visualization you use these attributes deliberately: make the important bar longer, the important dot larger, the important line a different shape, so the viewer's eye lands where you want it to land before they start reading. The eye notices these attributes more frequently than the regular stuff — that is what makes them a design tool.
3.1.2 The Recap Quizzes
To brush up the concepts, the session ran a few quick quizzes. The first one was a straightforward check:
Recap quiz — cluttering, pre-attentive attributes, and visual hierarchy.
Q: What is clutter in a visualization? A: Cluttering is an excess of too many things on a screen, where the user struggles with the core message. It was so obvious that everyone in the class answered it correctly — but the ease of the question is exactly the point. The definition is short, and the whole class carrying it around means we all share the same vocabulary for the rest of the course.
Q: What are pre-attentive attributes? A: The definition: a pre-attentive attribute is a feature we notice unconsciously — orientation, length, width, size, shape. These are the attributes our eyes and mind notice more frequently than the regular stuff. We can use them to pull attention where we want it.
Q: Which design concept prioritizes the most important information most effectively? A: Visual hierarchy. It is the concept that helps us navigate the flow of the screen — it decides what the eye meets first, second, and last. The other options are important too, but hierarchy is the one that organizes and prioritizes the information.
From last session we also carried over the eye-guidance idea: we guide the viewer's eye from top to right to left using the design concepts, so that focus and attention are never lost. These checks matter because everything in today's storytelling work depends on the same toolkit — less text, pre-attentive attributes, no clutter.
Why hierarchy is the winner. Visual hierarchy is the design concept that prioritizes the most important information: it arranges elements so the eye meets the most important thing first, the second most important second, and the rest last — a deliberate reading order. The other design concepts shape individual elements; hierarchy shapes the whole screen. If your story has a hero chart, hierarchy is what makes sure the audience actually meets that chart first. This idea returns constantly in storytelling: the setup, conflict, and resolution each have their own hierarchy, and within each section your data points must be arranged in a priority order.
3.1.3 Where the Course Goes from Here
The roadmap for the course: sessions three and four keep a theoretical flavor, and from the fifth session onward the tools start entering the curriculum — we will look at what data visualization tools exist and compare them, including Power BI and Tableau. From the sixth session onward the course becomes dedicated to Tableau with lots of hands-on work, and module two is entirely Tableau.
The tool-agnostic mindset. If we already know one tool, we tend to get biased toward it; coming into the course with an open, tool-agnostic approach is welcome. Tool syntax is something anyone can learn very easily — it is the concept that matters. That is why the course starts with concepts first and lets the tools come later; once we go deep into a tool, the class becomes very tool-specific. Today's plan is specific: we get familiarity with storytelling, we see a ready-made storyboard to see how a story looks inside Tableau, and then we cover a small set of plot types — dot plots, bar graphs, and floating bars — that are already familiar from earlier material, so the class turns more interesting by building some of them on the fly.
A trap to avoid from day one. Do not become the person who answers every chart question with the tool you already know. Power BI users instinctively reach for Power BI habits; Tableau users for Tableau habits; spreadsheet users for spreadsheet habits. The tool is the last decision, not the first. The first decision is: what is my message, who is my audience, and which chart shape serves both. Everything in the remaining theoretical sessions is designed to build that muscle before the tools arrive.
Recap and bridge. The toolkit from earlier sessions — no clutter, pre-attentive attributes, visual hierarchy, and eye guidance from top to right to left — is the grammar of every chart we will build and every story we will tell. Next, we take that toolkit and ask the bigger question: how do we arrange many good charts and many good slides into something that holds an audience's attention and moves them to a decision? That is the subject of storytelling.
3.2 Storytelling Foundations
3.2.1 What Storytelling Means in Data Visualization
Storytelling is presenting our data — or our findings — in a flow. Anyone can prepare individual slides one at a time; a story is different because it has a natural flow. It starts somewhere, moves forward, and carries the user along. The key difference from a standalone set of slides is that a story is more engaging: you can actually engage the users much better.
Why a flow, not a pile of slides? A single slide can be excellent and still fail, because the audience has to do the connecting work — jumping from one idea to the next without a guide. A story does that work for them: it starts somewhere, moves forward, and carries the user along. The difference is like a photo album versus a film: the album shows separate moments you must link yourself; the film leads you through the moments in order, and you leave with one continuous impression.
Formally, storytelling is a process of creating a story with the findings. It helps the end user understand, and in the end storytelling should encourage and help us to take a decision. That is the ultimate aim — we cannot just come, give a story, and go back. Whatever we build has to close by helping someone decide.
Storytelling, defined. Storytelling (in the data-visualization sense) is the process of creating a story from our data or findings — presenting them in a flow that starts somewhere, moves forward, and ends somewhere. Its job is twofold: (1) it helps the end user understand the findings, and (2) it encourages and helps the audience take a decision. The second half is not decoration — it is the ultimate aim. A presentation that ends without a decision point is a partial story.
Three ingredients must blend into the story: your visuals, your narrative (the words and flow that connect the visuals), and your data (the facts underneath). Individual visuals can be very good, but unless you use them effectively the story will not be effective. The work is to explain (make the findings understandable), engage (hold attention), and entitle (give the audience ownership of the next step) — do all three, and that is what makes a story good. Blending is key, and it should be a good combination of charts and images. It is not just individual beautiful slides; it is a well-knit story.
A well-knit story versus a slide pile — same content, different effect. Suppose the finding is "our testing defect count fell 40% this quarter." A slide pile shows: slide 1, a bar chart of defect counts; slide 2, a line graph of defects by severity; slide 3, a table of open defects by team. Each slide is fine, but the audience must assemble the message themselves. The well-knit story instead opens with the journey ("last quarter we were drowning in defects"), shows the same bar chart as the turning point, uses the severity graph to explain why (the fix rate beat the discovery rate), and closes with the decision ("we keep the new triage process; approve it for next quarter"). Same data, same charts — but only the second version carries the audience to a decision.
3.2.2 Why Stories Stick
There is research behind all of this. If you show somebody one random slide deck, the chance of that person forgetting it is higher than if you tell the same thing as a story. When the material is told as a story, users get engaged better. They remember the facts and the numbers much longer, and they remember them more accurately — it stays with them longer. It is a proven psychological fact, and the attachment is stronger.
Why stories stick — the memory argument. The claim is a proven psychological fact: material told as a story is remembered longer and more accurately than the same material shown as a random slide deck. Why should that be true? Stories give the brain a scaffold: a beginning that sets expectations, a middle that creates tension, an end that resolves it. Facts stored on that scaffold have hooks — each detail connects to the one before and after it — so recall is easier and more faithful. A deck of isolated slides gives the brain no scaffold, so each fact must be stored and retrieved on its own, and isolated facts are exactly the ones that fall out of memory first.
Almost all of us see slide decks on a daily basis, and most of them we forget. A well-knit story is what remains. That is the practical reason storytelling is not decoration — it is a memory and decision-making tool.
The trap of the "beautiful deck". A common mistake is to polish slides one at a time and stop there: beautiful charts, clean fonts, perfect spacing — and no story. Such a deck is easy to forget, because beauty alone does not give the brain the scaffold. The lecture's point: most slide decks we see daily are forgotten; the well-knit story is what remains. Storytelling is not an ornament on top of good slides; it is the structure that makes good slides unforgettable.
3.2.3 Know Your Audience and Your Purpose
Before building anything, you must know your audience and what they are keen on. A senior executive will not give importance to your weekly numbers or your small numbers. They will ask: where are we, what is the business value, what is the benefit we are trying to achieve. So your story and your interest are tailored based on the audience.
Audience first, charts second. The same project produces different visual stories depending on who is in the room. An executive wants the big picture — where are we, what is the business value, what benefit are we trying to achieve; your weekly numbers and small numbers carry little weight with them. A technical team, by contrast, lives in the weekly numbers. There is no single "correct" dashboard for a project — there is a correct dashboard for each audience.
Presenting data in a daily scrum or a daily standup call is very different from presenting a monthly status report. In the daily standup you probably discuss everything — testing coverage, open defects by level or severity, showstoppers. In the monthly status to executives, the data varies because the audience varies. So the same project produces different visual stories depending on who is in the room.
Your purpose also has to be clear before you write a single slide: what will I achieve after this presentation? Am I just giving a status update, or am I asking for a decision? Knowing exactly what you want from the audience helps you build the narrative.
Audience and purpose — the two questions to answer before any slide. (1) Who is my audience, and what are they keen on? The audience decides which data appears: daily standup (testing coverage, open defects by level or severity, showstoppers) versus monthly executive status (business value, benefit, where we are). (2) What is my purpose — what do I want to achieve? A status update and a decision request are different presentations even for the same data: one informs, the other commits. Answering these two questions before writing a single slide shapes everything: which numbers you show, which charts you pick, and where the story ends.
3.2.4 Emotion and Visuals That Carry the Narrative
If possible, connect your audience at an emotional level — bring some humor, or some fear, or some inspiration. A fear-based hook works: if we do not do this, this is the million-dollar cost overrun we are expecting. It can be good, it can be fear, it can be inspiration — any of those. The emotion creates attachment and resonance.
Emotion — the attachment layer. Facts inform; emotion attaches. Connect the audience at an emotional level with humor, fear, or inspiration. The fear-based hook is a classic: "if we do not do this, this is the million-dollar cost overrun we are expecting." The hook can also run positive — "if we do this, we get the bonus." Either way, the emotion creates attachment and resonance: the audience remembers not just the numbers but how the numbers made them feel, and the story stays with them longer.
Then support the story with strong visuals so people trust better. If you claim a delay will lead to overrun, show it. In one real program the team presented a monthly burn rate visual: the impact of a one-month delay is this much, the impact of a two-month delay is this much, with a per-month delay impact visual. That is how the narrative gets supported by strong visuals.
The burn-rate visual — emotion and proof in one. A real program needed executive support for a schedule risk. The claim was emotional (fear: delay means cost overrun); the proof was visual. The team showed a monthly burn rate visual built as a per-month delay-impact chart: one bar for the impact of a one-month delay, a taller bar for the impact of a two-month delay, and so on — the cost of not acting, month by month. The visual made the fear concrete: the audience could see the slope of the overrun, not just hear it asserted. Emotion set up the question ("what does a delay cost us?"); the visual answered it ("this much per month").
Real-world: this is exactly how executive decisions get made in industry — the story plus a visual proof of the cost of not acting.
Recap and bridge. Storytelling is data plus narrative plus visuals, arranged in a flow, aimed at a decision; stories stick because they scaffold memory; the audience and purpose decide the content; emotion and strong visuals carry the message. That is the foundation — next we look at the skeleton every such story follows: the three-phase structure of setup, conflict, and resolution.
3.3 The Three-Phase Story Structure
3.3.1 Setup: Hook and Engage
Any story typically has three key phases. The very first stage is the setup, where we try to engage and hook the user. We present the data in such a way that a connection is made: we start with some kind of trend that gets the user hooked. Nobody says a storytelling must have only three slides — that is not the purpose. You can use two or three slides for the setup where you are hooking and engaging the end user, showing where we were and how we have traveled to the present state.
The three phases of a story. Every story follows the same skeleton: setup (hook and engage), conflict (the crux), and resolution (the after state). The setup opens the story and makes a connection with the user — typically a trend showing where we were and how we have traveled to the present state. It answers the audience's silent question: "why should I keep looking?" The number of slides per phase is flexible — two or three slides for the setup is normal — but the phase itself is not optional.
The setup is where you earn attention. A trend that moves, a direction that changes, a relationship that surprises — anything that makes the user want to know what happens next. This is not the time for a dense table or a crowded chart; the hook must be instantly readable.
3.3.2 Conflict: The Crux of the Story
The second phase is the conflict — this is how the story flows: what exactly is the conflict, why it is causing this, what is happening. This is the core crux we are trying to achieve with the data. The conflict section carries the causes and the risks of not doing things. It answers: why did this change happen, and what happens if we do nothing.
The conflict — the engine of the story. The conflict is the core crux: what exactly is the problem, why it is causing this, what is happening. It carries the causes and the risks of not doing things. It answers two questions: "why did this change happen?" and "what happens if we do nothing?" Without the conflict there is no tension, and without tension there is no reason for the audience to want a resolution. The conflict is why the story exists — it is the gap between where we are and where we need to be.
The conflict is where the data works hardest: the falling metric, the growing risk, the slipping timeline. This is the phase where the audience should start feeling the cost of inaction.
3.3.3 Resolution: The After State
The third phase is the resolution — the last stage, the after state of the change. This is where we show: if we do this, this is what will happen. Our graphics, our visualizations, everything should follow this flow: setup, conflict, resolution. The relevant information and data should correspond to these sections.
The resolution — the after state and the ask. The resolution is the last stage: the after state of the change. It shows "if we do this, this is what will happen" — the proposed path and its outcome. Everything should follow the flow setup → conflict → resolution, and the information and data should correspond to their own sections: hook material in the setup, causes and risks in the conflict, the forward path in the resolution. This is also the phase where the story moves toward the decision and the ask (see 3.5.3) — a resolution without a direction is only half a resolution.
3.3.4 Quiz Walkthrough: Matching Visuals to Phases
The class then worked through a set of scenario quizzes, one per phase, to see how the theory translates into chart choice. The first two quizzes both targeted the hook:
Q: For the hook stage of a renewable-energy story, which visual works best — a pie chart showing the different energy distribution, an animated bar chart showcasing the growth of renewables over time, or a choropleth map highlighting the areas of higher adoption?
A: The animated bar chart. The hook is the stage where we showcase where we were and how we have traveled to the present state, and animation tends to engage users much better — animated is the keyword here. The pie chart is static and shows a single moment; the map is static and shows a single location; the animated bar chart shows movement, and movement is what a hook needs. That is a good way of starting a story.
Q: For the hook, would you use a line graph with a surprising spike, a pie chart with a contrasting color, or a heat map revealing an unexpected pattern? One student was genuinely confused between the line graph and the heat map.
A: The heat map revealing an unexpected pattern is more engaging — it gives a complete view, and because it has an unexpected pattern it shows different patterns at once. The line graph is not wrong, but the heat map has more potential to engage the end user, so in this scenario it is the better way to start. The lesson of the confusion: when two charts both could work, choose the one with more engagement potential — the complete-view chart that surprises beats the single-curve chart that merely spikes.
The two hook quizzes share the same logic: the hook is not the place for the most precise chart, it is the place for the most engaging chart. Precision is a conflict-stage and resolution-stage concern.
The next quiz tested the conflict phase:
Q: For the conflict stage, which visual works best — a bar chart showing the opposing trend, or a scatter plot showing an outlier? Both look like they could qualify.
A: The bar chart showing the opposing trend. Both may qualify, but the bar chart is comparatively easier to interpret, and in the conflict you have to show something conflicting with what you showed in the hook — you presented a heat map there, now you show exactly opposite trends via a bar chart, and the audience gets engaged and asks, what are you telling us? A scatter plot mainly shows correlation, so it is a weaker fit here: an outlier is a curiosity, not a counter-argument.
Q: For the resolution stage, which visual closes the story best — an area chart, or one of the other options?
A: The area chart. In an area chart the area underneath the line is shaded, so it tells the volume and reads as converging towards the goal. You are telling the audience: if we do this, this is how we are going towards the goal. That is the best way of coming to the resolution part — the shaded volume makes the forward path feel solid and closing in on the target.
After all four quizzes, an important caveat. There is never a rule that says these three graphs are for the hook, these four are for the conflict, these three are for the resolution. There is no such concept and there is no formula. The graphs can be used interchangeably between any phase of the story — it is all about your data and your audience. Whatever you choose should be logically done, should follow the concepts of less cluttering and good visuals with interactiveness. That is the mantra.
The mantra: no fixed graph-to-phase mapping. The quizzes above are reasoning exercises, not laws. The animated bar chart won the hook because animation engages — not because "animated bar charts are hook charts." The bar chart won the conflict because it is easy to interpret — not because "conflict requires bars." Graphs can be used interchangeably between any phase of the story; what decides is your data and your audience. The only hard rules are the general ones: less cluttering, good visuals, interactiveness, and a logical argument. Keep the phases in order, but keep the chart choice free.
3.3.5 Different Names, Same Structure
Different books give the three phases different names. One book the instructor read used something like a villain, a hero, and a third term — the idea was the same, just different vocabulary. Whatever you call them, the structure is the same: a hook where you engage the audience, a conflict where the causes and risks come, and a resolution where the story closes.
Same skeleton, different names. The three-phase structure is ancient and gets renamed by every book: setup–conflict–resolution in one book, villain–hero–third term in another, Aristotle's beginning–middle–end in the classics. Do not get attached to the vocabulary — get attached to the structure. When you hear "the hero of the story," map it to the resolution; when you hear "the villain," that is the conflict doing its job. The test question for any name is: does this phase hook, does this phase create tension, or does this phase close the story?
One warning goes with the structure: do not shuffle between the sections. It cannot happen that you talk about the resolution in between, then go back to the conflict, then go back to the setup. Maintain your hierarchy, and keep your data points related to the section they belong to. That is what makes the story hold together.
Do not shuffle the sections. The structure is a one-way flow: setup, then conflict, then resolution. Jumping back and forth — a resolution point in the middle, then a conflict, then back to the setup — breaks the audience's mental model of where the story is going. Maintain the hierarchy: every data point must belong to the section it appears in. Hook facts in the setup, causes and risks in the conflict, the forward path in the resolution. Shuffling is the fastest way to turn a story back into a pile of slides.
Exam note: No exam-specific guidance was given about the story structure in this session, but the three-phase structure (setup, conflict, resolution) is the backbone of the storytelling material covered in this unit, so know what each phase does — and know that the phases travel under different names in different books (such as villain and hero in one book), with the same meaning.
3.4 A Storytelling Case Study: The Multimillion-Dollar Program
3.4.1 The Problem: A Program on the Brink
To show the approach in action, the instructor shared a real case from industry. It was a massive, very strategic, multimillion-dollar program that was being delivered, and a lot was going wrong. The trouble showed up in the testing phase: roles and responsibilities were causing problems. Team members were saying, this is not my thing, you will do it. Last-minute bugs were being raised and nobody was taking ownership. The program went deep red. Testing was almost on the verge of collapsing and go-live was at risk.
The problem state — a program in the red. Picture a large, strategic program worth millions of dollars, already deep in delivery. The trouble concentrated in the testing phase, and it was structural: roles and responsibilities were unclear. Team members deflected work — "this is not my thing, you will do it." Last-minute bugs were being raised, and nobody took ownership of them. The consequences stacked up: the program went deep red (a status color meaning critical danger), testing was on the verge of collapsing, and the go-live date was at risk. This is the conflict state that a storytelling team must eventually lay out with data.
Worse, the teams blamed each other. The tester said it is a development issue. Development said we are not getting the requirement from business. The whole triangle between business, development, and testing collapsed, and nobody was able to make out what the actual challenges were.
The blame triangle — a storytelling diagnosis. When business, development, and testing each point at the others, nobody can see the real challenges: the tester says it is a development issue, development says the requirement is missing from business, and the loop never closes. The diagnosis matters because the conflict section of the story has to name this triangle — not to accuse anyone, but to show that the problem is a broken handoff structure, not a lazy team. Naming the real cause is what turns a shouting match into a fixable problem.
3.4.2 The Setup and the Conflict
The team built a story instead of arguing. First, the setup: they started with why this program is being done, showing the key KPIs of the program and why it is critical — once we do this, this is what we will get. They spoke about the achievements so far and where they were today. That set the context for the executives.
The setup — context before crisis. Instead of opening with "we are red," the team opened with why the program exists: the key KPIs of the program and why it is critical — once we do this, this is what we will get. They showed the achievements so far and where the program stood that day. The effect: executives were given the destination and the progress before the trouble, so the conflict that followed had something to threaten. A conflict with no context is noise; a conflict after a strong setup is a drama.
Then the conflict: this is where we are, this is what we have achieved so far, and this is what is wrong. They explained how it was impacting the program: our timelines will slip; if timelines slip, this is the cost impact; a vendor will ask for a more revised cost; here is the rework and the time taken. All of that conflict — why it was getting tough and difficult, and the challenges they would face if they did nothing — was laid out with data.
The conflict — the cost of doing nothing, quantified. The conflict section connected the current state to its consequences, each step backed by data: "our timelines will slip; if timelines slip, this is the cost impact; a vendor will ask for a more revised cost; here is the rework and the time taken." Every sentence in that chain is a claim — and every claim was shown, not asserted. The chain ends with the sharpest question in storytelling: what challenges will we face if we do nothing? By laying the full chain out with data, the team made inaction visibly expensive.
3.4.3 The Resolution: Roles, Standups, and Support
Then the resolution: they proposed their suggestion and did a dry run — look, this is how we can do it; if we do this, this is what will get resolved; every role's responsibility will be clear and validated. They presented exactly who does what: this is what the business users will do, this is what the tester will do, this is what the development team will do. They proposed daily standup meetings in which the defects would be distributed.
The resolution — a concrete proposal, dry-run tested. The resolution was not a vague "we will fix it." It was: here is how we can do it; if we do this, this is what will get resolved. Every role's responsibility was spelled out and validated — this is what the business users will do, what the tester will do, what the development team will do — and the mechanism was daily standup meetings in which the defects would be distributed. The dry run mattered: they rehearsed the proposal as the audience would hear it, so the ask arrived clear and tested rather than improvised.
The outcome was strong: the approach got support from all the stakeholders. Senior management said, our own business analyst will do this, IT will do this. It was a grand success. Importantly, it was not a tool-driven presentation — they went with a simple slide deck, presenting facts, data, conflicts, and a proposal.
The outcome and the medium. The approach got support from all stakeholders — senior management itself assigned responsibilities: "our own business analyst will do this, IT will do this." It was a grand success. And note the medium: it was not a tool-driven presentation — no Tableau, no Power BI storyboard. A simple slide deck with facts, data, conflicts, and a proposal carried the day. The lesson stands: the structure behind the words, not the software around them, is what wins support.
3.4.4 What This Case Proves
The lesson is not that every red program turns green — not all your programs will become green. The lesson is that building narrative, visualization, and facts around the three sections tends to engage users better, and engagement is what gets decisions and support. The story does not have to be a tool report; it can be a simple deck, it can even be written on paper, or you can just speak to your audience. What matters is the structure behind the words.
The honest limit of the case. The lesson is not that every red program turns green — not all programs will. The case proves something else: building narrative, visualization, and facts around the three sections tends to engage users better, and engagement is what gets decisions and support. The structure improves the odds of a good outcome; it does not guarantee one. Treat the case as evidence that storytelling changes how people respond to bad news, not as a promise that a well-told story always saves the project.
Recap and bridge. The multimillion-dollar program was saved by a three-phase story — setup (KPIs and context), conflict (slipping timelines, cost impact, vendor cost, rework, quantified), resolution (clear role responsibilities, daily standups, senior-management support) — delivered on a simple slide deck. The case is the proof that the phases from 3.3 work in real industry settings. Next: the practical checklist of what to do and what to avoid when you build your own stories.
3.5 Storytelling Do's and Don'ts
3.5.1 The Do's of Storytelling
The do's list starts with knowing your audience — the instructor repeated it because it is the foundation. Then your purpose should be very clear and your narrative should be very clear. Do a dry run: sit on the other side of the fence and see — if somebody else presented what you are about to present, would it make any sense? Make sure your narrative is compelling.
The do's — a checklist. (1) Know your audience — repeated because it is the foundation; every other decision hangs off it. (2) Purpose and narrative clear — know what you want to achieve and what thread connects the slides. (3) Do a dry run — sit on the other side of the fence: if somebody else presented what you are about to present, would it make sense? The dry run is a rehearsal from the audience's seat, not from yours. (4) Bring emotion — fear or inspiration: if we do not do this, this happens; if we do this, we get the bonus. (5) Make the visuals good — using everything from the earlier classes: less text, pre-attentive attributes, no clutter.
Bring some kind of emotion: fear or inspiration — if we do not do this, this happens; if we do this, we will get the bonus. Bring that emotional angle to the story. And make your visuals good, using everything from the earlier classes: less text, pre-attentive attributes, no clutter. All of it plays a part; today we simply went one level above — earlier we were discussing individual slides, now we are asking how to present a lot of good slides and a lot of good data together.
Finally, keep practicing and refining. It will never happen in one meeting that you please everybody. You are bound to get feedback, and different requests will come for different things. That is absolutely fine — feedback is what makes the story more impactful and more productive.
The one-level-above mindset. Everything from the earlier classes was about individual slides: less text, pre-attentive attributes, no clutter. Storytelling is the same toolkit applied one level up — how to present a lot of good slides and a lot of good data together, in a flow. The rules do not change; only the unit of analysis does, from the single screen to the whole narrative.
3.5.2 The Don'ts of Storytelling
Do not try to have too much information. You can have a flow — you do not have to put everything on one screen. The blank or white page in a presentation actually does work; by now the point is clear — do not overload.
Try to avoid technical jargon. If you say, my build is this, my version is this, the end user may not understand. Explain the concepts in the language the audience understands.
The don'ts — a checklist. (1) No information overload — you can have a flow; you do not have to put everything on one screen. The blank or white page in a presentation actually works — do not overload. (2) No technical jargon — "my build is this, my version is this" means nothing to the end user; explain concepts in the language the audience understands. (3) No extreme high level — support the story with numbers. (4) No extreme plainness — do not go to the opposite extreme and talk only numbers and data; the presentation must be balanced: engaging, attaching, and numeric. (5) No stopping at the story — move towards taking a decision. (6) No ignoring feedback.
Equally, do not be too high level — we have to support the story with numbers. And do not go to the opposite extreme and be too plain, only talking about numbers and data. It has to be a balanced approach: engaging, bringing some attachment, and showing the numbers.
Do not just tell a story and stop. Move towards taking a decision. And do not ignore feedback — feedback is usually very good. An experienced person you are presenting to will say, show me this instead of that, and that kind of feedback really helps; there is no harm in it. Any visualization goes through iteration — hardly any presentation gets a one-shot approval.
The two extremes to balance. Too high level leaves the story unsupported (no numbers, no proof); too plain leaves it dead (numbers and data with no engagement, no attachment). Both extremes fail. The balanced story is engaging, creates attachment, and shows the numbers — the same triangle as emotion plus visual proof from 3.2.4. And never fear the "show me this instead of that" comment: iteration is normal, and hardly any presentation gets a one-shot approval.
One quiz reinforced the jargon point:
Q: What is not a key element of effective data visualization storytelling — accuracy of data, clarity of visuals, personal anecdotes, or technical jargons?
A: Technical jargons. That is what does not help — end users may not understand build numbers and versions, so jargon is the element to leave out. Accuracy, clarity, and anecdotes all serve the story; jargon serves only the presenter's vocabulary.
3.5.3 Close the Loop: Always End with an Ask
Look back at the case study: otherwise the team could have only said, if we do not do this, this is the impact, and closed the meeting. What they did instead was include the third part — a proposal, how it would help, and what benefit it would bring. While telling a story, never forget the actions we should take to address it.
Close the loop — the ask. A story that ends at the impact is a partial story. The case study team could have stopped at "if we do not do this, this is the impact" — but they added the third part: a proposal, how it would help, and the benefit it would bring. Every story should move toward taking a decision: an action, a recommendation, or an ask, put on whoever is the qualified person. This closes the loop.
If you leave the action out, the story is partial and you are not achieving what you want — the action will come back on you. Your audience will say, okay fine, come back and tell us what we should do. So this is the best time to ask and to put action on whoever is the qualified person. There should always be an action, or a recommendation, or an ask, in your storytelling. It closes the loop.
The cost of a missing ask. If you leave the action out, the story is partial and you do not achieve what you want — the action will come back on you. The audience will say: okay fine, come back and tell us what we should do. You then lose the meeting's momentum and must re-present everything later. The presentation itself is the best time to ask — put the action on whoever is qualified to take it, in the room, while the story's tension is still fresh.
Recap and bridge. Do: know your audience, fix your purpose and narrative, dry-run, bring emotion, make visuals strong, keep practicing. Do not: overload, use jargon, go too high level or too plain, stop at the story, ignore feedback. And always close the loop with an action, recommendation, or ask. With the checklist in hand, we turn to three practical storytelling tools: the three-minute story, the big idea, and storyboarding.
3.6 The Three-Minute Story, Big Idea, and Storyboarding
3.6.1 The Three-Minute Story
These are three commonly known storytelling concepts, used a lot in marketing. The first is the three-minute story. If your boss or your stakeholder meets you in a lift — or in the cafeteria — and asks what is going on, you should be able to tell exactly what you want in three minutes. You have only three minutes, so you must be very crisp.
The three-minute story — the lift pitch. The three-minute story is the whole communication boiled down to what you could say in three minutes: the situation, the finding, and the ask, delivered crisply to a stakeholder you meet by chance — in a lift, a cafeteria, or a corridor. It is not a compressed copy of your slides; it is the story stripped to its spine: where we are, what we found, what we want.
The reason this matters: sometimes you do not get the luxury of a thirty-minute or one-hour session. Sometimes you only get five minutes. An executive manager may put your report to the side and say, tell me what you want. You cannot reply that you have prepared slide by slide and will go in sequence. In that situation you must be able to tell your ideas in a very short span of time.
Why the three-minute story exists. You will not always get the thirty-minute or one-hour session you prepared for. Sometimes you get five minutes; sometimes an executive puts your report aside and says, tell me what you want. The prepared slide-by-slide sequence is useless in that moment. The three-minute story removes your dependence on the deck: the story lives in you, not in the slides, so you can fit it to whatever time you are actually given — three minutes, five minutes, or a single lift ride.
3.6.2 The Big Idea: One Sentence
The big idea is the concept where you tell the overall opportunity or status in one sentence. If your line manager meets you in the lift or the cafeteria, what is the one thing you will tell?
The big idea — one sentence tells everything. The big idea compresses the whole opportunity or status into a single sentence: success or problem, current status, and the ask, with no ifs, buts, or sequences. Where the three-minute story is the short version, the big idea is the one-shot version — the sentence you would deliver if you had exactly one chance to say it.
Two worked big ideas.
Example one — the pilot ask: "Our pilot is successful — it has met all the criteria, so we need more funding for this to happen." One shot: the success (pilot successful), the evidence (met all criteria), and the ask (more funding) — no ifs, buts, or sequences.
Example two — the board approval ask: "We have two open issues; however, we have a workaround and we have the business approval; so we need a board approval." One sentence again carries the full status: the issues (two open), the mitigation (workaround exists), the approvals already in hand (business approval), and the remaining ask (board approval).
Sense-check: in each case, a manager who heard only that sentence could act — that is the test of a real big idea.
3.6.3 Storyboarding: Sticky Notes and Workshops
Storyboarding is where you go in a sequential manner — one slide after another. In workshops people do this with sticky notes, laying out one block after another until the whole story sequence exists. Today there are software tools for virtual workshops, where you do not all have to be in one room: you can drag and drop sticky notes and even give your ratings to the notes. Miro is one such tool, and Mural is another. These are very nice tools for building a storyboard collaboratively before any slide is designed.
Storyboarding — plan the sequence before the slides. Storyboarding is planning the presentation as a sequence, one block (one slide, one idea) after another, until the whole story order exists — a visual outline of the content you will create. The classic low-tech tool is the sticky note: write one idea per note, lay the notes out, and rearrange them until the flow works. The key habit: plan on notes first, not in presentation software — notes are cheap to move, delete, and rewrite, so you explore flows instead of committing to slides.
The workshop practice — physical and virtual. In workshops, people storyboard collaboratively with sticky notes on a wall: one block after another, rearranged until the whole story sequence exists. Virtual tools replicate the wall for remote teams — Miro and Mural let you drag and drop sticky notes and even rate the notes. The advantage of the virtual wall is the same as the physical one: the sequence is visible as a whole, and anyone can move a note without destroying work. Storyboarding happens before any slide is designed — it is the planning step, and a storyboard is the outline the slides will later fill.
The trap of starting with slides. The most common storyboarding failure is skipping it — opening the presentation tool and generating slides one by one, discovering the flow only when the deck is done. By then, rearranging means redoing work, and bad ordering gets preserved because it is expensive to fix. Storyboard first: one sticky note per slide, rearrange freely, get the sequence agreed — then build slides to match the agreed storyboard, not the other way around.
Recap and bridge. Three practical tools: the three-minute story (crisp spoken version for the lift), the big idea (everything in one sentence, success plus status plus ask), and storyboarding (sticky notes, physical or virtual, planning the sequence before any slide exists). These three are named concepts of this unit — be able to define each and give an example. Next, we see how the same skeleton works inside a real tool: stories in Tableau.
3.7 Stories in Tableau: Sheets, Dashboards, and Story Points
3.7.1 The Tableau Story Flow
A story in Tableau is nothing but a slide-deck-like flow — it is not rocket science. The flow works bottom-up: first you build individual sheets (worksheets); individual sheets make a dashboard; and the combination of sheets and dashboards leads to a story. Tableau has separate icons for a new worksheet, a new dashboard, and a new story, and the story is the icon where all of it comes together. When you want a new sheet you add a worksheet; when you want to bring sheets together you add a dashboard, drag and drop the sheets onto it, and arrange it; and all of these make the story.
The Tableau story flow — sheets → dashboards → stories. A story in Tableau is a slide-deck-like flow built bottom-up: (1) sheets (worksheets) — individual charts, each one a single visualization; (2) dashboards — several sheets dragged together onto one screen and arranged; (3) stories — a sequence of sheets and dashboards presented as story points, with a narrative connecting them. Tableau keeps separate icons for a new worksheet, a new dashboard, and a new story; the story icon is where all of it comes together. Not every sheet has to go into a dashboard or a story — that is entirely possible too.
3.7.2 A Worked Story: From Sales to California
The instructor walked through a ready-made story built for an earlier class, just to show the flavor — he noted openly that he randomly took this example, not claiming it is good or bad or validated, only that it shows how a story is built.
A worked story walkthrough — sales, states, and a strong year. The ready-made story opened with a sheet plus commentary, and you can navigate from story point to story point. Point by point:
- Open with the headline segment: "Our consumer sales is the highest among all the three segments" — the first screen presented a sheet with this commentary, setting the hook.
- Zoom into the best region: the narrator showed that California has the best sales among all the states, by the color.
- Broaden with a word cloud: "California and New York are our two top states where we got the maximum sales."
- Show the trend: the narrative moved to the trend — "our sales is going up, and it looks like we will end our year in a fantastic 2021."
- Close with an interactive dashboard: the story closed with an interactive dashboard the audience could explore.
Sense-check: notice the structure — segment headline (setup), best-state detail (deepening), word-cloud evidence (support), upward trend (positive outlook), interactive close (handing control to the audience). That is the three-phase skeleton expressed in Tableau points.
The honest caveat on the example. The instructor noted openly that this story was randomly picked from an earlier class — not claimed as good, bad, or validated. Its value is purely mechanical: it shows how a story is built and navigated in Tableau, not what a perfect story looks like. Keep the same attitude when evaluating any demo story: study the mechanism, judge the content yourself.
3.7.3 Building Your Own Story
The same skeleton is available to you: say where we are and what we have achieved; talk about what we want to do; come to the conflict — if we do not do this, this is the risk we are having; come to the action — if we do this, this is the benefit we will get; and at the end give an interactive dashboard.
The story skeleton in Tableau terms. Your own Tableau story should follow the same arc as every story in this lecture: say where we are and what we have achieved (setup); say what we want to do (direction); come to the conflict — if we do not do this, this is the risk we are having; come to the action — if we do this, this is the benefit we will get; and close with an interactive dashboard so the audience can explore the conclusion themselves.
Mechanically, you can add story points: choose a blank story point and a new one gets added; you can drag and drop a visual into it, and you can change the sequence of the points by dragging them around. That is how stories are built — this is what the course will slowly teach, from building sheets to dashboards to stories.
Building story points — the mechanics. To assemble the story: (1) add a blank story point — a new point appears in the sequence; (2) drag and drop a visual (a sheet or dashboard) into that point; (3) change the sequence by dragging points around until the narrative order is right. Each point holds one screen of the story, and the sequence of points is the flow the audience navigates. That is the whole mechanism — the course will slowly teach it, from sheets to dashboards to stories.
Exam note: No exam detail was given about Tableau stories in this session, but the sheet → dashboard → story flow is the concept that matters when the hands-on Tableau part of the course starts. Remember the direction of assembly (sheets make dashboards; sheets and dashboards make stories) and that story points are added as blanks, filled by drag-and-drop, and reordered by dragging.
3.8 Tableau Student Licensing and Setup
3.8.1 The Student License Route
A practical question came up in class: whether Tableau access is needed for the course assignments.
Q: Do we need Tableau access for this course? I tried last week and it was asking for a license, so I was wondering if it is something we should arrange from an assignment perspective.
A: It is not a showstopper, but it is worth arranging. From module two onwards the course is purely Tableau, and one of the experiential learning assignments also makes sense to give from Tableau, so it will be good to have it arranged. Tableau gives students a free one-year license: go to the Tableau website, choose the download, and it will offer a free academy license. The process uses your university email — you may have to show your admission letter or a course handout to prove you are a student — and they will send you a key via email. It may take some time, so start it early; in earlier batches students arranged it and it helped.
The student license route — how it works. Tableau offers students a free one-year license: go to the Tableau website, choose the download, and a free academy (student) license option appears. The process uses your university email as proof of student status — you may have to show your admission letter or a course handout — and Tableau sends you a license key via email. Two practical points: it can take time (start early), and past batches confirm the arrangement pays off.
The timing trap. Do not leave the license to the last week of the module. The verification process — university email, possibly an admission letter or course handout, email delivery of the key — can take days, and the hands-on Tableau sessions do not wait. The instructor's advice is explicit: arrange it early; in earlier batches students who arranged it early found it helped, and it is not a showstopper only because it is arrangeable in time — if you start late, it becomes one.
3.8.2 Tableau Public versus Desktop
If you cannot get the desktop version yet, Tableau Public is absolutely free of cost, although it has fewer features — file and export options and several other capabilities are missing compared with the desktop version, and the trial that comes with it is only about fourteen days. Power BI Desktop, by contrast, is free for everybody — that is one key difference between the two tools.
Tableau Public versus Desktop. Tableau Public is the free tier: absolutely free of cost, but with fewer features — file and export options and several other capabilities are missing compared with the desktop version, and its trial lasts only about fourteen days. Tableau Desktop is the full product (available to students via the free one-year license above). And Power BI Desktop is free for everybody — that is one key difference between the two tools. So a student who cannot get the desktop version yet still has a free fallback for practice, with the caveat that it is a restricted one.
3.8.3 Tableau and Salesforce
Tableau is a Salesforce product — Salesforce bought Tableau several years back, around seven to eight years ago. For students already working in the Salesforce ecosystem, that connection matters because the product roadmap is now driven by Salesforce.
Tableau and Salesforce. Tableau is a Salesforce product: Salesforce bought Tableau several years back, around seven to eight years ago. For students already working in the Salesforce ecosystem, the connection matters because the product roadmap — what features Tableau gets next — is now driven by Salesforce's priorities. The same thread reappears in the AI discussion (3.10.3): Salesforce is pushing AI into all of its clouds, including the analytics products.
Recap and bridge. Tableau access is worth arranging: free one-year student license via university email (start early), Tableau Public as a free but restricted fallback, and Power BI Desktop free for everyone. Tableau sits inside the Salesforce ecosystem, which shapes its roadmap. With both tools' practical setup understood, we compare the tools head-to-head — where each one is strong and where each one falls short.
3.9 Power BI versus Tableau: A Tool Comparison
3.9.1 Data Engineering and Cleaning
The class compared the two tools, mostly from the students' own Power BI experience. One student's take: Tableau is good in visualization, whereas Power BI is good in integrating data and simplifying the data to make decisions — cleaning and all those things.
Power BI can do data engineering, and the instructor agreed that Tableau does not have that to the same scale. Tableau does offer a bit of data cleaning: you can do a union of data, drag different tables, format a field, and split a field — for example an alphanumeric key like CA1 can be split very easily into three fields, one of them a year. You can do mapping between tables. But it is not as powerful as Power BI in this area. The full comparison is planned for the fifth class, when the course discusses all the tools in the market.
Data engineering and cleaning — the division of strength. Power BI's strength is data engineering: integrating data and simplifying it to make decisions — cleaning and all those things. Tableau is good at visualization, but does not do data engineering to the same scale. Tableau still offers a bit of data cleaning: you can do a union of data, drag different tables together, format a field, and split a field — an alphanumeric key like CA1 can be split very easily into three fields, one of them a year — and you can do mapping between tables. The difference is scale, not existence: Tableau cleans a little; Power BI cleans deeply.
Q: Power BI can do data engineering and data cleaning. Does Tableau do that too?
A: Tableau gives you a bit of data cleaning: you can union data, drag different tables together, format a field, and split a field — an alphanumeric key like CA1 can be split into three fields — and you can map between tables. But it is not at the scale of Power BI, where data engineering and cleaning are real strengths. The full comparison is planned for the fifth class, when the course discusses all the tools in the market.
3.9.2 Data Sources and Integrations
Power BI is a Microsoft-backed tool, so it comes with native integration with the whole suite of Microsoft products, and it has JDBC/ODBC drivers through which one can integrate with various data sources. From the students' experience, Tableau also offers many options to connect to different sources. The instructor said he has no preference — both tools have their pros and cons, and the detailed feature comparison will come when the course does the tool comparison chapter.
Data sources and integrations. Power BI is Microsoft-backed, so it ships with native integration with the whole suite of Microsoft products, plus JDBC/ODBC drivers through which one can integrate with various data sources. Tableau, from the students' experience, also offers many options to connect to different sources. Both tools reach the same data, through different doors: Power BI through the Microsoft ecosystem and standard drivers, Tableau through its own broad connector list. The instructor's stance is neutral — no preference; both tools have pros and cons, and the detailed feature comparison comes later in the course.
Q: Power BI seems to have not many options to import data compared with Tableau, is that right?
A: From experience, Tableau gives many options to connect to different data sources, while Power BI is backed by Microsoft with native integration with its whole suite of products and JDBC/ODBC drivers, so one can integrate with various data sources. That is one of its advantages. The real comparison will be done when we cover the tools. Also worth knowing for later: Tableau can have live connections and extracts, both of which we will learn when the tool work starts.
3.9.3 Storytelling in Power BI
Since the tools are very competitive, the class discussed whether Power BI offers a story concept like Tableau's.
Q: Does Power BI offer any kind of storytelling like Tableau's stories?
A: From what I can recall, Power BI does not offer such a storytelling concept. You can design a dashboard, add different widgets and gadgets to a single dashboard, and that is the final version you can present to stakeholders, or you can tell in a steady form what data you want to present. It is similar to Excel with multiple sheets: you create multiple pages and the first one is a summary of all of them. I will revalidate this, because these two tools are very competitive with each other.
Storytelling in Power BI — the current answer. Power BI does not offer a story concept like Tableau's stories. Its presentation unit is the dashboard: you design a dashboard, add different widgets and gadgets, and that is the final version you present to stakeholders — or you walk them through the pages in a steady form. The mental model given in class: Power BI is similar to Excel with multiple sheets — you create multiple pages and the first one is a summary of all of them. Tableau's story points (3.7) are a separate, explicit narrative layer; Power BI's narrative lives in the pages of the report. Note the caveat: the instructor said he will revalidate this, because the two tools are very competitive and features move fast.
The moving-target caveat. Tool comparisons like this have an expiry date. Power BI's feature set is evolving quickly (and generative AI, section 3.10, is accelerating that), so a "Power BI has no stories" answer from the session may be outdated soon. The instructor explicitly flagged the comparison for revalidation because the tools are very competitive. Treat this section as the state of play at the time of the lecture — the durable lesson is the shape of the difference (dashboards-with-widgets versus slide-deck-like story points), not the absolute feature list.
Recap and bridge. The comparison so far: Power BI leads in data engineering, cleaning, and Microsoft-ecosystem integration (JDBC/ODBC); Tableau leads in visualization and offers a dedicated storytelling layer (sheets → dashboards → stories); both connect to many data sources; no preference was declared, and the full comparison comes later. The next topic explains why this comparison may soon look very different — generative AI is entering the tools themselves.
3.10 Generative AI and the Future of Visualization Tools
3.10.1 Copilot and Auto-Generated Visuals
The tools are moving fast toward generative AI. Microsoft is doing a lot of research in AI and NLP, so Power BI may move naturally toward all these generative AI features and Copilot. Copilot features are arriving in these products — the instructor has heard Copilot is already there in Power BI in some form. The consequence may be that we do not have to build a dashboard of our own: we may just type to the Copilot, can you generate this graph for me and this table for me. Tableau is also moving aggressively toward generative AI tools, though it may not be public yet.
Copilot and auto-generated visuals. Microsoft is investing heavily in AI and natural language processing (NLP), so Power BI is moving toward generative AI features — including Copilot, which the instructor has heard is already present in Power BI in some form. The consequence may be dramatic: you may no longer build a dashboard of your own, but simply type to the assistant — "can you generate this graph for me and this table for me" — and receive the visual. Tableau is also moving aggressively toward generative AI tools, though it may not be public yet.
3.10.2 Generative AI Reading Your Data
Even now, the generative AI models like ChatGPT can analyze data for us: give them a table and tell them what do you see in this, and they will answer — this quarter your sales is less, this quarter your sales is up, because of that reason. They can analyze the data and give insights on their own, rather than us dragging and dropping to create everything ourselves. Sentiment analysis of feedback and tweets has existed for a while, but now it is getting integrated everywhere — auto insights come from the tools.
Generative AI reading your data — what it means for analysis. Generative AI models such as ChatGPT can already analyze data directly: give them a table and ask "what do you see in this?", and they answer in plain language — "this quarter your sales is less, this quarter your sales is up, because of that reason." The analyst no longer drags and drops every chart themselves; the model produces insights on its own. Sentiment analysis of feedback and tweets has existed for a while, but the change now is integration: auto insights are coming from the tools themselves, not from separate scripts.
The same pattern shows in meetings: if a meeting had the Copilot button enabled, it would go through everything happening in the discussion and give the minutes on its own — these actions were taken, that person took this action — a real-time, on-the-fly, very professional summary of the discussion.
The Copilot meeting-minutes scenario — a worked picture. Imagine a meeting with the Copilot button enabled. While the discussion happens, the assistant listens and processes everything: it produces the minutes on its own — "these actions were taken, that person took this action" — as a real-time, on-the-fly, professional summary. Nobody types the minutes; the assistant drafts them while the meeting runs. Sense-check: the pattern is the same as the data case — the human does the talking/validating, the AI does the summarizing — and the deliverable appears without manual assembly.
3.10.3 AI in the Enterprise: Service Cloud and Slack
One student, who works inside the Salesforce ecosystem, shared what is happening in industry. The company is aggressively integrating AI into all of its clouds, and the student's team is part of the service cloud. There, when a customer contacts a company and talks to a customer service representative, generative AI automatically analyzes the customer's behavior and what they are asking, and based on that it generates a response. The representative just has to validate it and then post the response. There is also a feature to rate the quality of the response the AI generated, so the model continuously learns based on the quality. Salesforce has internal large language model teams and is heavily investing everywhere; even Slack — which is also a Salesforce product — is getting integrated with AI tools, where you can respond, generate code, and more.
The AI-draft, human-validate, rate-and-learn loop. A student working in the Salesforce ecosystem described the enterprise pattern: AI is being integrated into all of Salesforce's clouds, including the Service Cloud. When a customer contacts a company, generative AI analyzes the customer's behavior and their question, and generates a response draft. The representative only has to validate it and post it. Then a rating feature scores the quality of the AI-generated response, so the model continuously learns from the ratings. Salesforce has internal large language model teams and is investing everywhere; even Slack — also a Salesforce product — is getting AI tools for responding, generating code, and more.
Real-world: the customer service workflow of the future is AI drafting, humans validating, and ratings feeding continuous learning.
Where this leaves the visualization analyst. The same loop that is transforming customer service is coming to analytics: AI drafts the visual and the insight, the human validates and refines, and usage feedback trains the model. The skills that survive are the ones AI cannot draft — knowing the audience, choosing the right story structure, judging whether an insight is true and useful. The tools of this course (storytelling, chart choice) become even more valuable as the drafting part gets automated; the judgment part does not.
3.10.4 Watch This Space
A lot is happening technologically in these areas, and a lot will change in the coming years. The advice is to keep an eye on how these things evolve — whether it is the tools themselves, auto-generated insights, or AI drafting responses. The course layout has limited line items, but industry discussions like these add more to learning, so they are always welcome.
Recap and bridge. Generative AI is entering the visualization stack on three fronts: auto-generated visuals (Power BI Copilot, Tableau's direction), auto-generated insights (ChatGPT reading tables, AI meeting minutes), and AI drafting in the enterprise (Salesforce Service Cloud, Slack). The advice is to keep an eye on these evolutions — the tools will change faster than the course material can. This matters for every later decision in the course: today's tool comparison (3.9) is a snapshot, and the next topic's chart taxonomy is the thinking you should take into the tool era.
3.11 Taxonomy of Data Visualization Methods
3.11.1 What a Taxonomy Does
The taxonomy of data visualization methods is the concept that classifies and organizes different charts and graphs. We already learned some of it informally: a bar chart is mostly used for comparisons, a scatter plot is more for correlation. The taxonomy is what helps us understand and select the right tool for the right scenario — which is quite important because we will learn storyboarding, engagement, and conclusion, but without knowing which chart to use for which kind of data, the story has no visual vocabulary.
The taxonomy — what it is and why it exists. A taxonomy (from the biological sciences: organizing members into groups that share similar characteristics) applied to data visualization is the scheme that classifies and organizes the different charts and graphs — by what they show and what they are for. We already knew parts of it informally: bar charts for comparisons, scatter plots for correlation. The taxonomy makes that knowledge systematic, and it matters because a story is only as good as its visual vocabulary: you can plan storyboarding, engagement, and conclusion perfectly, but without knowing which chart fits which kind of data, the story cannot be rendered.
3.11.2 The Dimensions of Taxonomy: Data Types
The taxonomy usually depends on the data type: whether the data is qualitative, quantitative, or temporal — the kinds of data you would cover in a statistics class. You can pick and choose your charts based on the data type.
The organizing dimension — data type. The taxonomy is usually organized around the data type: qualitative (categories and labels — names, segments, regions), quantitative (measured numbers — sales, temperature, counts), or temporal (time-stamped values — sales by month, temperature by day). These are the data types from a statistics class, and they act as the first filter on chart choice: the type of your data decides which charts are even possible before you consider which chart is best.
Tableau actually has a built-in helper for this: the "Show Me" panel. It holds a list of predefined charts and enables the ones that fit the dimensions you have in your data. For example, if you had used geospatial or geographical data, the maps would automatically get enabled. So knowing what kind of data you have tells you which charts are even possible.
Show Me — the taxonomy made executable. Tableau ships a built-in helper for exactly this reasoning: the "Show Me" panel holds a list of predefined charts and enables only the ones that fit the dimensions present in your data. Work with geospatial or geographical data and the maps automatically get enabled; work with one dimension and one measure and the bar options light up. It is the taxonomy implemented as a filter: knowing what kind of data you have tells you which charts are even possible, and Show Me is the machine-readable version of that step.
3.11.3 A Cross-Tab Cheat Sheet
The instructor shared a cross-tab reference from a book — a suggestion, not something to memorize: if the question is who or what, a chart is useful; how much, a chart; where, a map is usually the answer; when, a timeline is usually the answer, so we use a line chart and all those kinds of things.
The cross-tab cheat sheet — matching the question to the chart. The instructor shared a book's cross-tab (a table that cross-references two things — here, the question type and the chart family) as a suggestion, not something to memorize. The first dimension is the question being asked:
| Question | Typical answer |
|---|---|
| Who or what? | A chart (shows the entities and their values) |
| How much? | A chart (shows the magnitudes) |
| Where? | A map is usually the answer |
| When? | A timeline is usually the answer — use a line chart and those kinds of things |
The logic: the question determines the data dimension (entities, magnitudes, places, or time), and the dimension determines the chart family.
There is also a quick cheat sheet for comparisons: if we are comparing two variables, we use a scatter plot; if we are comparing three variables, usually there is a bubble chart; for distributions with too many points, the reference suggests a histogram — a chart that groups the individual points into intervals and shows how many fall in each — because plotting every point individually would just produce a crowded, unreadable cloud. The sheet also covers which graph to use when the data is two-variable. It is a good ready reference — those who already use Power BI will find none of it new — but it is only a reference. There is no one-size-fits-all: it all depends on your data and your audience.
The comparison cheat sheet — variables and distributions. The second dimension of the cross-tab handles comparisons by number of variables:
- Two variables being compared → scatter plot (each point pairs one value of each variable, so the relationship between them appears).
- Three variables being compared → usually a bubble chart (a scatter plot where the third variable is encoded as the size of the bubble).
- A distribution with too many points → histogram: the individual values are grouped into intervals, and the chart shows how many values fall into each interval. Plotting every point individually would produce a crowded, unreadable cloud, so the histogram sacrifices individual dots to reveal the shape of the distribution.
The sheet also covers which graph to use when the data is two-variable. Power BI users will find none of it new — it is a good ready reference for everyone else — but it is only a reference: there is no one-size-fits-all, and it all depends on your data and your audience.
The cheat sheet is a reference, not a law. The instructor explicitly framed the cross-tab as for reference only — you do not have to remember it or mug it up. Two reasons: (1) real decisions depend on your data and your audience, and no table can encode either fully; (2) the taxonomy organizes typical answers, and every chart has overlaps — an area chart, for example, shows changes over time and enables category comparison. Use the sheet to start a decision, never to end one.
3.11.4 Benefits of Knowing the Taxonomy
If we know the taxonomy, we can choose the right chart more easily — if you know you want to see the correlation between an x variable like sales and profit, you know a scatter plot is better. It improves our messaging and helps us convey the end message much more conveniently. Selection of which chart or hierarchy to use for which kind of data is a skill that pays off in every phase of the storytelling process.
The payoff — chart selection as a storytelling skill. Knowing the taxonomy speeds up chart choice: if you want the correlation between an x variable like sales and another like profit, you know a scatter plot is better before you open any tool. That speed improves messaging — you spend your time on the message, not on trial-and-error charting — and helps convey the end message much more conveniently. The skill of selecting which chart or hierarchy fits which kind of data pays off in every phase of the storytelling process: the hook needs an engaging chart, the conflict needs an interpretable one, and the resolution needs a forward-looking one — and the taxonomy is how you find each.
Recap and bridge. The taxonomy classifies charts by data type (qualitative, quantitative, temporal) and by question (who/what, how much, where, when) and by comparison shape (two variables → scatter, three → bubble, many points in a distribution → histogram). Tableau's Show Me panel automates the "which charts are possible" step, and the cross-tab is a reference, not a law. Next we work through specific chart types from the taxonomy, starting with the dot plot — the chart that shows every individual point.
3.12 Dot Plots
3.12.1 What a Dot Plot Shows
A dot plot is used for one axis: each data point is represented as a single dot. We use it when each dot has relevance to us — every individual value matters. The dots are usually positioned on one axis, typically the horizontal one, although it can be done the other way around too; the positioning stays consistent. Connecting lines between dots are optional — not a must-have. The key contrast: in a bar chart you typically need only the minimum and the maximum and you are least bothered about what is inside the bar — how many points there are — whereas the dot plot shows every single value.
The hook question. A bar chart already shows you the range of your data — so why would anyone bother drawing every single point as a dot? The answer is the whole point of this section: because the bar hides what is inside, and sometimes what is inside is exactly what you need to see. A dot plot shows every value, and every value gets a say.
Dot plot, defined. A dot plot is a chart used for a single axis, in which each data point is represented as a single dot. It is the right chart when each dot has relevance — when every individual value matters to the story. Construction details: the dots sit on one axis (typically the horizontal one, though it can be done the other way around); the positioning stays consistent for that axis; connecting lines between dots are optional, not a must-have. The contrast with the bar chart is the definition of the chart: the bar chart needs only the minimum and maximum and is least bothered about what is inside the bar (how many points are there), while the dot plot shows every single value.
3.12.2 Dot Plots versus Bar Charts
The instructor raised the natural question a student would ask:
Q: What is the difference between a dot plot and a bar chart? A bar chart also shows things like that.
A: In a bar chart you typically need only the min and the max, and you are least bothered about what is inside the bar — how many points are there. If the maximum is 100 and the minimum is 10, the bar will just say the range is between 10 and 100; if there was only one value that made it 100, you will only know that through a dot plot. The dot plot shows every single data point, so you can immediately see outliers and the skewness within each category.
Worked contrast — the bar hides the one value that matters. Suppose your data runs from 10 to 100. The bar chart shows one bar spanning that range — it tells you the range is between 10 and 100 and nothing more. Now suppose that out of 200 values, only one value is 100 and the rest cluster between 10 and 30. The bar chart looks exactly the same as before — the bar still spans 10 to 100 — and you would never know that the 100 is a lone outlier. The dot plot shows all 200 dots: 199 packed between 10 and 30, one lonely dot at 100. Sense-check: the bar told you the range; only the dot plot told you what the range was made of.
3.12.3 Outliers, Skewness, and Relationships
Because every point is visible, dot plots are good for comparing the distribution of a continuous variable across multiple categories, and for identifying outliers and skewness within each category. They also handle relationships — that is why scatter plots are always made of dots. They work for both small and large datasets, but we have to be careful: with very large data the plot can become very difficult for the end user. The definition of large varies, so you have to take a call — if it is getting very difficult, you may not be able to use it.
What dot plots reveal — outliers, skewness, relationships. Because every point is visible, dot plots are built for three jobs: (1) comparing distributions of a continuous variable across multiple categories (line the categories up side by side and the shapes of their dot clouds are directly comparable); (2) identifying outliers — a dot that sits far from the cloud; (3) identifying skewness — whether the dots pile up at one end and trail at the other, showing which side the distribution leans toward. They also handle relationships — that is exactly why scatter plots are always made of dots.
The large-data limit. Dot plots work for both small and large datasets, but with very large data the plot can become very difficult for the end user: hundreds or thousands of dots merge into an unreadable band, and the outliers you wanted to reveal get buried in the mass. The definition of large varies by context, so you have to take a call: if the plot is getting very difficult to read, you may not be able to use a dot plot, and a chart that aggregates (histogram, box plot, summary bars) becomes the honest alternative.
3.12.4 Building Dot Plots in Tableau
The instructor showed a dot plot built in Tableau the previous evening, using data on start years 2018 and 2021. It is easy to make in Tableau in the sense that any visualization in these tools is not rocket science — as long as we have the data and the right relationship, we just need to visualize what we want to present. But it is not a single drag-and-drop: it takes about ten to fifteen steps. You have to select the data and make sure all the right parameters are selected; by selecting the shape you can tell Tableau what kind of shape you want — a square makes the dots square, a circle makes them round — and you can choose the size. The instructor plans to show the full demo in the next class.
The Tableau dot plot demo — what was shown. The instructor showed a dot plot built in Tableau the previous evening, using data on start years 2018 and 2021. The demo's message was twofold. First, it is not rocket science: any visualization in these tools works the same way — as long as you have the data and the right relationship, you just visualize what you want to present. Second, it is still not a single drag-and-drop: building this plot takes about ten to fifteen steps — select the data, make sure all the right parameters are selected, then by selecting the shape you tell Tableau what the dots should look like (a square makes the dots square, a circle makes them round), and you can choose the size as well. The full step-by-step demo comes in the next class. Sense-check: the takeaway is the shape-and-size control, not the exact clicks — those come later.
3.12.5 Strengths and Limitations
The benefits: dot plots are simple, they are flexible, and you can very easily compare data by keeping things side by side. The trade-offs: they require a little bit more effort to analyze than line graphs or bar graphs, which are very straightforward to interpret — dot plots need more attention. And they are not ideal for showing trends. Bar graphs serve purposes that are not very far off from dot plots; the choice depends on whether the individual data values matter to your story.
Strengths and limitations, summed up. Strengths: simple, flexible, and very easy for comparison — put categories side by side and the dot clouds compare themselves. Trade-offs: dot plots need a little more effort to analyze than line graphs or bar graphs, which are very straightforward to interpret — dot plots demand attention; and they are not ideal for showing trends (a line chart owns that job). The strategic point: bar graphs serve purposes not very far off from dot plots, so the choice between them comes down to one question — do the individual data values matter to your story? If yes, dots; if no, bars.
Exam note: Know what dot plots show versus bar charts and when to choose one: dot plots show every individual point, exposing outliers and skewness that a bar chart hides behind its min–max span; choose dots when the distribution and individual values matter, bars when a simple comparison suffices. And remember the limit: very large data makes dot plots difficult for the end user.
3.13 Bar Graphs and Hierarchies
3.13.1 The Default Chart
The bar graph is the default chart and the easiest one to prepare and present. In Tableau it comes up almost automatically, you can sort it, toggle between values, and swap what you show — all of it is very easy. Use it when you are comparing. You can show a trend with it too, although a line chart is better for that — personally, the instructor prefers a line chart for trends, but it depends on the data.
The bar graph — the default chart. The bar graph is the default chart and the easiest one to prepare and present — in Tableau it comes up almost automatically; you can sort it, toggle between values, and swap what you show, all very easily. Its job: comparing — bar length (or height) encodes the value of each category, and the eye compares the ends of the bars instantly. It can show a trend too, although a line chart is better for trends — a personal preference for trends, but it depends on the data.
Bars are much easier to understand than dot plots because their nature and dimensions are so easy to relate to. The benefits are straightforward: simple, familiar, very easy for comparison, flexible, and usable for both large and small data. It is a simple but very well-used graph.
Why bars beat dots for comprehension. Bars are easier to understand than dot plots because their nature and dimensions are so easy to relate to: one category, one bar, one height — the mapping is one-to-one and physical, like comparing the heights of people standing side by side. Dot plots ask the reader to judge a cloud of points; bars ask the reader to judge ends of rectangles. For a mixed audience, that familiarity means the audience spends its brain power on the message instead of on decoding the chart. Benefits in one line: simple, familiar, very easy for comparison, flexible, usable for both large and small data.
3.13.2 Too Many Bars: The Brain Gives Up
The one caution: if the categories become too many, remember our brain will give up with too many bars. When that happens, think carefully — is there a way to create a hierarchy, should we roll the data up? You can also give filters to address clutter. And remember: bar graphs are for comparing, not for showing relationships — that is not their job.
Too many bars — the brain gives up. The one real caution: if the categories become too many, our brain gives up — a wall of forty bars is not a comparison, it is a wallpaper. When that happens, think carefully: is there a way to create a hierarchy (group the categories), should we roll the data up (aggregate to a higher level)? You can also give filters to let the user choose which categories to show — filters address clutter by letting the user cut it themselves. And remember the division of labor: bar graphs are for comparing, not for showing relationships — that is not their job (that is a scatter plot's job).
3.13.3 Hierarchies in Tableau
A hierarchy helps you minimize the data. In Tableau you can club fields under one another, and Tableau will automatically show you a top hierarchy; zoom into it and it creates another level for you. The instructor showed this with the Sample Superstore data, a built-in data source that ships with Tableau and is used by many teachers and channels. The product hierarchy there is category, within that subcategory, within that manufacturer — zoom into one bar and it automatically breaks down to the subcategory level; you can collapse and expand these levels by default. That is what makes it very interactive, and you can drag and drop to build your own hierarchies of logical fields — for example, products grouped so you can see product-wise sales.
Hierarchy — the answer to too many bars. A hierarchy is a structure of fields clubbed under one another, and it exists to help you minimize the data: instead of one giant flat list of bars, you get levels. In Tableau you club fields under one another and Tableau automatically shows a top hierarchy; zoom into it and it creates another level for you. The demo used Sample Superstore (a built-in data source that ships with Tableau, used by many teachers and channels): the product hierarchy is category → subcategory → manufacturer. Zoom into one bar and it automatically breaks down to the subcategory level; collapse and expand these levels by default. That interactivity is the point — the user controls the level of detail.
Worked hierarchy — the Sample Superstore product drill-down. Open the Sample Superstore data (ships with Tableau). Drag the product fields into a hierarchy: category at the top, then subcategory within it, then manufacturer within that. The initial bar chart shows categories. Click (zoom into) one category bar, and it automatically breaks down to the subcategory level — the single bar becomes its subcategories' bars; zoom again and you reach the manufacturer level. Collapse and expand by default; no extra work from you. Sense-check: what was one unreadable list of every manufacturer is now a three-level story you control, and the same pattern applies to any logical fields — for example, products grouped so you can see product-wise sales.
Dates come with a default hierarchy for free: with a shipping date, you can see things year-wise, quarter-wise, month-wise, or go into a specific day — the zooming in and out happens automatically without us doing anything.
Dates — the free hierarchy. Dates come with a default hierarchy for free: with a shipping date, you can see things year-wise, quarter-wise, month-wise, or go into a specific day — the zooming in and out happens automatically, without us doing anything. It is the same idea as the product hierarchy (roll up and drill down) applied to time, and it is built in.
3.13.4 When Bars Fail
So the bar graph is straightforward, but keep the two limits in mind: too many categories make it cluttered (answer with filters and hierarchies), and it is not good for relationships — it is for comparing.
The two limits of bars. Keep the two limits in mind: (1) too many categories make the bar graph cluttered — the brain gives up — answered with filters and hierarchies (roll up or drill down); (2) not good for relationships — a bar graph compares, it does not correlate, so a relationship question belongs to a scatter plot, not to bars. Neither limit makes the bar graph weak; both make it a specialist that must be used in its specialty.
Exam note: Bar graphs are the default comparison chart — simple, familiar, easy for comparison, flexible, large or small data — and when categories multiply, use hierarchies or roll the data up instead of adding more bars. Remember the two limits: too many categories → clutter; relationships → not a bar job. And the date hierarchy (year → quarter → month → day) is built in for free.
3.14 Dot Plots versus Bar Graphs
3.14.1 The Comparison
The instructor closed the dot-bar discussion with a read-offline comparison of the two charts, since they look similar and serve overlapping purposes.
The dot plot handles continuous data: you want to see each and every data point as a circle, you can very easily see outliers and how the spread of the data looks, and it can handle a decent number of categories and data points. The bar graph is very simple, and most of your audience will understand it; you can use it for discrete data as well as trends — but for trends over time, do consider lines.
Dot plot versus bar graph — the read-offline comparison.
| Dimension | Dot plot | Bar graph |
|---|---|---|
| Data it handles | Continuous data — every point shown as a circle | Simple; also works for discrete data and trends |
| What it reveals | Every individual point: outliers and the spread of the data are directly visible | The compared magnitudes; hides what is inside each bar |
| Interpretation effort | Needs more attention from the reader | Universally understood by most audiences |
| Categories and points | Handles a decent number of categories and data points | Handles many categories only via hierarchies/roll-up |
| Trends | Not ideal for trends | Possible, but for trends over time do consider lines |
The two charts look similar and serve overlapping purposes, but the dimension that separates them is the same one from 3.12: does the individual point matter?
The rule of thumb: choose a dot plot when the distribution and individual points matter, and the bar graph when you need a simple, universally understood comparison. Each has strengths and weaknesses, and the right choice depends on your data and your audience.
The rule of thumb, in one line. Choose a dot plot when the distribution and individual points matter (outliers, skewness, spread); choose a bar graph when you need a simple, universally understood comparison. Each has strengths and weaknesses, and the right choice depends on your data and your audience — the same closing formula as every chart decision in this course.
3.15 Floating Bar Charts
3.15.1 What a Floating Bar Is
A floating bar chart is one where the bottom of the bar is not linked to zero or the x-axis. It looks like a Gantt chart. Because the bar floats between two values, you can immediately see outliers, and you can see where the bar starts, where it ends, and what the width of the bar is.
The hook question. Every bar chart you have drawn so far grows up from zero — the axis, the baseline, the rule. But what if the thing you actually want to show is between two values — the range of a month's temperatures, the window in which a task runs? A bar that must start at zero cannot show that. The floating bar is the answer: a bar that floats, and its two ends are the data.
Floating bar chart, defined. A floating bar chart is a chart where the bottom of the bar is not linked to zero or the x-axis — the bar starts at one value and ends at another, so it visually resembles a Gantt chart (the project-scheduling chart in which each task is a bar between a start and an end date). Because the bar floats between two values, you can immediately see outliers (bars that sit far from the others), and you can see where the bar starts, where it ends, and what the width of the bar is — the span between its two endpoints.
3.15.2 Building One in Tableau: The Temperature Demo
The instructor built a floating bar on the fly in Tableau. He used month-level data and chose the value he wanted to show — the minimum temperature. The default bar came up first, not floating. Then he switched the display to a Gantt-chart style and set the width of the bar using the maximum temperature: in the size shelf, the width of the bar is the maximum temperature. The bar automatically started from the minimum temperature. So the visual shows, for each month, the range from the minimum temperature to the maximum temperature — where it started, where it ended, and the width between them.
Worked build — the monthly temperature floating bar. The instructor built the floating bar live in Tableau, on month-level temperature data. Step by step:
- Choose the starting value — the minimum temperature for each month.
- Get the default bar — it comes up first as a normal bar, not floating (the expected behavior: ordinary bars grow from zero).
- Switch the display to a Gantt-chart style — this changes what the bar means: the bar no longer grows from zero; it runs between two values.
- Set the width using the maximum temperature — in the size shelf, the width of the bar becomes the maximum temperature. The bar automatically starts from the minimum temperature.
The result: for each month, one floating bar showing the range from minimum to maximum temperature — where it started, where it ended, and the width between them. Sense-check: the two endpoints come from two fields (min sets the start, max sets the width), and that is the whole trick.
Had it been a normal bar chart, it would have shown values from zero to 45, zero to 40 — you would need a different x-axis scale, and you would not be able to understand the width of the bar. That is exactly what the floating bar adds: seeing the span that a regular bar cannot show.
Why a normal bar cannot do this. Had it been a normal bar chart, each month's bar would grow from zero to its maximum — zero to 45 for one month, zero to 40 for another. The visual would need a different x-axis scale per month to mean anything, and the width of the range would be invisible: two months with identical maxima look identical even if one spans 30 degrees and the other spans 5. That is exactly what the floating bar adds: seeing the span — the distance between the start value and the end value — that a regular bar cannot show.
3.15.3 Strengths and Risks
The benefits: it increases the visual hierarchy and helps in better storytelling — the instructor noted the bar chart would not have shown the proper data points here. It is useful for ranges.
The strengths — ranges and hierarchy. The floating bar's benefits: it increases the visual hierarchy and helps in better storytelling — the instructor noted the plain bar chart would not have shown the proper data points here. Its natural domain is ranges: temperature spans, delivery windows, task durations, any data that lives between a start and an end rather than between zero and a value.
The risks: it has a potential for misinterpretation because the x-axis varies — it is not starting at zero — so a user may struggle to read it. It depends on the data and on our storytelling. If it is too complex, it can become confusing and add clutter to the graph, so use it wisely. The instructor has not seen it used very frequently, but it is not ruled out — it depends on the kind of data. One more limit: it is not suitable for comparison, because the x-axes are variable — you cannot compare bars whose baselines are all different.
The risks — misinterpretation and non-comparability. The floating bar carries a real risk of misinterpretation, because the x-axis varies — it is not starting at zero — so a user may struggle to read it, especially one trained on ordinary bars. Risks to keep straight:
- Non-zero axis: the bar does not grow from zero, so readers who assume it does will misread lengths.
- Complexity: if it is too complex, it can become confusing and add clutter to the graph — use it wisely.
- No comparison: it is not suitable for comparison, because the x-axes are variable — you cannot compare bars whose baselines are all different. Two bars of identical width mean nothing if their starting points differ.
It depends on the data and on the storytelling; the instructor has not seen it used very frequently, but it is not ruled out. It is a specialist chart for range questions — use it there and only there.
Exam note: Understand the floating bar's defining feature — the axis does not start at zero, so the bar runs between two values like a Gantt chart — and the misinterpretation risk that follows. Know the temperature build: minimum temperature sets the start, maximum temperature sets the width in the size shelf. Strengths: ranges, visual hierarchy, storytelling. Limits: not for comparison (varying baselines), risk of clutter and misinterpretation.
3.16 Choosing a Visualization: Wrap-Up
3.16.1 No Single Correct Answer
To wrap up: there is no single correct approach to selecting a data visualization. There are various approaches, and all of them have their own strengths and weaknesses. The onus is on us to understand what we want to present, what our story is, and who our audience is — and then pick and choose. There are guidelines, but they are not theorems: no two parameters dictate that only this one graph must be used. The selection skill is flexible, and it will come with time and experience.
Guidelines, not theorems. There is no single correct approach to selecting a data visualization: various approaches exist, and all of them have their own strengths and weaknesses. The onus is on us to understand three things — what we want to present, what our story is, who our audience is — and then pick and choose. There are guidelines, but they are not theorems: no two parameters dictate that only this one graph must be used. The selection skill is flexible, and it will come with time and experience.
The recurring pattern of the whole lecture. Notice how every chart section ended the same way: it depends on your data and your audience. Dot plots versus bars (3.14), the taxonomy's no-one-size-fits-all (3.11), the graph-to-story-phase freedom (3.3), the floating bar's conditional usefulness (3.15) — one principle runs through all of them. Guidelines are starting points for thinking, not formulas that replace thinking. That is the honest summary of the entire course so far.
The trap of memorizing instead of reasoning. The tempting way to "learn" chart selection is to memorize a rule table — this chart for this case, that chart for that case. The lecture's warning is the opposite: the cross-tab is a reference, not a law; the quiz answers were reasoning exercises, not assignments of chart types to phases. If an exam or a real meeting asks you to justify a chart choice, the answer that scores is the reasoning — data type, message, audience — not the memorized cell of a table.
3.16.2 What Comes Next
The next class continues with different types of graphs, and it will be the last class that still relies on presentations for the material; from the fifth class onward, the tools enter the learning. Module two is dedicated to Tableau. Meanwhile, the habit of discussing where the industry is going — what AI and new tools are bringing — adds to learning and stays welcome even though the course layout has limited line items.
The road ahead. The next class continues with different types of graphs, and it will be the last class that still relies on presentations for the material; from the fifth class onward, the tools enter the learning, and module two is dedicated to Tableau. The storytelling concepts from today — the three-phase structure, the three-minute story, the big idea, storyboarding — will be revisited in recap, and the next session includes a full demo of building a dot plot in Tableau. The habit of discussing where the industry is going — what AI and new tools are bringing — adds to learning and stays welcome even though the course layout has limited line items.
Recap and handoff. There are guidelines, not theorems; chart selection is a flexible skill built from data type, message, and audience, and it comes with time and experience. The three-phase story structure, the named storytelling concepts (three-minute story, big idea, storyboarding), and the chart types of this unit (dot plot, bar graph, floating bar) are now in your toolkit — with the Tableau side of the course coming from the fifth class onward.
Exam Guidance Summary
No exam-specific guidance was given in this session, so treat this section as a consolidation of the study signals the session did provide.
How to study this unit. The storytelling material is concept-heavy: the three-phase structure (setup, conflict, resolution), the three-minute story, the big idea, and storyboarding are the named concepts of this unit, and each was explicitly defined in class. Know what each phase does and what the alternative names (such as villain and hero in one book) refer to. The storytelling section of an assessment will likely test definitions and the reasoning behind chart choices, not a memorized table.
- Chart choice is a reasoning skill, not a memorized table. The session repeatedly stressed that there is no fixed mapping between graphs and story phases — the answer depends on data and audience. For assessments, expect to justify a chart choice rather than recite a rule.
- The cross-tab cheat sheet shared in class is for reference only — the instructor explicitly said it does not need to be remembered or mugged up.
- The course handout is the reference list of chart types covered in this unit (dot plot, bar graph, floating bar among them).
- For the hands-on part of the course: module two is entirely Tableau, and the experiential learning assignment is expected to come from Tableau, so arranging the Tableau student license early is practical study advice.
- The next session will revisit the storytelling concepts in recap, and will include a full demo of building a dot plot in Tableau.
The chart-type essentials to carry forward. From the chart sections, the exam-relevant core is: dot plots show every individual point (outliers, skewness, spread) and are chosen when the distribution and individual values matter; bar graphs are the default comparison chart, with hierarchies and roll-up as the answer to too many categories, and they are not for relationships; floating bars run between two values (not from zero) like Gantt charts — useful for ranges but with a misinterpretation risk and unsuitable for comparison. Each choice is justified by data type, message, and audience — the reasoning, not the rule, is what gets tested.
Key Industry Applications
- Storytelling as an executive-communication practice: the multimillion-dollar program case shows how setup, conflict, and resolution narratives win stakeholder support and decisions — a simple slide deck, not a tool report, carried a program from deep red to senior-management backing.
- Decision-oriented presentations: the monthly burn-rate visual with one-month and two-month delay impacts is a real pattern for cost-overrun conversations — emotion (fear) plus a visual proof of the cost of not acting is how executive decisions get made in industry.
- The three-minute story and the big idea are standard marketing and management concepts for elevator pitches and executive check-ins — the lift-meeting summary and the one-sentence status-plus-ask.
- Storyboarding with sticky notes, physical or virtual (Miro, Mural), is standard workshop practice for planning narratives before any slide is designed.
- Tableau storyboards: sheets to dashboards to stories is the official Tableau workflow, shown on sales data (segments, states, word clouds, year outlook, interactive dashboards).
- Tableau's Sample Superstore data is a common built-in practice dataset that ships with the tool — used by many teachers and channels for hierarchies and drills.
- Industry licensing practices: Tableau offers free one-year student licenses through university emails; Tableau Public is a free but restricted alternative; Power BI Desktop is free for everyone.
- Power BI is used in industry for data engineering, cleaning, and Microsoft-ecosystem integration via JDBC/ODBC drivers; Tableau is favored for visualization and story building. The two tools are competitive, and feature comparisons should be revalidated over time.
- Generative AI is entering visualization: Power BI Copilot, Tableau's generative AI direction, ChatGPT reading tables and producing insights, AI meeting minutes, and Salesforce Service Cloud using AI-drafted, human-validated customer responses with rating-based continuous learning — the AI-draft, human-validate, rate-and-learn loop is spreading from customer service into analytics itself.
DVI Lecture 3 notes · Storytelling and the Taxonomy of Visualization Methods
Sections Breakdown
Recap of the design toolkit from earlier sessions: cluttering as excess visual noise that buries the core message, pre-attentive attributes (orientation, length, width, size, shape) as features the eye notices unconsciously, and visual hierarchy as the concept that prioritizes the most important information and navigates the eye's flow.
Storytelling is presenting data or findings in a flow — a well-knit blend of visuals, narrative, and data that helps the user understand and take a decision. Stories stick longer and more accurately than random slide decks; know your audience and purpose before building, and carry the narrative with emotion plus strong visuals such as the monthly burn-rate example.
Every story follows three phases: setup (hook and engage, showing where we were and how we traveled), conflict (the crux: causes and risks, what happens if we do nothing), and resolution (the after state: if we do this, this is what will happen). Quiz walkthroughs showed the animated bar chart and heat map winning the hook, the bar chart winning the conflict, and the area chart closing the resolution — but graphs are interchangeable between phases, and there is no formula, only data and audience. Different books rename the phases (villain, hero); never shuffle the sections.
A real multimillion-dollar program was deep red: testing was collapsing, the business-development-testing blame triangle had collapsed, and go-live was at risk. The team told a three-phase story instead of arguing: setup (KPIs and why the program is critical), conflict (timelines will slip, cost impact, vendor revised cost, rework, quantified), resolution (defined responsibilities for business, testers, development, daily standups to distribute defects). Senior management gave full support. It was a simple slide deck, not a tool report.
Do: know your audience (the foundation), keep purpose and narrative clear, dry-run from the audience's seat, bring emotion (fear or inspiration), make visuals strong (less text, pre-attentive attributes, no clutter), keep practicing and refining. Do not: overload with information, use technical jargon (quiz: jargon is not a key element — accuracy, clarity, anecdotes are), go too high level or too plain, stop at the story, ignore feedback. Always close the loop with an action, recommendation, or ask.
Three named storytelling concepts: the three-minute story (crisp summary for a lift or cafeteria meeting, because you may get only five minutes), the big idea (tell everything in one sentence — pilot met all criteria so we need more funding; two open issues with a workaround and business approval so we need board approval), and storyboarding (sequential sticky-note planning, physical or virtual with Miro and Mural, before any slide is designed).
A Tableau story is a slide-deck-like flow built bottom-up: sheets (worksheets) make dashboards, and sheets plus dashboards make stories via separate icons. The demo story walked from consumer sales highest among segments, to California best by color, to a California-New York word cloud, to a strong 2021 outlook, closing with an interactive dashboard. Story points: add a blank point, drag and drop a visual, change the sequence by dragging.
Tableau access is worth arranging for module two and the experiential learning assignment: students get a free one-year license via the Tableau website using a university email (possibly with an admission letter or course handout), and the key arrives by email — start early. Tableau Public is free but has fewer features with a short trial; Power BI Desktop is free for everybody. Tableau is a Salesforce product (bought around seven to eight years ago), so its roadmap is Salesforce-driven.
Power BI leads in data engineering and cleaning (union, table drags, field format/split, mapping exist in Tableau but not at Power BI scale). Power BI is Microsoft-backed with native Microsoft integration plus JDBC/ODBC drivers; Tableau also offers many data-source options. Power BI does not currently offer a story concept like Tableau's — dashboards with widgets are the final version, like Excel sheets with a summary first (to be revalidated). No preference declared; full comparison comes later.
Generative AI is entering visualization: Power BI Copilot and Tableau's generative AI direction may let us type 'generate this graph' instead of building dashboards; ChatGPT already reads tables and gives insights; Copilot can produce real-time meeting minutes. In the enterprise, Salesforce Service Cloud has AI drafting responses that representatives validate, with rating-based continuous learning, and Slack is getting AI tools.
The taxonomy classifies and organizes charts by data type (qualitative, quantitative, temporal) and question (who/what and how much → chart, where → map, when → timeline/line). Comparison cheat sheet: two variables → scatter plot, three variables → bubble chart, distribution with too many points → histogram. Tableau's Show Me panel enables only the charts that fit the data dimensions. The cross-tab is a reference, not to be memorized — no one-size-fits-all.
A dot plot represents each data point as a single dot on one axis (usually horizontal), used when every individual value matters. Unlike a bar chart, which needs only min and max and hides what is inside the bar, dot plots show every point, exposing outliers and skewness within categories, and support relationships (scatter plots are made of dots). Tableau build takes 10–15 steps with shape and size selection; demo used start years 2018 and 2021.
The bar graph is the default chart — the easiest to prepare and present, for comparing (not relationships; line charts are better for trends). Too many categories make the brain give up: use hierarchies or roll the data up, and filters to address clutter. In Tableau, hierarchies club fields (Sample Superstore: category → subcategory → manufacturer; dates: year → quarter → month → day) with automatic zoom/collapse.
The read-offline comparison: dot plots handle continuous data, show each point as a circle, expose outliers and the spread, and handle a decent number of categories and points; bar graphs are simple and universally understood, work for discrete data and trends (but consider lines for trends over time). Rule of thumb: dot plot when distribution and individual points matter, bar graph for a simple, universally understood comparison.
A floating bar chart has its bottom not linked to zero or the x-axis — it looks like a Gantt chart and shows where the bar starts, ends, and the width between. Tableau build: minimum temperature sets the start, switch to Gantt style, maximum temperature sets the width in the size shelf. Benefits: visual hierarchy, storytelling, ranges. Risks: misinterpretation because the axis does not start at zero; not suitable for comparison since baselines vary.
There is no single correct approach to selecting a visualization: understand what to present, the story, and the audience, then pick and choose. Guidelines exist but are not theorems — no two parameters dictate one graph. The skill is flexible and comes with time and experience. Next class continues with graph types and is the last presentation-based class; tools enter from the fifth class onward and module two is Tableau.
Consolidation of study signals: the storytelling concepts (three-phase structure, three-minute story, big idea, storyboarding) are the named concepts of the unit; chart choice is a reasoning skill, not a memorized table; the cross-tab cheat sheet is reference only; the course handout lists the chart types; arrange the Tableau license early for module two; the next session revisits storytelling in recap and demos the dot plot in Tableau.
Industry applications: executive storytelling for program rescue (setup-conflict-resolution deck), burn-rate visuals for cost-overrun conversations, elevator pitches (three-minute story, big idea), storyboarding workshops (Miro, Mural), Tableau sheets-to-dashboards-to-stories workflow on sales data, Sample Superstore practice data, licensing practices, Power BI versus Tableau division of labor, and generative AI entering visualization (Copilot, ChatGPT insights, AI minutes, Service Cloud AI-drafted responses with rating-based learning).
Exam Revision Notes
Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.
Recap: Cluttering, Pre-Attentive Attributes, and Visual Hierarchy
Must-know: Clutter = excess of too many things on a screen where the user struggles with the core message. Pre-attentive attributes = features noticed unconsciously (orientation, length, width, size, shape). Visual hierarchy is the design concept that prioritizes the most important information and navigates the screen's flow.
⚠️ Top pitfall: Tool bias: answering every chart question with the tool you already know instead of starting from message, audience, and chart shape.
Self-check: Which design concept prioritizes the most important information most effectively?
Connects to: 3.2 (Storytelling Foundations)
Storytelling Foundations
Must-know: Storytelling = process of creating a story from findings, presented in a flow; blends visuals, narrative, and data; explains, engages, and entitles; ultimate aim is to help the audience take a decision. Stories are remembered longer and more accurately than random slide decks.
⚠️ Top pitfall: Polishing individual slides and stopping there: a beautiful deck without a story is forgotten; also giving executives weekly numbers instead of business value and benefit.
Self-check: What two things must you know before writing a single slide?
Connects to: 3.1 (Recap: Cluttering, Pre-Attentive Attributes, and Visual Hierarchy), 3.3 (The Three-Phase Story Structure)
The Three-Phase Story Structure
Must-know: The three phases: setup hooks and engages (trend, where we were to present state); conflict is the crux — causes and risks, why the change happened and what happens if we do nothing; resolution shows the after state — if we do this, this is what will happen. Graphs are interchangeable between phases; there is no formula.
⚠️ Top pitfall: Shuffling between sections (resolution mid-story, then back to conflict) breaks the hierarchy; also treating quiz chart choices as fixed rules instead of reasoning exercises.
Self-check: Why did the heat map beat the line graph for the hook stage, and why did the bar chart beat the scatter plot for the conflict stage?
Connects to: 3.2 (Storytelling Foundations), 3.4 (A Storytelling Case Study: The Multimillion-Dollar Program)
A Storytelling Case Study: The Multimillion-Dollar Program
Must-know: The case proves that narrative, visualization, and facts built around setup–conflict–resolution engage users better and win decisions and support — not that every red program turns green. The medium does not matter (simple deck, paper, spoken); the structure behind the words does.
⚠️ Top pitfall: Reading the lesson as 'stories guarantee success' — the honest lesson is engagement, not guaranteed green status; also presenting the problem without the quantified cost of doing nothing.
Self-check: What three elements did the team's resolution contain, and what mechanism distributed the defects?
Connects to: 3.3 (The Three-Phase Story Structure), 3.5 (Storytelling Do's and Don'ts)
Storytelling Do's and Don'ts
Must-know: The do's and don'ts checklist: audience first, clear purpose and narrative, dry run, emotion, strong visuals, practice. Avoid overload, jargon, extremes of too-high-level or too-plain, stopping without a decision, ignoring feedback. Every story must end with an action, recommendation, or ask — closing the loop.
⚠️ Top pitfall: Leaving the ask out — the audience says 'come back and tell us what to do' — and using technical jargon the end user cannot understand.
Self-check: Which of accuracy, clarity, anecdotes, and technical jargons is NOT a key element of effective storytelling, and why?
Connects to: 3.2 (Storytelling Foundations), 3.4 (A Storytelling Case Study: The Multimillion-Dollar Program)
The Three-Minute Story, Big Idea, and Storyboarding
Must-know: Three-minute story: the whole communication, told crisply in three minutes for lift/cafeteria stakeholder meetings. Big idea: overall opportunity or status in one sentence (success + status + ask). Storyboarding: planning the sequence one block at a time with sticky notes, physical or virtual (Miro, Mural), before designing slides.
⚠️ Top pitfall: Starting with presentation software instead of storyboarding first, which locks in bad ordering because rearranging means redoing work.
Self-check: Give the one-sentence big idea for the pilot example from class.
Connects to: 3.2 (Storytelling Foundations), 3.7 (Stories in Tableau: Sheets, Dashboards, and Story Points)
Stories in Tableau: Sheets, Dashboards, and Story Points
Must-know: The sheet → dashboard → story flow: individual sheets make a dashboard; sheets and dashboards together make a story (separate Tableau icons for each). Story points: add a blank point, drag and drop a visual into it, change the sequence by dragging. Not every sheet must enter a dashboard or story.
⚠️ Top pitfall: Confusing the assembly direction — stories are built bottom-up from sheets through dashboards, not the other way around.
Self-check: What are the three steps to add content to a story point?
Connects to: 3.6 (The Three-Minute Story, Big Idea, and Storyboarding), 3.8 (Tableau Student Licensing and Setup)
Tableau Student Licensing and Setup
Must-know: Free one-year Tableau student license via university email (admission letter or course handout may be needed; key emailed — start early). Tableau Public: free but fewer features, restricted trial. Power BI Desktop: free for everyone. Tableau is a Salesforce product affecting its roadmap.
⚠️ Top pitfall: Leaving the license arrangement to the last week — the verification and key delivery take time and the hands-on module does not wait.
Self-check: What proof of student status may the Tableau license process require, and why start early?
Connects to: 3.9 (Power BI versus Tableau: A Tool Comparison), 3.10 (Generative AI and the Future of Visualization Tools)
Power BI versus Tableau: A Tool Comparison
Must-know: Power BI: data engineering, cleaning, Microsoft-ecosystem integration, JDBC/ODBC drivers, free Desktop. Tableau: visualization strength, a bit of cleaning (union, drag tables, format/split fields like CA1, mapping), many data sources, dedicated story feature. Power BI storytelling: dashboards with widgets, no Tableau-style story concept (to be revalidated).
⚠️ Top pitfall: Treating the tool comparison as permanent — the instructor will revalidate because the tools are very competitive and features move fast.
Self-check: What Tableau data-cleaning capabilities were mentioned, and what does Power BI offer instead at a larger scale?
Connects to: 3.8 (Tableau Student Licensing and Setup), 3.10 (Generative AI and the Future of Visualization Tools)
Generative AI and the Future of Visualization Tools
Must-know: Generative AI trends in visualization: Copilot in Power BI (type to generate graphs and tables), Tableau moving aggressively, ChatGPT analyzing tables and producing insights, AI meeting minutes, and the enterprise AI-draft / human-validate / rate-and-learn loop (Salesforce Service Cloud, Slack).
⚠️ Top pitfall: Assuming today's tools and feature lists will stay stable — the advice is to keep an eye on how these things evolve.
Self-check: What three components make up the customer-service AI workflow described in class?
Connects to: 3.9 (Power BI versus Tableau: A Tool Comparison), 3.16 (Choosing a Visualization: Wrap-Up)
Taxonomy of Data Visualization Methods
Must-know: Taxonomy classifies charts by data type (qualitative, quantitative, temporal) and by question: who/what and how much → chart; where → map; when → timeline (line chart). Two variables → scatter; three variables → bubble chart; distribution with too many points → histogram. Show Me enables only charts fitting the data dimensions.
⚠️ Top pitfall: Mugging up the cross-tab cheat sheet — it is explicitly a reference only, and no chart choice is one-size-fits-all; decisions depend on data and audience.
Self-check: If you want the correlation between sales and profit, which chart does the taxonomy point to?
Connects to: 3.12 (Dot Plots), 3.13 (Bar Graphs and Hierarchies), 3.14 (Dot Plots versus Bar Graphs)
Dot Plots
Must-know: Dot plot: one dot per data value on a single axis; shows every point so outliers and skewness appear, unlike bars that need only min and max. Good for comparing distributions across categories and relationships; not ideal for trends; very large data becomes difficult for the end user.
⚠️ Top pitfall: Using a dot plot on very large data — the plot becomes difficult for the end user; also reading a bar's span as if it showed the distribution inside.
Self-check: If the maximum is 100 and the minimum is 10, what can a dot plot reveal that the bar chart cannot?
Connects to: 3.13 (Bar Graphs and Hierarchies), 3.14 (Dot Plots versus Bar Graphs), 3.11 (Taxonomy of Data Visualization Methods)
Bar Graphs and Hierarchies
Must-know: Bar graph = default comparison chart: simple, familiar, flexible, large or small data. Too many categories → brain gives up → hierarchy, roll-up, filters. Not for relationships. Tableau hierarchy: club fields (category → subcategory → manufacturer); dates come with year → quarter → month → day for free.
⚠️ Top pitfall: Overloading a bar chart with too many categories (the brain gives up) or using bars to show relationships, which is not their job.
Self-check: What are the two limits of the bar graph and the two answers to too many categories?
Connects to: 3.12 (Dot Plots), 3.14 (Dot Plots versus Bar Graphs), 3.15 (Floating Bar Charts)
Dot Plots versus Bar Graphs
Must-know: Dot plot: continuous data, every point visible as a circle, outliers and spread directly seen, decent number of categories/points. Bar graph: simple, universally understood, discrete data and trends OK (but consider lines for time trends). Choose dots when distribution and individual points matter; bars for simple comparisons.
⚠️ Top pitfall: Using a bar graph when the individual points and distribution are the story — the bar hides what is inside.
Self-check: When do you choose a dot plot over a bar graph, in one sentence?
Connects to: 3.12 (Dot Plots), 3.13 (Bar Graphs and Hierarchies)
Floating Bar Charts
Must-know: Floating bar: bottom not linked to zero/x-axis, like a Gantt chart; shows start, end, and width. Build: minimum temperature starts the bar, switch to Gantt display, maximum temperature sets width in the size shelf. Benefits: visual hierarchy, storytelling, ranges. Risk: misinterpretation with non-zero axis; not suitable for comparison.
⚠️ Top pitfall: Misreading a floating bar as a zero-based bar — the axis does not start at zero, and bars with different baselines cannot be compared.
Self-check: In the temperature demo, which field set the start of the bar and which set its width?
Connects to: 3.13 (Bar Graphs and Hierarchies), 3.14 (Dot Plots versus Bar Graphs), 3.11 (Taxonomy of Data Visualization Methods)
Choosing a Visualization: Wrap-Up
Must-know: Guidelines, not theorems: no single correct chart; selection depends on what you present, the story, and the audience, and comes with time and experience.
⚠️ Top pitfall: Memorizing a rule table instead of reasoning about data type, message, and audience.
Self-check: What three things must you understand before choosing a visualization?
Connects to: 3.11 (Taxonomy of Data Visualization Methods), 3.12 (Dot Plots), 3.13 (Bar Graphs and Hierarchies), 3.14 (Dot Plots versus Bar Graphs), 3.15 (Floating Bar Charts)
Exam Guidance Summary
Must-know: Named concepts: three-phase story structure (setup, conflict, resolution, with alternative names such as villain and hero), three-minute story, big idea, storyboarding. Chart choice is reasoning, not memorization; the cross-tab is reference only; module two is Tableau, so arrange the student license early.
⚠️ Top pitfall: Treating the cross-tab cheat sheet or quiz chart choices as fixed rules to memorize — the session explicitly said the reference does not need to be mugged up.
Self-check: Which named storytelling concepts should you be able to define for this unit?
Connects to: 3.3 (The Three-Phase Story Structure), 3.6 (The Three-Minute Story, Big Idea, and Storyboarding), 3.7 (Stories in Tableau: Sheets, Dashboards, and Story Points), 3.11 (Taxonomy of Data Visualization Methods), 3.12 (Dot Plots), 3.13 (Bar Graphs and Hierarchies), 3.15 (Floating Bar Charts)
Key Industry Applications
Must-know: Real-world patterns: storytelling wins executive decisions (program case); burn-rate visuals prove cost of delay; three-minute story and big idea for elevator pitches; storyboarding with sticky notes (Miro, Mural); Tableau sheets → dashboards → stories; Sample Superstore practice data; free student licensing; Power BI data engineering versus Tableau visualization; generative AI drafting with human validation and rating-based learning.
⚠️ Top pitfall: Delivering a tool-driven report instead of a structured story — the case study succeeded with a simple slide deck.
Self-check: Name two real industry applications of storytelling mentioned in this lecture.
Connects to: 3.4 (A Storytelling Case Study: The Multimillion-Dollar Program), 3.7 (Stories in Tableau: Sheets, Dashboards, and Story Points), 3.10 (Generative AI and the Future of Visualization Tools)
Was this lecture useful?
BitsNotes AI Assistant
Subject Notes AssistantConfigure AI Chat
Choose how to access the chatbotSigned in as
Powered by BitsNotes — 20 messages per day. No API key needed. Want unlimited access? Use "Bring Your Own Key" mode.
Sign in to use AI Chat
Get 20 free AI messages per day to ask questions about your lecture notes. Sign in with Google or GitHub — it takes 5 seconds.
Sign In to BitsNotesSwitch to "Bring Your Own Key" tab above for unlimited access with any OpenAI-compatible provider.