Dashboard and Story Building in Tableau
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
- Dashboards as collections of worksheets — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second)
- Individual sheets as the building blocks — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second)
- Stories and story points as narrated walkthroughs — covered in Lecture 10 (Stories and Storyboards: Dashboards That Narrate)
- Layout, containers, and fitting the screen — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second)
- Device preview and export options — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second)
- Interactivity with filters — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second) and Lecture 7 (Filtering the Data)
- Color consistency across sheets — covered in Lecture 10 (Tableau Dashboards: Sheets First, Assembly Second)
- Titles and captions — covered in Lecture 7 (Titles and Captions)
- Calculated fields — covered in Lecture 7 (Metadata Management and Calculated Fields)
- Visual perception, pre-attentive attributes, and Gestalt principles — covered in Lecture 10 (Visual Perception and Why Visualization Matters)
This session is the hands-on wrap-up of the Tableau module. Everything before this built individual sheets — the true building blocks — and today we put those blocks together into dashboards and stories, looking at the typical do's and don'ts and the tricks of both. With this, the Tableau module is complete; from the next session onward the course shifts to the other form of data visualization: Python-based plotting libraries.
Think of the earlier sessions as learning to take individual photographs, and today as learning to lay those photographs out in an album and to narrate the story the album tells. The photos are the hard part; the album and the narration are where the craft of presentation takes over.
11.1 Recap and Course Roadmap
11.1.1 What We Covered in the Last Session
The previous session spent a decent amount of time on DIY analytics platforms: what they actually are, the myths people hold about them (what people think they are or are not), and where the future trends and opportunities lie. Those platforms are likely to integrate with AI and become voice-enabled, and all of these things will make them even more user friendly. Tableau was covered as one of the DIY data visualization tools.
The short version of "why this all matters": a dashboard is only as good as the building blocks it combines, and those building blocks only communicate because of how our eyes and brains work. Today's session is the payoff — everything from last time comes together in practical form.
From there we moved into short-term memory and visual encoding — how our mind and brain actually holds and processes data, with a short video showing how these factors play an important role in data visualization. We then learned about pre-attentive attributes (the features the eye picks up before conscious attention) and the Gestalt principles of perception. We saw the differences between these two, and then how all of these can be combined together to make a dashboard. Everything from last time comes together today in practical form.
11.1.2 Today's Agenda and the Road Ahead
Today's plan: a quick recap, then dashboard building — what some of the best practices are, how the size and layout works, and how dashboards are usually designed — and then we move on to stories. The approach is to show already-built dashboards and stories while replicating some of the steps live in the background, so the workflow can be seen real time rather than just animated.
With this session, the Tableau module (module 3) is complete. From next week onward the focus shifts to other forms of data visualization: Python-based libraries. The plan is Matplotlib first, then Seaborn, then Bokeh. Power BI and Tableau are beautiful products, but they are definitely not the only sources of data visualization, and these libraries open the same capability in code.
One honest expectation to set: building dashboards and stories is much simpler than the individual sheets. The sheets are where the real work lives, because dashboards and stories are nothing but combinations of those sheets. What is learnable is how to build a dashboard; what is not is the judgment of which KPIs to pick — that depends entirely on your understanding of the data, your analytic skills, your organization, and your own skill set.
And dashboarding comes with practice. It is not rocket science, but if you only listen and never practice, you will listen and then forget. Keep practicing after every session.
11.2 The Worksheet–Dashboard–Story Hierarchy
11.2.1 Worksheets, Dashboards, and Stories
A worksheet (also called a sheet) contains a single view — one chart, one map, one table built from the data, for example sales by segment or sales by state. We create these individual views first. A dashboard is a collection of multiple worksheets arranged on one canvas. When you create a new dashboard (via the New Dashboard button or the top menu), you see all the individual sheets you have created and you choose which ones to include — it is not necessary to use every sheet. A story is one step further: a sequence of worksheets and dashboards presented as a narrated walkthrough. This is where you create multiple story points that combine individual sheets and whole dashboards.
The hierarchy is fixed: individual sheets → dashboards → stories. When you create a story, it offers all your sheets and all your dashboards as options, and it does not care whether a dashboard has content on it or not — you build the story from whatever options exist.
The individual sheets are the true building blocks of everything that follows — building dashboards and stories is much simpler than building those sheets, because dashboards and stories are nothing but combinations of the sheets. Think of it like building with Lego bricks: the sheets are the carefully assembled bricks, the dashboard is the display board you pin them onto, and the story is the guided tour you give someone across that board.
A concrete example of the narrated style: "Our sales are quite good. Customer sales is the best. California is the highest. New York is the second largest profit share. Our sales are going up." Each of those sentences is a story point with the supporting sheet or dashboard underneath it. That is what a story is — a narrated walkthrough of one or more sheets or dashboards.
11.2.2 What a Dashboard Can Contain
A dashboard is not limited to sheets. It can also include:
- Text boxes — your own commentary, for example "this dashboard is for my company's data."
- Images — for example, the logo of your company placed at the top, wherever you want it.
- URLs / web pages — an embedded live web page.
So in addition to the sheets, you can place your own text, your own image, and a web page into the same canvas, and position each of them where you want. The other object types will be touched later in the course.
11.2.3 Blue Icons Show Which Sheets Are Used
Once a sheet is placed on a dashboard, a blue tick (blue icon) appears next to its name in the sheets pane. For example, if segment sales, subcategory sales, and state sales are used in a dashboard and two other sheets are not, only the three used ones carry the blue icon. This is the quick visual way to differentiate which sheets are part of the dashboard and which are not — useful when you have many sheets.
11.2.4 How Data Reflects Between Sheets, Dashboards, and Stories
Worked example — data propagation. This is a worked demonstration of how edits move between the three levels. Take a sheet with all the countries, one with shipping costs by shipping mode, and one with a running total. Drag the shipping-cost sheet into a dashboard — the blue icon appears the moment it is dropped — and drag the same sheet into a story as well. Now the same sheet is used in both places.
The rule for the direction of propagation:
- Change something in the underlying sheet (for example, filter out Africa). The dashboard reflects it automatically, and the story reflects it automatically.
- Change something in the dashboard (for example, remove Europe from a filter). The individual sheet updates too, and the story also updates.
- Change something in the story (for example, remove the United States). Neither the dashboard nor the individual sheet updates back.
The summary that is easiest to remember: changes to a sheet or dashboard update across sheets, dashboards, and stories. However, stories have a slightly different behavior — any change made in a story does not reflect back into the sheet and the dashboard. That is the hierarchy of data propagation, and with practice this behavior becomes second nature.
11.2.5 Duplicating Sheets for Independent Use
Because of that one-way behavior, you may sometimes want a cleaner setup: create a copy of the same sheet, use one copy in the dashboard and the other in the story, and then modify each independently. To do this, right-click the sheet in the sheets pane and choose Duplicate. A duplicate copy appears (the original keeps its blue icons; the copy can be used wherever you like). This is purely an individual choice — use one sheet for the dashboard and its copy for the story if you want them to behave differently.
11.2.6 Hiding and Unhiding Sheets
When you are presenting, it is better to focus on the finished dashboards and stories, so you can hide the sheets that are in use. Any sheet that is part of a dashboard or a story gets a hide option. A sheet that is not used in any dashboard or story does not get a hide button at all — there is no point hiding it, because you could never unhide it. So if you see a sheet without a hide button, it is simply not referenced anywhere.
Pitfall: forgetting which direction the propagation flows. Students routinely assume the hierarchy is symmetric — that an edit in the story must also travel back into the sheet. It does not. Only sheet-level and dashboard-level edits propagate everywhere; story edits stay inside the story. If you want the story and the dashboard to drift apart, duplicate the sheet first (11.2.5) instead of fighting the one-way behavior.
To bring a hidden sheet back: go to the dashboard, right-click, and choose Unhide — the sheet returns. Or use the sheet icon shown for the hidden sheet, which takes you to that sheet, unhides it, lets you make changes, and lets you hide it again. And remember, any change you make to a sheet while it is unhidden propagates into the dashboard and the story.
Remember the direction: sheet and dashboard changes flow everywhere; story changes flow nowhere but the story. This one-way rule is the single most important behavior of the worksheet–dashboard–story hierarchy, and it is why duplicating sheets exists.
11.3 Dashboard Sizing, Layout, and Placement
11.3.1 The Dashboard Workspace
A dashboard looks different from a worksheet. In a worksheet you work with data — tables, dimensions, measures. In a dashboard you work with sheets and objects. The size area at the top gives you the layout options, and in the sheets/objects pane you pick what to bring onto the canvas.
The mental switch: in a worksheet your raw material is fields; in a dashboard your raw material is finished views. The dashboard is not a place to recompute numbers — it is a place to compose.
11.3.2 Fixed, Automatic, and Range Sizing
Every dashboard has three sizing options:
- Fixed — the dashboard has a fixed setup with preset dimensions. Choosing fixed reveals a dropdown of predefined sizes (desktop browser, generic desktop, full screen, and so on), and you can also give your own custom dimensions.
- Automatic — the dashboard fills all the space that is available. Whatever dimension the browser window has, the dashboard resizes automatically and fits the space, eliminating gaps.
- Range — you give your own pixel range and define the boundaries, i.e. how much the dashboard is allowed to grow and shrink.
There is also a device preview, which shows how the layout will look on a given device — a preview of the dashboard before you finalize it.
| Sizing option | What it does | Best when |
|---|---|---|
| Fixed | Locks dimensions to a preset or custom pixel size | A known display target, e.g. a fixed projector screen |
| Automatic | Expands/contracts to fill whatever space exists | Browser-based viewing on varied window sizes |
| Range | Grows and shrinks only within your pixel bounds | You need some flexibility without losing the layout |
11.3.3 Decide Size and Device Upfront
The standing advice: make up your mind about the size and the target device before you start designing. Decide with your business stakeholders or subject matter experts: who is the audience, should the dashboard be desktop-preferred, should the size be flexible? If you lock these choices upfront, your layout, your spacing, and your available space are all clear from the start, and designing later gets easier. Changing things on the fly means dragging, resizing, and redesigning mid-build.
Exam note: Decide dashboard size and target device upfront with stakeholders before designing. The alternative — redesigning on the fly — is how dashboards become late and cluttered.
11.3.4 Adding Sheets and Placing Them
Worked example — adding and placing sheets. Adding a sheet to a dashboard is very easy. Either drag the sheet straight onto the canvas, or double-click it and it comes in. The first view you place automatically takes the whole space — the sheet and everything that came with it (its icons, menus, legends, and filters). After that, you place subsequent sheets wherever you want: as you move your mouse across the canvas, a gray area shows the drop zone, and you can drop on top, on the right, at the bottom, and so on. The layout adjusts automatically around your drop. You can then grab the panes between items to resize each container. The blue icons in the sheets pane keep telling you which sheets are used.
11.3.5 Logical Placement
Placing is not random — it should flow logically. A typical pattern: start with an overall world view (the country map), then show a specific breakdown into it, then a detail. First sheet takes the whole page; after that you decide where the next sheet makes sense. The placement must stay readable, so think about what the eye should meet first and what supports it.
11.3.6 Rearranging Sheets
Placement is never permanent. Hover over the top bar of a sheet and the move icon appears; drag the sheet to a new position and the layout reflows around it. You can also pick a sheet up from the top bar menu and rearrange your dashboard at any time.
Pitfall: treating every sheet as equally important. If the map is the anchor of the story, it should own the prime position and the largest container. A dashboard whose most important view is squeezed into a corner forces the eye to hunt — place the supporting views around the anchor, not the other way around.
11.4 Titles, Filters, and Scroll Bars
11.4.1 Dashboard and Sheet Titles
Titles are very important for effective communication. By default, the titles you see inside a dashboard are the individual sheet names that came in with each view. There is also a dashboard title, controlled by a checkbox at the bottom — by default the dashboard title is unchecked, so the sheet titles show. You can decide which one wins: hide the individual sheet titles and retain the bigger dashboard title, or keep the sheet titles; it depends on your data and your layout.
You can edit any title by double-clicking it. The default name (for example "Dashboard 2") can be changed to something meaningful, and you get word-processor style control: center the line, change the font, make it bold, and so on.
11.4.2 Runtime Fields in Titles
Titles can be made dynamic. When you double-click a title, you can insert a field into it — for example the Market or Country field. Now the title becomes a runtime value: select the United States in a filter and the title changes to "Shipping cost for US" on the fly; select another country and it changes again. The fields that can be inserted are offered to you; you pick whichever fits.
This is a genuine interactivity feature. Almost every session has stressed how important interactivity is — the user should always remember what exactly they are clicking. With a runtime title, it is automatically clearer: "this is all US data, my US shipping costs are this." The title stays engaged with the user's current selection, and that makes the dashboard more engaging.
11.4.3 Removing Scroll Bars with Entire View
If a sheet inside a dashboard shows a scroll bar, there are two ways to fix it. First, you can simply resize the container until the data fits — this works when the data has a known maximum size. Second, you can use the Entire View option from the top menu of the sheet: the view then takes the entire space of its container automatically, whatever data or filters are active.
Worked example — Entire View. The live demo: a filter on shipment mode was added, and removing one or two modes made the bars grow broader — the chart stretched to fill the whole container because Entire View was selected. With the standard (fixed) view, the same change produced a vertical scroll bar and blank space. So Entire View makes the best use of scale — though again, whether it helps depends on your data. If you are not sure how much data will be shown under different selections, choose Entire View and the view takes care of itself.
11.4.4 Filters: Defaults, Scoping, and Cleanup
When you drag a view onto a dashboard, the filters (and legends) that exist in that sheet come along with it. You do not have to keep them: any legend that is only displaying values and not adding value can be crossed out and removed. Watch the clutter — be very careful about which menus and legends are important and keep only those.
You can also add your own filters. From the filter menu you can add a filter based on any field, for example shipment mode (first class, same day, second class, standard class). The important default: a filter you add applies only to the sheet it came from. If you want it to work across the dashboard, open that filter and choose the option to apply it to all worksheets using this data source — then the whole dashboard behaves synchronously as you change it. Filters are quite important for interactivity, but not every filter is useful, and you can remove any filter at any time and bring it back later.
Pitfall: the "it only affected one sheet" confusion. A filter you drop on a dashboard defaults to its own sheet — that is by design, not a bug. If a filter should drive the entire dashboard, set it to apply to all worksheets using the data source; otherwise different sheets silently answer different selections and the numbers stop agreeing with each other.
Titles set the context, filters drive the interactivity, and Entire View removes scroll-bar surprises. Runtime titles in particular keep the viewer anchored: the title always says exactly what selection the current numbers belong to.
11.5 Tiled vs Floating Layouts and Dashboard Objects
11.5.1 Tiled Layout
When you start a new dashboard, the default layout is tiled. In a tiled layout everything is placed into an automatic structure — a container view. When you bring something in, it snaps into the structure, and the gray area indicates exactly where it will land when you drop it. Tiles behave like containers: you can resize each container, and you decide how much space each one gets.
11.5.2 Floating Layout
The alternative is floating. With floating selected, an object stays as a floating sheet: it sits on top of your view and you can move it anywhere, resize it, minimize or maximize it — it does not fit into the layout structure at all. You can toggle between tiled and floating at any time, and even in a tiled dashboard you can convert an object into a floating one.
Floating has not seen too much use in practice, but it totally depends on your use case. If you want to give a user flexibility — a small information panel in a corner that they can enlarge on demand — floating is the way. Another natural use: a URL page that opens when the user clicks a country, which they can then drag wherever they want while reading.
11.5.3 Adding Images
Worked example — logo placement. You can add an image to a dashboard (insert image, then choose the file) — for example the company logo. One quirk: an image object has no left-alignment option, so by default it spreads across the whole container. The trick is to place a dummy object — for example a blank space tile or another container — next to the image. That dummy takes the remaining space, and the image gets squeezed compactly into the left. This is how you control where a logo sits without pixel wrestling.
11.5.4 Horizontal and Vertical Containers
To build even layouts, use containers. Place a vertical container, then place horizontal containers inside it, then put images, text boxes, and blank spaces inside each of those. For example: a header row with the logo on the left (dummy object next to it), company text beside it, and the company URL next to that. You decide whether a container is horizontal or vertical, and you can keep nesting and reshaping until the layout matches your plan. This is how you actually plan layouts — worksheets, text, images, and blank space arranged inside containers.
Pitfall: dropping images and text straight onto the canvas and calling it a layout. Without containers, moving one item forces every neighbor to be nudged by hand. Nesting containers — vertical at the top level, horizontals inside — is what lets the dashboard reflow itself when you resize a pane.
| Tiled | Floating | |
|---|---|---|
| Structure | Snaps into automatic containers | Free-floating, no structure |
| Resize | Via container panes | Move/resize/minimize anywhere |
| Overlap | Not possible | Possible — objects sit on top |
| Use case | Most dashboards, consistent grid | Corner info panels, draggable URL pages |
Tiled is the safe default: everything snaps and reflows predictably. Floating is the deliberate exception for user flexibility. And when an image misbehaves, remember the dummy-object trick — a blank tile next to the image pins it to the left without pixel wrestling.
11.6 Formatting Dashboards
11.6.1 Formatting Individual Sheets
By default, fonts and the overall look of a dashboard are quite mature — you usually will not need to overcomplicate things. But you should know how formatting works in principle. You can change the fonts of any individual sheet by right-clicking the sheet and choosing Format — for example set the font size to 8, and the sheet's text changes. You can change colors the same way, per sheet.
11.6.2 Formatting the Whole Dashboard
For dashboard-level changes, right-click the canvas and choose Format Dashboard. These are the dashboard settings: set the background color (for example a shade matching your company's theme), and the title, legend, and filters all pick it up. You can also set title fonts and alignment from here. The division of labor: individual controls are changed at sheet level, and overall theming is applied at dashboard level.
11.6.3 The Layout Tab and Item Hierarchy
There is a third level — the Layout tab. Here you see the complete item hierarchy of the dashboard: how the objects are nested, for example a vertical container holding the shipping dashboard, a vertical element inside that, then tiles within it. The hierarchy tells you exactly how the items were placed. You can select any item in this hierarchy and change its background shading — for example make one tile pink — so very specific color coding is possible per component, not just per sheet.
11.6.4 Borders and Padding
From the layout level you can also beautify individual components. Select a component (for example a legend), give it a border, give it a background shading, and control its outer and inner padding — the gap between the border and the content grows as the padding increases. These are pixel-level controls, useful when you want everything to match down to the pixel.
11.6.5 Caution About Over-Formatting
Worked example — formatting demo. The demo touched all three levels: a sheet's font was set to size 8 from the sheet-level Format menu; the whole dashboard received a themed background from Format Dashboard; and inside the Layout tab a single tile was given a pink background shading, then a component (a legend) was given a border with controlled outer and inner padding. Each level — sheet, dashboard, layout — controls a different slice of the look.
One warning to carry with you: too much coloring can also be a bit tricky. Be very careful — do you really want those borders? Do you really need all those changes? The options exist at worksheet level, dashboard level, and layout level (background color, borders, padding), and they are powerful — use them with restraint, and only where they add value.
Formatting lives at three levels: sheet (fonts, colors per view), dashboard (background theme, title fonts), and layout (per-component shading, borders, padding). Match the level to the change — and resist the urge to use every option.
11.7 Dashboard Actions
11.7.1 The Three Action Types
An action defines what happens when a user takes some action on a dashboard — you decide what should happen. There are three types of action primarily used:
- Filter — a user interaction filters the target views.
- Highlight — a user interaction highlights matching marks in the target views.
- Go to URL — a user interaction opens a web page.
Highlight and filter actions need a source sheet and a target sheet. The URL action can take a field value as dynamic input, building a runtime URL from what the user clicks.
11.7.2 Source and Target Sheets and Activation Behaviors
When you add an action you specify the source sheet (where the user acts), the target sheet (what reacts), and the activation behavior:
- Select — the action runs when the user clicks a mark.
- Hover — the action runs when the mouse passes over a mark.
- Menu — nothing happens on click or hover; instead a hyperlink appears in the tooltip, and the action runs only when the user clicks that link. Control stays with the user.
Each behavior has a downside to weigh. On select, every click refreshes the target views — that can be very disturbing when a user is trying to read the title ("boss, I want to read the title — why are you changing things?"). Hover runs as the mouse moves, which can be equally annoying while the user is scanning. The menu behavior avoids both: nothing changes until the user deliberately clicks the tooltip link, so the user decides whether the action happens.
Pitfall: pick the activation behavior for the reading situation, not for the demo. Select and hover constantly refresh target views and can disturb a user who is reading or scanning; menu leaves control with the user and is the polite choice for exploratory dashboards.
For example, when a user brings the mouse over one field on your dashboard, you can trigger an action based on that — change the background of another screen, filter it, or anything else you define.
11.7.3 Worked Example: Filter Action
Worked example — filter action. On a dashboard with three sheets — a map on top and two others below — add a filter action with the map as source and the two other sheets as targets, running on selection and applying to all fields. Now click the United States on the map: the values are highlighted and the sheets underneath change — the filter is applied to both target sheets exactly as defined. The same action could be set to hover instead of click, and it would run while the mouse is over a country.
11.7.4 Worked Example: Highlighting from the Legend
Highlighting can also be done without an action. The legend carries a pen icon: click the pen and then click an item in the legend, and only the data for that item is highlighted across the view. In the demo, clicking "critical" selected only critical values, clicking "high" selected only high and relative-high values, and clicking "low" selected only low values. Clicking the legend again removes the highlight. So the legend itself is a second, simpler way to add highlighting interactivity.
11.7.5 Worked Example: Go to URL with a Dynamic Field
Worked example — Go to URL. For the URL action, build a dashboard with a country sheet and a web page object pointed at Wikipedia, then add a Go to URL action on the dashboard. In the action setup, select the source sheet and set the URL to accept the country field as a runtime parameter — so the URL is built from whatever country the user clicks.
The first attempt looked broken: clicking Australia did nothing. The reason turned out to be the menu behavior — the action had been left on menu, so only a hyperlink in the tooltip would have triggered it. After editing the action and switching from menu to any-click, the action worked: clicking Australia passed the parameter and opened Australia's Wikipedia page; Russia opened Russia's; Canada opened Canada's; India opened India's. The parameter travels in real time — that is how dynamic URL actions behave once the behavior setting is right.
11.7.6 Live Web Pages as Dashboard Objects
The web page object is a real live page, not a static picture — the user can toggle and click inside it. You can place this next to your logo, or keep it as a floating object, so that whenever the user wants, they can open whatever link you have configured. Building dynamic page URLs into a dashboard is a legitimate way to add interactivity — the user clicks somewhere on the dashboard and gets complete detail from an external resource.
A summary of actions: three types (filter, highlight, URL); filter and highlight need a source and a target; the URL action can use a dynamic field; actions are activated by hovering, clicking, or menu. The menu behavior puts the control with the user — useful when you want to catch attention without forcing every click to reload the dashboard. These controls bring a lot of interactivity, but do not overdo it — decide carefully what you want, and use the documented steps to replicate these examples.
11.8 Device Designer
11.8.1 Device Preview and Preset Models
The dashboard has a device preview option. Tableau lets you decide which kind of device the dashboard is for: desktop, tablet, or phone. Within desktop there is a list of predefined options, and for tablets there are standard dimensions of the common models — iPad, the different iPads, Nexus, Samsung tablets, and so on — with phone models available too. Choosing one shows you exactly how your dashboard and its controls will look on that device.
11.8.2 Default Dashboard as the Template
The device designer works like this: the default dashboard is the starting point. It acts as a template for the other device layouts, so the other layouts do not have to start from scratch. When you select a device type (say tablet) and a model (say iPad mini) and add it to the layout, a device-specific layout is created, and the content you placed on the default dashboard carries forward into it. You then make modifications for that device — swap the layout, switch to portrait, rearrange controls — and those changes live only in the device-specific layout. If your organization uses iPads, for example, you build the dashboard once on the default, then make a tablet layout tuned for the iPad model your people actually use.
Pitfall: editing the default layout after building device layouts and expecting every device to follow. The default only seeds the device layouts at creation time — later edits to the default do not reflow the already-created device layouts, and edits inside a device layout stay local to that device.
Device designer = one default dashboard as the seed, plus per-device layouts that inherit once and then diverge. Pick the device and model first, preview it, then tune each layout for its real audience.
11.9 Dashboard Best Practices
11.9.1 Tableau's Own Best Practices
These best practices are published by Tableau itself, and they are worth following:
- Know your purpose and audience. The first question is always who the dashboard is for and what it must do.
- Make the most of the most-viewed spot. The top-left of a web page is where the eyes typically go first, so be very careful about what you place there — your title and your main views belong in that prime spot.
- Select your layout and display size carefully. Do not make too many views on a single dashboard; select them very carefully.
- Keep color themes, menus, and legends consistent. Your red cannot mean one thing here and another thing there. Consistent scaling and consistent colors across every sheet make the dashboard readable at a glance.
- Add interactivity to encourage exploration. This session showed the level of interactivity possible — filters, actions, highlights. Let the user explore rather than just view.
The eye-tracking logic behind practice 2: reading in western languages scans left to right, top to bottom, so the top-left corner is the anchor point where attention lands first. Putting the title and the headline view there means the most important message is the first thing seen — anything important placed in the bottom-right risks being noticed last, if at all.
11.9.2 A Reliable Build Order
If you need a reminder of the whole pipeline: build your individual sheets and charts first. Customize the charts for a consistent look and feel — if you are using red and blue, that same red and blue appears in every sheet. Place them on the dashboard using containers, carefully designing which view is the top-level one and which are the subsets. Then add interactivity. If you follow these steps, your dashboards will turn out very, very successful.
Build order: sheets first → consistent styling → container-based placement with a clear hierarchy → interactivity last. And keep practicing with your own version of a dashboard in the coming days and weeks — dashboarding comes with practice, and it is not rocket science. Your own coloring and your own formatting are the things you will only learn by doing.
11.10 Story Building
11.10.1 Story Points
A story is one level further than a dashboard. Story points are nothing but the interactive, data-driven steps of the story. Each story consists of individual sheets or dashboards — when you create a story, all your sheets and dashboards appear for selection. The sequence matters: a story is a narrated walkthrough of one or more sheets or dashboards, where each story point carries a piece of the narrative.
11.10.2 Creating and Sizing a Story
There are two ways to create a story: click the story icon, or use the top menu — Story → New Story. As with dashboards, make sure the size and layout are right first; the size setting at the bottom matters. Automatic is the safe choice for a story, because it takes the maximum size it needs on its own.
11.10.3 Building the Story: Sheets, Captions, and Sequence
Worked example — building a story walkthrough. With the story open, the already-created sheets and dashboards are visible on the left. Click and drag an individual sheet or dashboard into the story, and give it a meaningful caption. The examples used in the demo: "My consumption is the best", "Segment Overview", "Sales Overview". Each story point gets its own title and commentary.
Stories are even less complex than sheets. The sheets are the laborious part — that is where you build the building blocks. After that, it is purely placing and building your narrative, exactly like putting together a PowerPoint: add a third story point, decide whether it goes between two existing ones, on the left, or on the top, and rearrange as you talk. In the demo the sequence was changed on the fly — "let's not start with the segment, better start with the country": first story point countrywide sales, then the overview, then closing with the dashboard.
If you dragged the wrong sheet into a story point, you do not need to delete it: simply drag the correct sheet on top of it, and it replaces the wrong one. You can add a new story point by clicking the blank option, double-clicking, or dragging a sheet into the strip. You can always insert a new story point in between existing ones to adjust the flow.
11.10.4 Story Point Navigation Layouts
The story strip at the top can be presented in several layouts: the default captions (each story point shows its title), numbers instead of captions, dots, or arrows only. There is no right or wrong — you decide which layout fits the presentation.
11.10.5 Story Best Practices
The story best practices mirror the dashboard ones:
- Know your audience.
- Keep the narrative clear — know exactly what you are planning to present.
- Sketch the flow first. Before building, sketch the sequence: "I'll start with this, then show this here, then this." Build the story to match that sketch.
- Flow matters a lot.
- Make the visuals important and focused. Ideally you should not be speaking too much when presenting a dashboard; let users see the data. If you have to say more than what is on the dashboard, then probably the user will struggle. Show the data, use a voice-over if needed, and make the best use of the data you have.
- Context is very important — the story must place each view in context.
Pitfall: treating the story as a talk with slides as decoration. The visuals are the argument — if you have to say more than what is on the dashboard, the user will struggle to follow. The story exists so the data carries the message.
11.10.6 Seven Data Story Types
Tableau describes seven types of data stories, and it helps to recognize which type fits your situation:
- Change over time — something is changing over time (company sales, profit, anything) across the last ten years. Narrate what happened and why; use a chronology, and make sure the trend is visible (for example with a trend line chart).
- Drill down — set the context, then zoom into a particular category. If one segment is the least-selling segment, you zoom into that segment: we sell into these many countries within this segment; within those countries, this one is the least. This is root cause analysis.
- Zoom out — show the bigger picture. Start with something small and keep zooming out, higher and higher, until you land on "this is where we are today — overall company sales are this much."
- Contrast — compare two or more different subjects. One contains this, another contains that, and you compare one product against another.
- Intersection — stories about factors that combine.
- Outliers — show the unusual values that stand out.
- (The examples go on, but broadly these are the categories.)
In practice, most data stories are either change-over-time (a historical review) or drill-down (a root cause analysis). Recognize which one you are building and structure the story points accordingly — and remember the PowerPoint rhythm: point, rearrange, replace, narrate.
11.11 Funnel Chart Demo
11.11.1 Creating a Funnel Chart
A funnel chart shows how a measure narrows across categories — for example sales per customer segment. This demo fills a gap from an earlier session where the funnel chart could not be built because the wrong data was selected that day.
Worked example — funnel chart from sales per segment. The recipe:
- Bring Sales to the columns shelf — the chart now shows sales per segment (consumer, corporate, and home office).
- Color the marks by segment.
- Put Segment on Size as well — move segment to the size shelf.
- Select Entire View.
The chart takes the funnel shape automatically. Your data may be different, but the recipe is the same: decide the field you want to show, give the coloring, give the size, and the funnel appears.
11.11.2 Notes on Encodings
One detail from the demo: the earlier attempt had used percentages; this time real values were used, which is why the chart showed the shape it did. The funnel chart is just another chart type — same drag-and-drop approach as every other chart you have built across the previous sessions.
Pitfall: a funnel built on percentages can flatten or distort the narrowing shape, because each segment is being shown relative to its own total rather than as a portion of the whole. When the funnel does not look like a funnel, check the encoding — real values on the size shelf are usually the fix.
Funnel chart = measure on columns + color by category + category on size + Entire View. The encoding details matter: percentages hide the narrowing that real values reveal.
11.12 Calculated Fields in Tableau
11.12.1 Q&A: Power BI Measures and DAX vs Tableau Calculated Fields
Q: In Power BI we can create measures and DAX functions. Can we also create the same in Tableau?
A: Yes. Tableau achieves the same purpose through calculated fields. We can create our own calculations — for example sales multiplied by something, divided by something — create our own measures, and bring them into the dashboard. This was covered in an earlier session; review the class video, and let me know if you face any challenge with it.
The naming difference is worth pinning down: Power BI calls these measures built with DAX functions; Tableau calls the same idea calculated fields. Same purpose, different vocabulary — a terminology contrast that matters when you switch tools or read documentation for the other product.
11.12.2 Merging and Splitting Fields
Beyond plain calculations, calculated fields cover data-shaping too. You can merge two fields and make one field out of them. You can also split a field: for example, if you have a field with a value like "CA-hyphen-something", you can split it into separate parts — one part for "CG", one for "1-5", and so on. Combining fields, splitting fields, and building calculated measures are all possible in Tableau, which is the direct counterpart of Power BI's measures and DAX.
Pitfall: treating calculated fields as formulas-only. A calculated field is not just a number you compute — it is also the tool for data shaping. If a raw field is badly structured (a code like "CA-1-5" jumbling region and value), the split is a calculated-field operation, not a new data source.
Tableau's answer to Power BI measures and DAX is the calculated field: build your own measures, merge two fields into one, or split one field into parts. The capability is identical — only the name changes.
Exam Guidance Summary
Exam note: The next assignment is an experiential learning assignment, and it will most likely be on a Tableau dashboard or story building kind of thing. The quiz is done; this assignment will be published about a week after this session, and you will get a decent amount of time to complete it. Because the assignment is most likely a Tableau dashboard or story, today's material is important — expect to need it.
Exam note: If you have doubts, the next session will open with 10–15 minutes (the instructor is happy to give 15–20) of brushing up on dashboards and stories before the course moves to Python.
Exam note: Practice is the study advice that matters most here. Dashboarding comes with practice and is not rocket science — practice dashboards and stories after class with your own version of a dashboard in the coming days and weeks, and get your hands dirty with your own coloring and your own formatting.
Exam note: From the next session onward the course shifts to Python-based data visualization libraries — Matplotlib first, then Seaborn and Bokeh. Plan for the gear change.
Key Industry Applications
Real-world: Tableau dashboards are a standard BI deliverable in organizations — branded with the company logo, themed background colors, and consistent colors across every sheet, exactly as the formatting and best-practice sections described. Analysts and data teams ship these to executives, operations, and field staff as the everyday face of the data warehouse.
Real-world: The device designer supports real deployment scenarios: when an organization's workforce uses iPads or tablets in the field, the dashboard gets a device-specific layout tuned for that exact model. What looks right on a 24-inch monitor often breaks on a 7-inch tablet — the device designer exists to prevent that.
Real-world: Actions connect dashboards to the wider web — a logo click can open the company website, a country click can open a Wikipedia page, and dynamic URLs pass the selected context into any external system. A sales manager can click a region and land directly in the CRM record for that territory without leaving the dashboard.
Real-world: Teams migrating from Power BI (measures and DAX) to Tableau have a direct counterpart in calculated fields — the ability to create measures, merge two fields, and split fields. The terminology changes, the workflow does not.
Real-world: Data visualization is not limited to BI products like Tableau and Power BI. Python libraries — Matplotlib, Seaborn, and Bokeh — provide the same capability in code, which is where the course heads next. Teams that own their analytics in notebooks or web applications increasingly build visualizations in these libraries rather than in packaged BI tools.
DVI Lecture 11 notes · Dashboard and Story Building in Tableau
Sections Breakdown
Recaps the prior session's DIY analytics platforms, visual encoding, pre-attentive attributes, and Gestalt principles, then lays out today's dashboard/story agenda and the road ahead into Python libraries.
Worksheets hold single views, dashboards collect them on one canvas, and stories narrate a sequence of sheets and dashboards. Edits propagate from sheets and dashboards everywhere, but story edits stay local.
Dashboards are built from sheets and objects with three sizing modes (fixed, automatic, range); decide size and device upfront, then place views logically with the first sheet taking the full space.
Titles can be static or runtime field-driven, filters come with their sheet and default to sheet-scope unless set to all worksheets, and Entire View removes scroll bars by stretching the view.
Tiled layouts snap objects into automatic containers (the default); floating lets objects sit freely on top. Images, text, and URL objects are placed with the dummy-object trick and nested containers.
Formatting applies at three levels: sheet-level Format (fonts/colors per view), dashboard-level Format Dashboard (background theme, title fonts), and Layout tab item hierarchy (per-component shading, borders, padding).
Three action types (filter, highlight, go to URL) with source/target sheets and activation behaviors (select, hover, menu); demoed with a map filter action and a dynamic Wikipedia URL action.
Device preview shows desktop/tablet/phone layouts from preset models; the default dashboard acts as the template seed for device-specific layouts that then diverge.
Tableau's five published best practices: know purpose/audience, use the most-viewed top-left spot, select layout and size carefully, keep colors consistent, and add interactivity - plus a reliable build order.
Stories narrate a walkthrough of sheets and dashboards via story points with captions, sized automatically; seven data story types exist, with change-over-time and drill-down being the most common.
A funnel chart narrows a measure across categories; built by putting sales on columns, coloring by segment, putting segment on size, and selecting Entire View.
Tableau calculated fields are the direct counterpart of Power BI measures and DAX: custom calculations, merging two fields into one, and splitting a field into parts.
The next assignment is likely a Tableau dashboard or story; a brief dashboard/story brush-up opens the next session; practice is the key study advice; the course then shifts to Python libraries.
Dashboards are standard BI deliverables; the device designer serves field workforces; actions connect dashboards to external systems; calculated fields ease Power BI-to-Tableau migration; Python libraries extend visualization beyond BI tools.
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 and Course Roadmap
Must-know: Dashboards and stories are simpler than the sheets beneath them; the sheets are where the real work lives.
⚠️ Top pitfall: Listening without practicing; the judgment of which KPIs to pick cannot be taught, only developed.
Self-check: What comes next in the course after this Tableau wrap-up session?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2)
The Worksheet–Dashboard–Story Hierarchy
Must-know: Fixed hierarchy sheets → dashboards → stories; sheet and dashboard edits propagate everywhere, story edits do not reflect back.
⚠️ Top pitfall: Assuming story edits propagate back into sheets/dashboards; they do not — duplicate the sheet if independent behavior is wanted.
Self-check: You remove a country inside a story. What happens to the dashboard?
Connects to: Dashboard Sizing, Layout, and Placement (11.3), Story Building (11.10)
Dashboard Sizing, Layout, and Placement
Must-know: Three sizing options: fixed (preset/custom dimensions), automatic (fills available space), range (grows within pixel bounds). Decide size and device upfront with stakeholders.
⚠️ Top pitfall: Squeezing the anchor view into a corner; changing size/device mid-build forces redesign.
Self-check: Which sizing option makes the dashboard fill whatever browser window it is opened in?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Device Designer (11.8)
Titles, Filters, and Scroll Bars
Must-know: Runtime titles insert a field so the title reflects the current filter selection; Entire View makes the view fill its container and removes scroll bars.
⚠️ Top pitfall: Forgetting that dashboard filters default to sheet scope only; set them to apply to all worksheets for synchronous behavior.
Self-check: How does a title change when you insert the Country field and select a country?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Dashboard Actions (11.7)
Tiled vs Floating Layouts and Dashboard Objects
Must-know: Tiled is the default and snaps into containers; floating is free placement for user flexibility. Image objects have no left-align; use a dummy object next to them.
⚠️ Top pitfall: Placing objects without containers; then every move requires manual nudging of neighbors.
Self-check: How do you pin a company logo to the left of a container when the image object spreads across the whole container?
Connects to: Dashboard Sizing, Layout, and Placement (11.3), Formatting Dashboards (11.6)
Formatting Dashboards
Must-know: Sheet-level Format changes individual views; Format Dashboard themes the whole canvas; the Layout tab edits nested components and padding.
⚠️ Top pitfall: Over-formatting: too many borders, colors, and paddings make the dashboard harder to read, not better.
Self-check: Where do you go to change the background shading of a single tile inside a dashboard?
Connects to: Dashboard Sizing, Layout, and Placement (11.3), Tiled vs Floating Layouts and Dashboard Objects (11.5)
Dashboard Actions
Must-know: Filter and highlight actions need a source and target sheet; URL actions can take a field value as a runtime parameter; activation can be select, hover, or menu.
⚠️ Top pitfall: Leaving an action on menu and wondering why clicks do nothing — the menu behavior only fires from the tooltip hyperlink.
Self-check: Why did clicking Australia do nothing in the first URL action attempt?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Titles, Filters, and Scroll Bars (11.4)
Device Designer
Must-know: The default dashboard is the starting template; device-specific layouts inherit its content once and then take their own modifications.
⚠️ Top pitfall: Expecting later default-dashboard edits to propagate into already-created device layouts.
Self-check: Where does the content of a new tablet layout come from?
Connects to: Dashboard Sizing, Layout, and Placement (11.3), Tiled vs Floating Layouts and Dashboard Objects (11.5)
Dashboard Best Practices
Must-know: Top-left is the prime real estate; purpose and audience first; consistent colors and scaling; interactivity for exploration; build sheets → style → place → interact.
⚠️ Top pitfall: Putting the most important view in the bottom-right, where it is noticed last.
Self-check: Where on a web dashboard do eyes typically land first?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Story Building (11.10)
Story Building
Must-know: A story is a narrated walkthrough of sheets/dashboards; drag sheets in, give captions, rearrange points; automatic sizing is the safe choice.
⚠️ Top pitfall: Speaking more than the dashboard shows; if you must say more than what is on the dashboard, the user will struggle.
Self-check: How do you replace the wrong sheet inside a story point?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Dashboard Best Practices (11.9)
Funnel Chart Demo
Must-know: Funnel recipe: measure on columns, color by category, category on size, Entire View — the shape appears automatically.
⚠️ Top pitfall: Using percentages instead of real values flattens or distorts the funnel shape.
Self-check: What fixed the funnel chart that would not take shape in the earlier session?
Connects to: Titles, Filters, and Scroll Bars (11.4)
Calculated Fields in Tableau
Must-know: Power BI measures and DAX correspond to Tableau calculated fields; they cover calculations, merging fields, and splitting fields.
⚠️ Top pitfall: Thinking calculated fields only compute numbers — they also merge and split fields.
Self-check: What is the Tableau counterpart of a Power BI measure built with DAX?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2)
Exam Guidance Summary
Must-know: Assignment is most likely Tableau dashboard/story building; practice dashboards and stories; gear change to Python next session.
⚠️ Top pitfall: Assuming the quiz is the end of Tableau material — the experiential learning assignment comes after.
Self-check: What will the next assignment most likely be about?
Connects to: The Worksheet–Dashboard–Story Hierarchy (11.2), Story Building (11.10)
Key Industry Applications
Must-know: The dashboard skills map directly onto industry BI practice: branding, device-specific layouts, web-connected actions, and cross-tool calculated fields.
Self-check: Why would an organization tune a dashboard specifically for iPad?
Connects to: Formatting Dashboards (11.6), Device Designer (11.8), Dashboard Actions (11.7), Calculated Fields in Tableau (11.12)
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.