Recently Jeffrey Shaffer posted about an experience he had building a dashboard that was generated through AI prompting. Naturally, I thought that seemed like a fun challenge and something that would be worth experimenting.

I’ll be the first to admit that my end output wasn’t nearly as good of a final product, but I had some very interesting takeaways from this project. If you are in the data visualization or data storytelling space I would highly recommend you try this process at least once.

I relied exclusively on AI tools to develop ALL of the code that was used in my final output. Yes, that caused a headache at many points along the way, but this led to a lot of learning. Some of my key takeaways and insights are below:

1. Your AI tool may get stuck and cant find a solution. When this happens try a different tool.
2. The end-to-end development process is likely going to be far slower than building something directly in a tool like Power BI or Tableau.
3. The AI tools have a limited ability to identify and implement visualization best practices (without additional prompting).

Basically, at this point, you probably don’t need to worry about AI building best-in-class visualizations with minimal effort. As the data viz practitioner it will continue to be important to understand data viz best practices and design standards.

Tech and Data Overview

First of all, if you are trying to replicate something like I did it’s helpful to have the context of the tools I was using to build out my dashboard. When it comes to the data, I used an API feed of San Antonio road pavement quality. My initial goal was to use traffic data, but I had to pivot as the AI tools struggled to get those feeds set up properly.

I built the dashboard itself using the Databricks Free Edition and d3.js to build a locally hosted dashboard. The goal here was to use only free and readily available tools. The Databricks Free Edition is a great way to be able to play around with the Databricks UI while connecting to real data. I’ve also been hearing a lot about d3.js dashboards and wanted to experiment with them. Effectively, two birds one stone.

The AI tools that I used were Claude in a VERY limited capacity and Google’s Gemini. For Claude, I just used the free version with limited tokens. Gemini was the powerhouse behind getting the process built out and was limited to Gemini 3 Fast. I suspect I could have benefited from using a more advanced version of Gemini but again the goal was to keep this as available to a broad reaching audience as possible.

Setting up the API call

This part was executed within Databricks. The goal here is to set up the initial data feed from the San Antonio pavement data API endpoint. Here is the prompt I used to set up the API feed.

My goal is to create an end to end data visualization tool. This tool will visualize San Antonio pavement data patterns using geospatial maps and trend lines over time. The data must be sourced via API. The output visualization must be deployed via a D3 web dashboard.

Generate code that can be used within the Databricks Free Edition to collect the initial data via the API connection to the Texas department of transportation. Assume I have limited experience connecting to API endpoints.

After repeated prompting I kept getting errors with the API call. Many of these errors were due to ill formatted querying against the API feed. Ultimately, this is where I pivoted to Claude to get the starting code seed. Claude was able to build code that connected on the first try and then I refined that code in Gemini after I ran out of Claude tokens.

In the Databricks Free Edition there are limitations to the way that data feeds can be structured for downstream use. Ultimately, after A LOT of prompting and iteration I was able to generate the following code that sets up the initial API call that then saves a json data feed. Below is the code (you’ll notice the references to traffic data from my initial research that I pivoted away from):

import pandas as pd
import json
import base64
from pyspark.sql.functions import col, lit, when

# 1. Convert to Spark
df = spark.createDataFrame(traffic_data)

# 2. DATA REPAIR: Using Backticks to resolve the column name error
# Spark requires ` ` when a column name contains a dot .
target_col = "`attributes.PCI`"

if "attributes.PCI" in df.columns:
    # Cast to integer for D3 math
    df_clean = df.withColumn("pci_score", col(target_col).cast("int"))
else:
    # Fallback if the column is truly missing
    df_clean = df.withColumn("pci_score", lit(0))

# 3. Create 'Health' categories for high-contrast D3 colors
df_clean = df_clean.withColumn("health", 
    when(col("pci_score") >= 85, "Excellent")
    .when(col("pci_score") >= 70, "Good")
    .when(col("pci_score") >= 50, "Fair")
    .when(col("pci_score") > 0, "Poor")
    .otherwise("Unknown")
)

# 4. Final Prep (Ensuring we keep geometry for the map!)
final_pd = df_clean.toPandas()

# 5. GENERATE DOWNLOAD BUTTON
json_string = final_pd.to_json(orient='records')
b64 = base64.b64encode(json_string.encode()).decode()
payload = f"data:application/json;base64,{b64}"

html_button = f'''
<div style="background-color: #121212; padding: 20px; border: 1px solid #00ff41; border-radius: 8px; text-align: center; font-family: sans-serif;">
    <h3 style="color: #00ff41; margin-top: 0;">Step 1: PCI Data Extracted</h3>
    <p style="color: #e0e0e0;">Resolved Column Conflict using Backticks.</p>
    <a href="{payload}" download="pavement_data.json" 
       style="background-color: #00ff41; color: #000; padding: 12px 25px; 
              text-decoration: none; border-radius: 4px; font-weight: bold; 
              display: inline-block; margin-top: 10px;">
       DOWNLOAD REPAIRED JSON
    </a>
</div>
'''
displayHTML(html_button)

Building the Dashboard

Now comes the really fun part. Unfortunately, I was out of Claude tokens at this point because I used them all to get the API feed stood up… Setting up the d3.js dashboard was a bit tricky because of the structure that is needed to general set up that is needed across multiple files.

To set up a d3.js dashboard you need to have a dedicated folder that houses 4 different files. These files tell your web app what data to reference, how to render the images, how to structure the overall dashboard, and an index file. Coordinating the code across each of these files will lead to the final dashboard output. However, as with all code, the different files could also be the source of a lot of code discrepancies.

Below is the code I used to generate my final dashboard:

index.html

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>San Antonio | Pavement Infrastructure Analysis</title>
    
    <script src="https://d3js.org/d3.v7.min.js"></script>
    
    <link href="https://fonts.googleapis.com/css2?family=Inter:wght@300;400;600&family=JetBrains+Mono&display=swap" rel="stylesheet">
    
    <link rel="stylesheet" href="style.css">
</head>
<body>

    <header class="app-header">
        <div class="header-content">
            <h1>San Antonio | <span>Pavement Infrastructure Analysis</span></h1>
            <div class="status-badge">
                <span class="indicator"></span> Real-time Condition Monitor
            </div>
        </div>
    </header>

    <main class="dashboard-container">
        
        <aside class="sidebar">
            <section class="control-group">
                <h2>Controls</h2>
                <p class="instruction">Click legend items to toggle visibility</p>
                
                <div id="map-legend" class="legend-container">
                    </div>
            </section>

            <section class="kpi-group">
                <div class="kpi-card">
                    <label>Visible Segments</label>
                    <div id="kpi-miles" class="kpi-value">0</div>
                </div>
                <div class="kpi-card">
                    <label>Predominant Health</label>
                    <div id="kpi-type" class="kpi-value excellent">--</div>
                </div>
            </section>
        </aside>

        <div class="viz-content">
            
            <div class="viz-card map-card">
                <div class="card-header">
                    <h3>Spatial Distribution: Road Health</h3>
                </div>
                <div id="map-viz" class="svg-container">
                    <div class="loader">Loading Geospatial Data...</div>
                </div>
            </div>

            <div class="viz-card trend-card">
                <div class="card-header">
                    <h3>PCI Score Distribution (Pavement Condition Index)</h3>
                </div>
                <div id="trend-viz" class="svg-container">
                    </div>
            </div>

        </div>
    </main>

    <script src="dashboard.js"></script>
</body>
</html>

style.css

/* --- 1. GLOBAL RESET & FONTS --- */
:root {
    --bg-dark: #0f0f0f;
    --card-bg: #1a1a1a;
    --border-color: #333;
    --text-main: #e0e0e0;
    --text-dim: #888;
    
    /* Condition Colors matched to D3 */
    --excellent: #00ff41;
    --good: #00e5ff;
    --fair: #ffff00;
    --poor: #ff4500;
    --unknown: #444444;
}

body {
    background-color: var(--bg-dark);
    color: var(--text-main);
    font-family: 'Inter', -apple-system, BlinkMacSystemFont, sans-serif;
    margin: 0;
    display: flex;
    flex-direction: column;
    height: 100vh;
    overflow: hidden;
}

/* --- 2. HEADER --- */
.app-header {
    height: 60px;
    padding: 0 24px;
    display: flex;
    align-items: center;
    background: #000;
    border-bottom: 1px solid var(--border-color);
}

.app-header h1 {
    font-size: 1.2rem;
    font-weight: 600;
    letter-spacing: -0.5px;
}

.app-header span {
    color: var(--text-dim);
    font-weight: 300;
}

/* --- 3. LAYOUT ENGINE --- */
.dashboard-container {
    display: grid;
    grid-template-columns: 320px 1fr; /* Fixed Sidebar, Fluid Viz */
    gap: 20px;
    padding: 20px;
    flex-grow: 1;
    box-sizing: border-box;
}

/* Sidebar Styling */
.sidebar {
    display: flex;
    flex-direction: column;
    gap: 20px;
}

.control-group, .kpi-group {
    background: var(--card-bg);
    border: 1px solid var(--border-color);
    border-radius: 12px;
    padding: 20px;
}

/* Viz Content Stacking (Map on top of Trend) */
.viz-content {
    display: flex;
    flex-direction: column;
    gap: 20px;
    min-width: 0; /* Prevents D3 from overflowing container */
}

/* --- 4. CARDS & VISUALS --- */
.viz-card {
    flex: 1;
    background: var(--card-bg);
    border: 1px solid var(--border-color);
    border-radius: 12px;
    padding: 20px;
    display: flex;
    flex-direction: column;
    position: relative;
}

.card-header h3 {
    margin: 0 0 15px 0;
    font-size: 0.9rem;
    text-transform: uppercase;
    letter-spacing: 1px;
    color: var(--text-dim);
}

.svg-container {
    flex-grow: 1;
    width: 100%;
    min-height: 0;
}

/* --- 5. LEGEND & CONTROLS --- */
.legend-container {
    margin-top: 15px;
}

.legend-item {
    display: flex;
    align-items: center;
    padding: 6px 8px;
    border-radius: 6px;
    transition: background 0.2s;
}

.legend-item:hover {
    background: rgba(255, 255, 255, 0.05);
}

.instruction {
    font-size: 0.8rem;
    color: var(--text-dim);
    margin-bottom: 10px;
}

/* --- 6. KPI STYLING --- */
.kpi-card {
    margin-bottom: 15px;
}

.kpi-card:last-child { margin-bottom: 0; }

.kpi-card label {
    display: block;
    font-size: 0.75rem;
    color: var(--text-dim);
    text-transform: uppercase;
    margin-bottom: 5px;
}

.kpi-value {
    font-family: 'JetBrains Mono', monospace;
    font-size: 1.8rem;
    font-weight: 600;
}

/* Dynamic KPI Colors */
.kpi-value.excellent { color: var(--excellent); text-shadow: 0 0 15px rgba(0,255,65,0.2); }
.kpi-value.good { color: var(--good); }
.kpi-value.fair { color: var(--fair); }
.kpi-value.poor { color: var(--poor); }
.kpi-value.unknown { color: var(--unknown); }

/* --- 7. D3 SPECIFIC OVERRIDES --- */
path.road-path {
    transition: stroke-width 0.2s;
}

path.road-path:hover {
    stroke-width: 4px !important;
    cursor: crosshair;
}

.domain, .tick line {
    stroke: #444; /* Axis colors */
}

.tick text {
    fill: #888;
    font-size: 10px;
}

dashboard.js

// 1. GLOBAL STATE
let globalData = [];
let filteredData = [];
const colorScheme = {
    "Excellent": "#00ff41", 
    "Good": "#00e5ff",      
    "Fair": "#ffff00",      
    "Poor": "#ff4500",      
    "Unknown": "#444444"
};

// Initialize with ALL filters active
let activeFilters = new Set(["Excellent", "Good", "Fair", "Poor", "Unknown"]);

// 2. DATA LOADING ENGINE
d3.json('pavement_data.json').then(data => {
    // This will bring back your sample observation for debugging
    console.log("Sample Observation:", data[0]);

    globalData = data.map(d => {
        // Convert Unix Timestamp (ms) to Year for the trend chart
        const rawDate = d['attributes.InstallDate'];
        const yearInt = rawDate ? new Date(rawDate).getFullYear() : 0;

        return {
            ...d,
            health: d.health || "Unknown",
            pci: d.pci_score || 0,
            year: yearInt,
            geometry: { 
                type: "LineString", 
                coordinates: d['geometry.paths'] ? d['geometry.paths'][0] : [] 
            }
        };
    }).filter(d => d.geometry.coordinates.length > 0); // Remove empty geometries

    filteredData = [...globalData];
    initDashboard();
}).catch(err => console.error("Loading Error:", err));

// 3. INITIALIZATION
function initDashboard() {
    renderLegend();
    updateKPIs();
    
    // Give CSS 100ms to calculate the grid before drawing SVGs
    setTimeout(() => {
        renderMap();
        renderTrend();
    }, 100);
}

// 4. MAP RENDER (Using Auto-Fit)
function renderMap() {
    const container = d3.select("#map-viz");
    const width = container.node().clientWidth;
    const height = container.node().clientHeight;
    
    const svg = container.html("").append("svg")
        .attr("width", width)
        .attr("height", height);
    
    const g = svg.append("g");

    // 1. Create a FeatureCollection for D3 to measure
    const geojson = {
        type: "FeatureCollection",
        features: filteredData.map(d => ({
            type: "Feature",
            geometry: d.geometry
        }))
    };

    // 2. AUTO-SCALE: This forces the data to fill the box
    const projection = d3.geoMercator()
        .fitSize([width, height], geojson); // <--- THIS IS THE MAGIC LINE

    const pathGen = d3.geoPath().projection(projection);

    g.selectAll("path")
        .data(filteredData)
        .enter().append("path")
        .attr("d", d => pathGen(d.geometry))
        .attr("stroke", d => colorScheme[d.health] || "#888")
        .attr("stroke-width", 1.5)
        .attr("fill", "none")
        .style("opacity", 0.8);

    // Add Zoom
    svg.call(d3.zoom().on("zoom", (event) => g.attr("transform", event.transform)));
}

// 5. LEGEND & FILTERING
function renderLegend() {
    const legend = d3.select("#map-legend").html("");
    
    Object.keys(colorScheme).forEach(category => {
        const item = legend.append("div")
            .attr("class", "legend-item")
            .style("display", "flex")
            .style("align-items", "center")
            .style("margin-bottom", "8px")
            .style("cursor", "pointer")
            .style("opacity", activeFilters.has(category) ? 1 : 0.3)
            .on("click", function() {
                if (activeFilters.has(category)) activeFilters.delete(category);
                else activeFilters.add(category);
                
                filteredData = globalData.filter(d => activeFilters.has(d.health));
                d3.select(this).style("opacity", activeFilters.has(category) ? 1 : 0.3);
                
                renderMap();
                renderTrend();
                updateKPIs();
            });

        item.append("span")
            .style("width", "12px").style("height", "12px")
            .style("background-color", colorScheme[category])
            .style("margin-right", "10px").style("border-radius", "2px");

        item.append("label").text(category).style("cursor", "pointer").style("color", "#eee");
    });
}

// 6. TREND CHART (PCI Distribution)
function renderTrend() {
    const container = d3.select("#trend-viz");
    const width = container.node().clientWidth - 80;
    const height = Math.max(container.node().clientHeight - 80, 150);

    const svg = container.html("").append("svg")
        .attr("width", "100%")
        .attr("height", "100%")
        .append("g")
        .attr("transform", `translate(50, 20)`);

    // 1. Define X Scale
    const x = d3.scaleLinear().domain([0, 100]).range([0, width]);

    // 2. Generate Bins
    const histogram = d3.bin()
        .value(d => d.pci)
        .domain(x.domain())
        .thresholds(10);

    const bins = histogram(filteredData);

    // 3. Define Y Scale 
    const y = d3.scaleLinear()
        .domain([0, d3.max(bins, d => d.length) || 10])
        .range([height, 0]);

    // 4. Draw Grouped/Stacked Bars
    bins.forEach(bin => {
        // Group the data inside this specific bin by health status
        const counts = d3.rollup(bin, v => v.length, d => d.health);
        let yOffset = 0;

        // Draw a sub-rect for every health type present in this PCI range
        Array.from(counts).forEach(([health, count]) => {
            const barHeight = height - y(count);
            
            svg.append("rect")
                .attr("x", x(bin.x0) + 1)
                .attr("width", Math.max(0, x(bin.x1) - x(bin.x0) - 1))
                .attr("y", y(count) - yOffset) 
                .attr("height", barHeight)
                .attr("fill", colorScheme[health] || "#888") // <--- Syncs with Map!
                .attr("opacity", 0.8)
                .append("title") // Tooltip for clarity
                .text(`${health}: ${count} segments`);

            yOffset += barHeight; // Stack them if multiple types fall in one bin
        });
    });

    // Axes
    svg.append("g").attr("transform", `translate(0,${height})`).call(d3.axisBottom(x));
    svg.append("g").call(d3.axisLeft(y).ticks(5));
}

// 7. KPIs
function updateKPIs() {
    const total = filteredData.length;
    
    // Group and find the most common health status
    const counts = d3.rollup(filteredData, v => v.length, d => d.health);
    const topEntry = d3.greatest(counts, d => d[1]);
    
    // Safety check: if no data, default to N/A / unknown
    const topHealth = topEntry ? topEntry[0] : 'Unknown';
    const healthClass = topHealth.toLowerCase();

    // Update the HTML
    d3.select('#kpi-miles').text(total.toLocaleString());
    
    d3.select('#kpi-type')
        .text(topHealth)
        // This removes old classes and adds the new one for the color sync
        .attr("class", `kpi-value ${healthClass}`);
}

After the code was created and synced across each of the files I went it a local command line editor on my laptop to set up a locally hosted version of the dashboard. In that editor I navigated to the folder containing these 4 files and typed in the following code (python -m http.server 8000) to set up a locally hosted web app. Then I opened a new browser and entered localhost:8000 to load the dashboard.

Conclusion

At the end of the project I ended up getting the following dashboard.

Keep in mind all of this was built from AI directly. If I were to build this on my own for a real work project this is far from the desired final output. However, this approach does show a ton of promise and is something I’ll be exploring further. I relied entirely on Gemini to be able to derive the design and all relevant KPIs as well.

At this point, the development process here was significantly slower and much less iterative than what I’m used to being able to do in Tableau. If I need to get something fast out to stakeholders this isn’t the approach I would use, but building a generalizable framework on top of this is very appealing as well.

If you’re even remotely curious about doing something like this let me know. I’m curious to see how other people approach a similar problem and to see your successes.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

If this post was helpful leave me a comment here or connect with me on LinkedIn.

Note that this post was not written by AI (except for the code… obviously).

Vibe Code a Dashboard from Scratch was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Tableau Conference has been one I have attended multiple times. Obviously, this is a vendor sponsored conference and vendor sponsored conferences are going to be far from unbiased reflections of reality. However, exposure in this conference has opened many doors I wouldn’t have expected.

In this post I’ll cover my conference experiences within the context of the Tableau Conference while outlining ways to get the most your experiences regardless of which conferences you attend. There is basically a little bit for everyone in this post.

My Tableau conference experiences

I attended my first Tableau Conference in 2019. I’ve always been excited about the prospects of what Tableau could offer as a tool, but had never really had any formal training. My experience was all learned by doing and was very limited at best. I had attended a couple user group meetings in Cincinnati but again I was far from a regular. In my first Tableau Conference I sat in as many training sessions as I could. If something was remotely interesting and I had nothing better planned I was there. This was a great opportunity to learn a little bit about a lot of topics.

My first conference, most importantly, was where I learned about community projects. Makeover Monday was then, and still is now, one of the largest community projects for data visualization anywhere. After attending the conference I started participating in Makeover Monday, but not sharing my work publicly.

That first year taught me about what data visualization was and helped me get introduced to tools and resources available to the community.

My second (and all COVID) conferences

These conferences I still heavily indexed my time on participating in as many sessions as I possibly could. As I grew in my career, though, I started to find that the technical sessions just weren’t enough for what I needed. The technical sessions were still fun and a great learning opportunity, but I found that industry sessions or stories from representatives at other companies about how they used Tableau became much more powerful. In these sessions I learned how to build best-in-class templates or visualization guides.

These were incredibly helpful as a point of reference but ultimately were still pretty limited in scope. That being said I still reference relevant presentations today and frequently apply key learnings to my workflows and to strategic recommendations for my leadership.

Tableau Conference 2025

This conference was a complete pivot from my first experiences at Tableau Conferences past. In late 2024, I started getting much more involved in the broader Tableau community. I started leading the Retail and Consumer Goods Tableau User Group and was given a chance to speak about our design process for analytics within HEB Retail Media.

In all honesty I wasn’t Sure how beneficial it would be to attend this particular conference given that my work had shifted towards more data science heavy workflows and because I was already “good enough” with Tableau to more than meet the expectations of my current role (I lead a team of analysts and data scientists and rarely have bandwidth to build any practical reporting for the organization anymore).

However, because I was speaking and leading a user group I ended up having a ton of opportunities to connect with people both one-on-one and in broader group settings. I ended up helping run meetups for retail professionals and presenting. Not only that, but I had countless opportunities to meet other industry professionals with a strong data background.

The best part was that since I had started to engage with the broader Tableau user community I had started to build genuine friendships with other professionals with similar interests. This is probably the biggest benefit for attending a conference is that, if done right, you can start to build meaningful relationships.

How can you get the most out of conferences?

The best way to approach conferences is to be social. As most analysts are introverted this can be a big ask, but it’s totally worth it.

Before the conference, research who is presenting. Connect with them on socials and let them know you’re excited for their presentation. Start connecting early and importantly be genuine. You shouldn’t be expecting anything from these individuals, but this is a great way to start building those connections.

Next, when you are at the conference attend the sessions and go up to the presenters afterwards (if it’s appropriate for the conference). Ask meaningful questions about their presentations and introduce yourself.

Then, shortly after the conference ends, send the people you meet from presentations and throughout your daily interactions a note on a social network like LinkedIn. Again, your intent isn’t to look for a new job or to get anything from these people. You’re just trying to build a genuine connection.

The other recommendation I have is to go where the people are and talk with people in common gathering areas. At Tableau Conference there is a data village where vendors present the capabilities of their tools. However, there is also inspirational meetups like an area with data visualization submissions where you can get inspired about Tableau Public or broader meetup breakout areas. Go to these places and spend time there. You will meet some great people. At Tableau Conference this also happens to be where a lot of community thought leaders tend to congregate so don’t underestimate the value of spending time there.

Summary

Conferences aren’t the only way to get connected with like minded peers. However, they can be an excellent way to build meaningful connections, get inspired, solve problems you didn’t know you had, and genuinely have fun at the same time. My biggest piece of advice for anyone attending any conference is to not be afraid to get social.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — —

If you found this helpful let me know. Add a comment telling me what resonated. If you got other advice for conferences share that in the comments too.

Feel free to connect with me on LinkedIn or follow my work on Tableau Public as well.

Dashboards are a horrible place to tell a story.

- Steve Wexler

Think about that for a second… You don’t expect to look at your watch or speedometer and expect to get a rich body of insights do you? A dashboard in it’s simplest form is intended to communicate data quickly. Dashboards can do the following:

• Communicate changing performance metrics
• Create frameworks for communicating complex data

Dashboards are intended to quickly and easily share information. Dashboards don’t have to just communicate descriptive data performance either. They can communicate predictive data or modeled data as well.

However, they don’t tell a story. You shouldn’t assume they would.

The next logical question is how do we then blend a dashboard with a story? Enter the analyst, data scientist, data engineer, or other data professional. This post will help guide you through some tactical best practices you can implement to better tell data stories.

Why the design matters?

As data practitioners engage more technical efforts (think advanced data science), it can become easy to discount the importance of dashboard design. That disregard ultimately comes at the expense of your ability to communicate and influence others with your work.

Whether you’re attempting to communicate why a sales trend is going up or down or you are trying to show why a neural network is the correct approach for the problem at hand you are trying to do the same thing. You are taking data and trying to convince someone else that your approach is valid.

Too many times I have seen the hard work of others (and myself) get set aside because the analysis, model, dashboard, etc. was too hard to understand. This is ultimately why data practitioners need to have an eye towards design. Design and a solution centered approach is key for helping you drive adoption of your proposed idea or solution.

What resources are available?

In the context of this article I’ll focus on using Tableau Public as a resource to help you understand design best practices. It is worth noting though that Tableau Public is not the only place to go to find data design best practices (or that it is even the best). This is just where I go to get inspired and to get examples I can reverse engineer. I recommend you find the place(s) that work best for you and your needs.

On Tableau Public you can think of the visualizations there in two different contexts:

• Business friendly dashboards
• Recreational dashboards

Business friendly dashboards are just what they sound like. They are dashboards or parts of dashboards on Tableau Public that could easily be repurposed for business reporting.

Recreational dashboards are typically created by community members to experiment with Tableau. These dashboards frequently include elements that you should NOT share in corporate dashboards. You can tell which dashboards are recreational by the subject matter, use of visualization best practices, etc. Often these dashboards are very “artistic” in nature. Generally, you will not want to recreate these dashboards for storytelling in a corporate setting. It is worth noting though that some components of these dashboards are totally fine in the context of business reporting but exercise caution before you pull them into a business dashboard.

What does good look like?

One recommendation I have to anyone that is looking to get better at data storytelling and analytics in general is to read “Storytelling with Data” by Cole Nussbaumer Knaflic. This book is an excellent primer on data storytelling and how to use charts to communicate your research and perspective.

The other callout I have after participating and hosting Makeover Monday is that there is no single “best” dashboard that should be created with your data. Don’t expect to build the perfect dashboard, report, or data story. What is more important though is understanding what you are trying to communicate and then crafting your visualizations to support that story (after doing your research… obviously). The following questions are typically where I start building my data story:

1. What key insights or takeaways did my research uncover? (at most 2–3… or they probably aren’t main takeaways)
2. Are your insights or takeaways new or impactful?
3. Is there a logical order to your insights or takeaways?
4. Do your insights or takeaways roll up to some other initiative or project that wasn’t previously known?

As you build your data story you need to keep in mind that your research is not the same work that you should share. As the data practitioner your job is to pull apart and stress test the data as part of your research process. Often data practitioners do excellent research and then just share everything they’ve pulled together with little thought to how their work is presented. This is one of the fastest ways to ruin credibility as your stakeholders will get bored and/or won’t understand the nuance. Effectively at this point it is very easy to get lost in the details.

Building an effective data story

A data story can take many shapes. You shouldn’t be afraid to call a data story a simple email with 1 or 2 data backed insights. Sometimes thats all you need. The main takeaway is meet your audience where they are.

Identify the key takeaways

Assuming you need to build something more robust than an email, I’ll ground my story in the key takeaways (no more than 3). These should be simple bullets communicating data backed insights. Try to keep the text to a minimum as the goal is for your insights to be simple and impactful to strategy. I also recommend using text formatting to double emphasize your takeaways. This has the benefit of focusing the reader on the absolute minimum they need to understand while also giving you a visual cue when presenting. Below are some examples of how to execute this approach:

• Chuck was a popular tv show with a strong fan following that struggled to receive network investment but was ultimately saved for 3 extra seasons due to direct investment by Subway is an example of advertising opportunities (bad)
• The popular tv show Chuck survived due to direct brand advertising by Subway(better)
• Direct advertising investment in tv shows builds brand loyalty and by reaching customers where they are (even better)
• Direct advertising investment in tv shows builds brand loyalty and by reaching customers where they are (best)

As you compile your key takeaways you will want to consider the flow of how you communicate them. You will generally want to start with the “what happened?” then “so what?” or “why should I care?” and then finally to “now what?” or “what should I do after knowing this?”.

Sculpt your presentation

After you’ve shared your key takeaways and have your flow built out, now you can start crafting your presentation. Regardless of whether you use PowerPoint or Tableau to craft your story you should only use charts that directly support your key takeaways. By support I specifically mean charts that communicate the findings clearly and concisely to your stakeholders.

In a PowerPoint presentation I recommend using the slide title to communicate points directly related to the key takeaways. Then the chart that you share links directly to the title of the slide and any supporting text you include helps explain the chart and/or provides additional context. The richer your research the more you can expound the additional context you provide.

I often do something similar in dashboards that I compile. I’ll frequently add questions or callouts in the different sections of a long form (one time use) dashboard. This tells my audience how to interpret the dashboard and what to take from the chart.

Build your tool kit

When building your charts I recommend going out to a resource like Tableau Public to see how other people are communicating similar points to what you are trying to do. This is also where having a standard toolkit of charts really comes in handy. Participating in community projects like MakeoverMonday, Back2Viz Basics, GamesNightViz, WorkoutWednesday, and others is important because they expose you to unfamiliar data models and chart types and require you to think about presenting data differently.

An example where I’ve found having a toolkit of chart types handy is when trying to communicate distributions. While box and whisker plots are great for technical teams and academia (only those that use them frequently) it can be hard to communicate what they represent to non-technical stakeholders. This is where something like a jitter plot (tape plot, etc.) or a violin plot really comes in handy as they can communicate distributions in a cleaner way even if you lose some precision. Remember the main goal is to communicate your insights. If you are worried about precision remember you can always include the box and whisker in the appendix.

Communicate only what you want to communicate

Now that you have the structure in place for your presentation you need to consider how you will drive focus to those places where you want the audience to focus. This is where text formatting, color, size, and chart choice become important.

Take the electricity viz below as an example. Text formatting was used to specifically highlight key takeaways and drive home the emotional impact of electricity access.

Yellow was used because it is a color frequently associated with electricity. Note that only 2 colors were used in the dashboard. Grey was meant to give context but since it isn’t tied to the key takeaways I needed to de-emphasize that data so you can focus on the emerging economies (which is where electricity access is most problematic). The strategic use of color here helps to focus the message clearly and quickly. If I had a different color for each country then it would be almost impossible to quickly figure out what is going on (I know… that’s the default and it took forever to parse it out). Also, note that color is used consistently throughout the presentation. What I label with yellow ALWAYS refers to the same thing in this dashboard.

One callout when it comes to communicating what you want to communicate is that chart type will matter. Bar charts are typically the de facto chart used in a corporate setting. However, don’t be afraid to deviate from the default. Sometimes a more complicated chart type with clean labels, colors, etc. will communicate your story more effectively.

Summary

As you begin your data storytelling journey remember that as a data practitioner your job is to deliver clean, concise, memorable data stories that help drive decisions. Your goal is to drive speed to insight while reducing the analytical burden on your audience. Focus on the fundamentals and building your toolkit and you will be surprised at the value you can start to deliver

Main takeaways

• Meet the audience where they are
• Focus on the key takeaways
• Charts should only be used if they support the key takeaways
• Charts should use visualization best practices (size, color, font, etc.)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Want to learn more?

• Connect with me on LinkedIn (link)
• Follow me on Tableau Public (link)

Telling a BETTER data story was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

The good news is that there are things you can do to close those skills gaps. These activities aren’t free. They require effort, but they can be fun too. Ultimately, everything comes down to practice (and a little bit of play).

That’s the beauty of the Makeover Monday data project. It was originally designed as a way to help connect the community of Tableau users, share best practices, and think and explore data concepts. In this post I’ll outline what the Makeover Monday data project is and how you can get involved.

What is Makeover Monday?

Makeover Monday is simply a weekly data challenge. Every Monday a data set is published for use within the community. These datasets cover a wide range of topics from social initiatives to fun data sets in the news cycle. Along with these datasets is an image of a chart that is sourced from the data.

Your mission (should you choose to accept it) is to take that data set and using whatever software you prefer (e.g. Tableau, PowerBI, Excel, pen and paper… you get the idea) do one of the following:

1. Recreate the original image
2. Improve upon the original image

Once you’ve done worked through either of these approaches the only ask is that you share your work. You can share that with other people you work with or on LinkedIn tagging the Makeover Monday leaders or any other way you prefer. If you work through Makeover Monday with Tableau we strongly recommend uploading your work to Tableau Public and filling out the Makeover Monday tracker here to track your progress in this viz.

Avoid perfection (it doesn’t exist anyways)

When starting your work don’t worry about being perfect. Your work won’t be perfect but that’s kinda the point. Makeover Monday can be viewed as a sandbox project where you’re able to try out new capabilities.

In the context of Tableau, if you haven’t used dynamic zone visibility or spatial parameters or any variety of other newer capabilities use Makeover Monday to practice and learn what works or doesn’t.

You should view Makeover Monday as a low stress option to up skill and get inspired by others in the community.

Why the random data sets?

This is the hidden value behind Makeover Monday. Imagine you’re an analyst focusing on profit and loss statements. You probably have a couple of go to methods for displaying your reports. If you were to practice building analytics skills just on data you’re familiar with you’d hit a growth ceiling quickly.

Makeover Monday introduces you to large-ish and small data sets. You’ll also be introduced to mapping data and simple tabular data. You’ll be exposed to topics you’ve never considered. This exposure forces you to think about the data and the best way to visualize the same data.

A lot of analysts I’ve worked with didn’t want to work with data that wasn’t directly applicable to their everyday work. However, to be a well rounded and versatile analyst you need the broad data exposure.

Why share your work?

Think of sharing as your personal commitment device. Since this project is live every week there is always something new to learn. You will pick up simple tips and tricks over time just by participating.

Sharing is also a way to pay it forward to others. I’ve been participating in Makeover Monday now for the past 5+ years and sometimes I get stuck. When that happens I find going to other people’s work can be a great source of inspiration that I can try to replicate.

The other benefit of sharing (especially to somewhere like Tableau Public) is that this will give you a large portfolio of data visualization assets you can refer back to. I can’t tell you how many times I go back to a dashboard I previously posted on Tableau Public because I forgot how to do something but I can reverse engineer my old work.

I’m convinced, but don’t have enough time

I mentioned earlier that any community project is going to require an investment. You won’t get better unless you invest the time up front. This has a hidden benefit of helping you work faster in the long run too.

My recommendation is to start small. Set a time limit for what you are willing to do each week. If you can set aside 30 minutes each week you’d be shocked at what you learn over months of consistent and targeted practice.

Remember, you’re just trying to get better than you were last week. Get inspired by the work the community is doing. Learn from the community. Share with the community. You’ll be shocked at what you learn with a little bit of dedicated effort. Most importantly though….

HAVE FUN!

— — — — — — — — — — — — — —

Still have questions?

• Join the Tableau community Makeover Monday channel (via Slack).
• Reach out to your Makeover Monday leaders (Chimdi Nwosu, Harry Beardon, Ojoswi Basu, Blake Feiza, and myself) and other active participants for help.

Will Sutton, an Iron Viz winner a couple years back, built a dashboard analyzing the different food sources in the game. You can find his dashboard here. The concept behind this dashboard is a lot of fun. What I found most interesting was that he added a single subtle feature to his dashboard that, in my opinion, was pretty powerful. He added a button to the dashboard that would swap out the background colors. None of the data changed, but this ability to simply swap out the backgrounds of a dashboard is something I have thought about A LOT ever since seeing this viz.

I finally had a use case to test out this trick on my own when building a viz on tips and tricks for the Portland Tableau User Group. I thought it would be fun to showcase the differences between data from the University of Oregon and Oregon State University. While I’m a huge University of Oregon fan I wanted to showcase some fun facts about each university. To do this I wanted to use Will Sutton’s background image swap so I could have a branded view of the data for each school in the same dashboard.

The problem

I needed to have a single dashboard that would have a single filter. This filter needed to adjust the underlying data that was in each chart for the chosen university. I also needed to have that same filter change the background image for the dashboard overall. This would ensure that I’m not showing University of Oregon branding on Oregon State University data (eww…).

Naturally, I also downloaded Will’s dashboard to see how he did the swap. His approach was very similar to something I’ve done before when adding explanations to a dashboard. However, it turns out this solution wasn’t going to work for my dashboard.

The other piece to keep in mind is that when I collected the data I had multiple data sources (this is a hint at the solution for those reading ahead). Each of these data sources had slightly different structures to support the specific visualizations I wanted for the dashboard.

The (not so) solution

The simple approach for this was to add an image to your dashboard. This image will simply sit in the background of everything you lay on top of it.

Next, you can add a floating container sized to the specific dimensions of your dashboard. In this container you can add your second background image. You can then add a button for the container. This will allow you to turn on or off this image. Remember the first layer image we put down? If we turn off the container then the first layer image will show.

This works great if all you want to do is change the background image. However, obviously I don’t want to share University of Oregon data on Oregon State Universities view and vice versa. I could ask my stakeholders to click a button in one spot to change the image and then interact with a different filter somewhere else. However, that is far from the kind of experience I want for my stakeholders.

The (real) solution

Remember when I said we had multiple data sources? That was a hint that the solution we need is going to rely on some kind of parameter. So let’s start by creating a parameter that lets us pick the university (either UO or OSU).

Now the trick we used earlier for swapping out the backgrounds won’t work here because a container button isn’t capable of changing a parameter. If you know a way to get that to work let me know. I did figure out a workaround though. In this case, let’s just use maps to do the heavy lifting for us.

To start, create a new worksheet for one of the school’s images. Connect it to one of your datasets and create a metric on the rows and columns shelf that is the avg(0).

Next, change the default mark type to map like below.

Then in your Map dropdown select the data set you are using from the following pattern.

Then choose to add an image and change the specifications to fit the size of your dashboard. In my case I want the image to start at (0,0) and fit 850 pixels across and 1500 pixels vertically.

You should then get something like this.

With some reformatting to remove the axis labels, sheet titles, etc. you should now be able to add this directly into a floating container on your dashboard as a background image.

Now the trick to this approach is that your image is now a worksheet object instead of an image or container object. You can then use either standard sheet swap or dynamic zone visibility approaches to show or hide the background images using the same parameter you use to show or hide the underlying data that is exposed. Now you have a dynamic background image on your dashboard that can be powered by a parameter.

You can check out the final dashboard here. Another bonus tip in this dashboard is that the numbers laid out at the top of this dashboard were created using map layers which gives flexibility into where you show the numbers. To accomplish something like this without map layers would require you to build multiple sheets and cause Tableau to trigger multiple queries to render your views.

So what?

Why is this approach useful? Imagine you have different stakeholders that each had different internal brand needs. This approach allows you to swap the view that is shown to your stakeholders dynamically. If you have references in your data identifying views that only certain users need you can then selectively show data and branding to the stakeholders that only they need to see. This allows for you to create multiple dynamic views that can all be controlled via parameters thereby reducing your overall dashboard development by compiling multiple stakeholder views into a single dashboard.

Image magic in Tableau with maps was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

What’s the point? I don’t have anything to contribute? There isn’t anything that I can offer to somebody else. It’s a lot of work for little benefit.

You’ve probably had similar thoughts to those above. However, each of us has a unique perspective and point of view. I’ll be the first to admit that your perspective might not be valuable for everyone, BUT it will be valuable for someone.

Spoiler alert!

You are probably the person that will benefit the most. Writing is an excellent way to clear your thoughts and develop frameworks. Writing is especially powerful as a mechanism for refining ideas and consolidating your thoughts.

Within a technical framework writing is especially powerful as a reinforcement mechanism. It becomes a process for you to explain concepts in a way that you understand best. For highly complex topics you now have a reference point you can use the next time you need to do something similar. Think of technical writing as bread crumbs you leave yourself.

The best part of writing is that the best practices you develop by practicing in Medium apply to work as well. In a corporate setting writing internal wikis are powerful ways to communicate your perspective and anchor a conversation. This anchoring is a powerful approach to implement change as peers can all start from the same baseline.

Getting started

The first and most important step in writing on Medium is simple. Think of a topic and start writing. Your writing doesn’t need to be perfect (guaranteed it won’t be). You might not even like your first post. Doesn’t matter… publish and share it!

A bias for action is the critical piece of this first step. I see a lot of people passively consume but rarely contribute. If you want to get better you need to contribute. Set personal goals and have fun.

What to write

I especially enjoy writing about Tableau. In a work context I encounter many people that have varying levels of capability with Tableau. It isn’t uncommon that people who are newer in their journey ask questions. These questions are gold! Document and share solutions to their questions.

Writing solutions to these questions gives you a repository of tips and tricks you can refer back to. It also has the sneaky benefit of meaning you now have a playbook for answering the same questions in the future.

Getting social

Once you’ve done the hard part of writing now you need to socialize. While this part is optional I highly encourage sharing. I consider sharing optional because Medium will share your work organically. However, sharing is important as it gives you the opportunity to connect with other members of the same community. Within the Tableau community there are plenty of places to share. You can volunteer to present at a Tableau User Group (they’re always looking for speakers). You can share it to social platforms like LinkedIn, Tableau Public (if there’s a corresponding visualization), Twitter/X, or Blue Sky. This is your opportunity to give back to everyone that has shared their ideas before.

Within Medium you can also work with publications. For example, the Retail and Consumer Goods Tableau User Group recently began a publication focused on all things Tableau, data viz, analytics, and retail. As a non-paying Medium contributor you can still write and submit your work to a publication (follow the publication’s rules and recommendations though). This is a great way for you to connect with other like minded professionals.

This should go without saying but as you create content be sure to share it with your colleagues at work. It’s safe to say that the reason you were writing in the first place was to solve a business problem you faced. It is all but guaranteed that some of your peers have a very similar problem to what you solved. My preference is to share my writing via direct message (where applicable) or within social channels on Slack that have peers working on similar projects.

Conclusion

Regardless of your experience level or technical capabilities YOU have a story worth sharing. Your approach is exactly what someone else needs. By contributing to the community you’ll be forging lasting relationships and friendships. This is an opportunity you won’t want to miss.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

If you made it this far and found this valuable let’s connect! Share what you liked in the comments. You can also find me on LinkedIn and Tableau Public.

I’m also a 2025 Tableau Ambassador and leader of the Retail & Consumer Good Tableau User Group (here). I’d love to connect in one of our meetups.

Why you should write on Medium was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Step 1: Data set up

Let’s dive right into the build of this dashboard. This dashboard will use the Superstore dataset that comes with Tableau. After connecting to Superstore we need to move sub-category onto the rows shelf and filter to the 2 most recent years. In my example I’m using the years 2023 and 2024.

Then add sales to the columns shelf and the order date year to the marks shelf. This gives us sales for the two years, which is not quite what we want. However, we can add a simple calculation to get what we need. Use the following formula to create a field “1. Sales Growth”.

SUM(if year([Order Date]) = 2024 then [Sales] else null end)
/
SUM(if year([Order Date]) = 2023 then [Sales] else null end)
- 1

You can then sort sub-category by the sales growth descending. You should get something like this.

At this point, I highly recommend you play around with this view to see if you can get something similar to the final output. You’ll quickly learn that standard tricks won’t work all that well here.

Step 2: Create a dual axis workaround

The first thing that becomes apparent is that a dual axis bar chart is not capable of getting the formatting to match exactly. This is a huge bummer as that would make this chart trivial to create. Instead we’re going to have to pull out some tricks we learn in Workout Wednesday (see sample problem here).

This means we’ll need to get tricky ourselves. Let’s duplicate “1. Sales Growth” twice and rename both fields so we can have “1. Sales Growth”, “1. Sales Growth Left” and “1. Sales Growth Right”. All sorting should still be occurring on “1. Sales Growth”. This will help us keep track of the makeshift dual axis chart we’ll create. The make sure both are on the columns shelf until we get something like this.

Now let’s refine the query used to generate the left and right sides of the sales growth calculations. Let’s adjust the left side calculation to:

if (
SUM(if year([Order Date]) = 2024 then [Sales] else null end)
/
SUM(if year([Order Date]) = 2023 then [Sales] else null end)
 — 1 ) >= 0 then 0

else (
SUM(if year([Order Date]) = 2024 then [Sales] else null end)
/
SUM(if year([Order Date]) = 2023 then [Sales] else null end)
 — 1 )
end

The right side of the equation should be:

if (
SUM(if year([Order Date]) = 2024 then [Sales] else null end)
/
SUM(if year([Order Date]) = 2023 then [Sales] else null end)
- 1
) <= 0 then 0

else (
SUM(if year([Order Date]) = 2024 then [Sales] else null end)
/
SUM(if year([Order Date]) = 2023 then [Sales] else null end)
- 1)
end

Adjusting these calculations will give you only negative values on the left side equation and only positive values on the right side equation. Then fix the axis for the left side to be similar to the following

We then need to do the same for the right side axis.

You should then have something that looks like this. At this stage double check your sort is still working as expected.

Step 3: Scale your axis value

This is looking pretty promising so far but there’s something odd going on. Machines and Envelope sales declines aren’t really comparable to the 500% growth we see for Fasteners but the bars suggest the same order of magnitude. This tells us that we have an issue with the scaling that is happening on the axes. So let’s fix the issue.

To fix the scaling let’s identify maximum growth on the right and the maximum decline on the left side. We’ll then pass these values into parameters that can update on the workbook load so we can have dynamically updating axes.

We’ll use the following formula “1. Sales Growth Right Max” to calculate the maximum value on the right side:

-1 * max(
(
{fixed [Sub-Category]:SUM(if year([Order Date]) = 2024 then [Sales] else null end)}
/
{fixed [Sub-Category]: SUM(if year([Order Date]) = 2023 then [Sales] else null end)}
- 1
))

We’ll always create the “1. Sales Growth Left Min” to calculate the maximum sales decline on the left:

-1 * min(
(
{fixed [Sub-Category]:SUM(if year([Order Date]) = 2024 then [Sales] else null end)}
/
{fixed [Sub-Category]: SUM(if year([Order Date]) = 2023 then [Sales] else null end)}
- 1
))

What we want to do is create two parameter values based on both of these values. You can right click on the calculated fields to create these parameters. After doing this you should have 2 new parameters. You will then add these parameters as reference lines for your chart. Be sure to suppress any labeling and line formatting so they are invisible. You will want something that looks like this for both the maximum sales growth and maximum sales decline.

Once done, you should have a view that looks like this.

Step 4: Label the observations

Perfect! We are getting close. You can take my word for it or you can try to build labels yourself but bar charts just aren’t going to work here. This is because we are looking for a very specific kind of labeling. However, gantt bars are going to work perfectly here. I created something similar for a walkthrough on waterfall charts you can check here.

To start with let’s change the default chart types from bars to gantt. Doing so will yield this:

Now, let’s hack these gantt marks to get a bar. For the right side you will ctrl drag the sales growth right field from columns onto size in the marks shelf. This will add the sales growth onto your gantt marks like this.

This is close to what we want but not quite right so let’s apply the same trick we used for building waterfalls to use the negative of the sales growth on the marks shelf to reorient the location of the bar. Do the same for the left side and you’ll get the following:

We now have gantt bars disguised as a bar chart as desired. Now lets create the labels. I’ll give you the formulas but because we want to mix between showing a number and text we’ll have to apply a couple of cumbersome calculation to the growth values. If we don’t account for the number formatting we’ll end up with number formatting that has a LOT of decimal values suggesting a level of precision we shouldn’t be comfortable with.

Here is the calculation for the left label:

if {fixed [Sub-Category]:SUM(if year([Order Date]) = 2023 then [Sales] else null end)}
< {fixed [Sub-Category]: SUM(if year([Order Date]) = 2024 then [Sales] else null end)}
then [Sub-Category]

else str(int([1. Sales Growth]))
+
‘.’
+
str(int(
(
[1. Sales Growth]
-
floor([1. Sales Growth])
)*10)
)
+
str(int(
((
[1. Sales Growth]
-
floor([1. Sales Growth])
)*100) %10)
)
+ ‘%’
end

For the right label we’ll use the following:

if {fixed [Sub-Category]:SUM(if year([Order Date]) = 2023 then [Sales] else null end)}
>= {fixed [Sub-Category]: SUM(if year([Order Date]) = 2024 then [Sales] else null end)}
then [Sub-Category]

else str(int([1. Sales Growth]))
+
‘.’
+
str(int(
(
[1. Sales Growth]
-
floor([1. Sales Growth])
)*10)
)
+
str(int(
((
[1. Sales Growth]
-
floor([1. Sales Growth])
)*100) %10)
)
+ ‘%’
end

Then add the left label to the left side text field on the marks shelf and the right label for the right side. You’ll then get the following:

Then with a little touch up and formatting we can get something like this:

Summary

While it isn’t necessarily worth building this out everytime I need to create a bar chart this view is powerful and concise. I like how it cleanly shows the data next to the bar while alternating the labels on/off depending on whether the sub-category is growing or not.

Reinventing the Humble Bar Chart was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.

Imagine you’re a data scientist or technical analyst that has a collection of reports that you run regularly. None of these reports are incredibly difficult to run but they all require some finesse. Essentially they require some form of manual input. Maybe that input is a date range, list of products, or list of locations. Wouldn’t it be nice to automate the collection of these inputs?

In this post I’ll walk through an LLM based approach and general framework you can use to automate these pipelines. It helps to walk through a tactical example so I’ll look at a simple example where I want to have an automated process to generate behavior based audiences at scale.

Process overview

To incorporate this process you will need to have key pieces in place. Below is a diagram outlining each necessary component to the proposed workflow.

Keep in mind that this proposal is intended to be a bare essentials process. This is a framework that you can add to or take away from at your leisure. For example, I’m only recommending a single LLM model run, but you could just as easily swap this out with a more agentic approach where you run multiple LLM’s simultaneously to get multiple recommendations that could then be evaluated by another agent. For this purpose though a lot of those complexities will just muddy the key points we need to review.

User intake

This should be as low-touch as possible for you. Ideally, you have an established intake process that non-technical stakeholders can access. An example, would be a simple Slack bot that you set up that will let your stakeholders input custom text for whatever audience they want. This allows your stakeholders to explain in detail what they are looking to accomplish with the audience they need.

Once you have your Slack bot stood up, you will need to have that output into a table in your respective data lake. As part of this process you will want to have clearly defined metadata as well for this particular request. For example, you would want to ensure that the Slack bot would output the following features:

• Request ID (possibly linked to a work ticket in Jira or other ticket management software)
• Urgency
• User description (will be passed to the LLM)

LLM model

During this phase you will dig deep in tuning your model. Ideally, you have a backlog of requests you could use to manually test your prompt.

As you build your prompt you will want to keep the following in mind:

• Clearly define the structure of your inputs
• Specify that your outputs should ONLY be in a table structure (or other data structure that you plan to ingest in workflows later on)
• Clearly define all data requirements you need to use in your downstream models (e.g. date ranges, etc.)
• Defined lists of models that the model can choose from

Here is a sample prompt you can use as a starting point. Note that this prompt needs further refinement to restrict output to a single usable table format with variables that need to be evaluated.

You are a senior level data science practitioner. Your purpose is to take a custom explanation of audience profiles as described by your stakeholders and translate those descriptions into filtering and model recommendations for defining the relevant audiences. The output you define must consist of exactly one model recommendation and your confidence, between 0 and 1, in your model choice. You must also provide any recommendations for minimum or maximum spend and visit thresholds. You must also generate the ideal look back window for your recommendation.

Model recommendation

In this phase you would have a workflow that regularly picks up new audience requests in the data lake. Then you would iteratively loop through all new audience requests against the LLM you defined above. The goal here is to generate a simple table or series of tables that can again be picked up by other downstream processes.

At the end of this phase you will have tables with clear thresholds for features needed to support your model along with a specific model recommendation. For example, you would have clearly defined date ranges or geographic locations you want to use in defining your audiences. Remember that you will have defined the key features you need to pass into the assortment of audience models you can choose from.

Models

At this point you should have an output table with the relevant request ID’s and other model recommendations. Within your data platform you can then set up specific jobs that begin executing after your model recommendations have been made. The audience segmentation process can then be executed as individual workflows for each model type you have available or as a single, broad workflow through a directed acyclic graph (DAG).

The important piece here is that you will have a process that takes the output from the LLM and that will be used to define features and criteria that are needed for your audience segmentation frameworks. You can then add new methods for segmenting audiences over time as needed.

Reporting layer

The reporting layer is critical to the success of this automation process. This is where we introduce a human-in-the-loop process to evaluate the outputs of the LLM recommendation and assess whether or not the audience that was generated is tactically relevant. One consideration here is that you will want a low touch process that can be used to re-evaluate the initial model through the above process again.

Additionally, this is another space where you can introduce agentic frameworks to evaluate the outputs and provide recommendations on next steps. This isn’t recommended though for initial deployments until you have refined the above framework and have a good understanding of where gaps may exist in your framework.

Application

In Google’s Gemini I tested a couple of sample audiences that my hypothetical stakeholders may request. It is important to note that these examples are purely hypothetical and don’t actually reflect any segmentations I have created. Also, I used the prompt that I shared above to create these model recommendations.

Example #1

I need an audience that can be used to target ads for recent Nike brand shoppers at my company.

Example #2

I need to create an audience that identifies loyal shoppers of Pepsi that have a high likelihood of switching to coke if presented with an ad.

Summary

While there’s still plenty of tuning that is need to support this particular hypothetical example of audiences it should be clear that there is a lot of merit to this particular approach. This approach works for other processes as well especially when you simply need to parameters for analysis but your code can’t scale due to size but automating the requests can.

Scaling data science workflows was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a previous post I discussed how I have benefited from participating in data communities. Maybe you don’t feel comfortable working with communities outside of your organization. You’ll be missing out on building a rich network and friendships. That’s totally fine though because you can build them within your organization and get a lot of the same benefits.

In this post I’ll be discussing what you can do to build those communities and the benefits you can look to receive from participation. The journey isn’t short and there will be ups and downs but it’s definitely worth it.

What is a data community?

Whether it is openly acknowledged or not every organization needs to have some form of data community. The needs of those communities may differ widely. For example, the data community at a small, local shop may just be the people running the accounting and sales reports. For a larger organization there may be many different communities each focused on a specific data science or analytics' topic.

Ultimately, it doesn’t matter how big the community is. The community is there to provide guidance and best practices for the data you are using.

What are the benefits of a data community?

Let’s start by asking if you’ve ever been stuck trying to find a dataset or how to do a certain type of standard analysis. Sure, you can do a quick search online or maybe even pass your questions through an LLM. However, it’s very likely that the answers you find won’t be tailored to your specific use cases. It would be nice to just be able to ask a colleague who knows the nuance of what you are looking to do. This is the main benefit of data communities. These are the daily practitioners that have a shared analytics background.

While there are a lot of benefits from these communities I’ll list out some of the main benefits I’ve experienced.

• Learning data best practices
• Creating a portfolio that showcases technical skill growth
• Reducing the friction to get answers to questions I have
• Get visibility into blind spots in my applied technical knowledge
• Building relationships with people on other teams that I might not work with daily
• Gain confidence with sharing your work and incorporating feedback
• Gain confidence in giving feedback

This is definitely not an exhaustive list of benefits but should give you a flavor of the types of benefits you can expect to see.

My experience building data communities

Over the past five years I’ve stood up many different data communities. Most of them have actually been internal communities focused on specific needs of the organization or colleagues.

I’ve set up multiple Tableau communities that focus on developing more advanced technical skills or sharing simple tips and tricks to help users operate more efficiently. I’ve also built out book clubs reviewing technical and leadership skills. Externally, I’ve helped build the Retail and Consumer Goods Tableau User Group.

Each community is a bit different with different needs and goals. Some communities we’ve sunset others have been very successful. Below I’ll share some best practices that I’ve discovered over the past five years of building communities.

Building your own data communities

I’ll share some examples of what you can do today to start building your own data community. First, and most important, make this your own. Being creative, having fun, and providing value will give your participants a reason to attend and engage. This will likely be a side of desk project for you but can help establish you as a thought leader in your community.

Now let’s get into the practical work you need to do. I’ll provide recommendations for a larger company but a lot of the same steps still apply.

Step 1: Identify a need

In this phase you need to identify what communities are needed and something you are passionate about. For me, Tableau checked both boxes. Tableau seems simple to start with but the learning curve is deceptively steep. Additionally, we have a lot of new Tableau users that need to upskill quickly.

For you this may be integrating AI into workflows, mastering Databricks or Snowflake, applying statistical measurement, or whatever else you are passionate about and is a need for others.

Step 2: Get feedback

Don’t spend a lot of time on this step but you should connect with peers and other people you think might be interested and ask if they want to participate. This will confirm to you whether or not a community is needed. You’re also starting to seed potential participants at the ground level.

Step 3: Build infrastructure

You’ve decided it’s worth pursuing your ideas for a data community. Now you need to start creating the infrastructure behind what you want to accomplish. Below are key considerations you need to considering implementing:

• Slack or Teams channels for communication
• Schedule recurring community meetings
• Identify what you will be doing
• Internal wikis to record thought leadership and meetings

One key consideration is that people learn best by practice or application. How will your community give people the opportunity to practice? In the past I’ve used external community projects like the Makeover Monday project for Tableau. You can also use Kaggle data or even other internal data. My recommendation is to use external data because this forces you to think about what you will be doing out of context from what you’re already doing. This makes the learning more sticky. It also means you can start to share that work externally if you want.

Step 4: Kick off

Now you need to kick off the community. This is where you start to market your community and start to let anyone and everyone know about your new community.

Now comes the long slog. You will be on the hook for making sure that you have quality content (another reason to use external projects) which can be a heavy lift if you aren’t careful. Regardless of whether you are the only participant or you have fifty participants make sure you’ve done your homework every time and honor your commitments to the community.

Step 5: Refine

After you’ve been running the community for a while get some feedback from your participants. Ask them what could be better?

Anything and everything should be off the table during refinement. I’ve sunset communities that I’ve set up in the past and that’s ok. We all got value while they were running but decided the effort was too high and the return on personal investment just wasn’t there.

Conclusion

As you look to upskill there is no reason to go alone. If you want to develop quickly lean on those around you and give back. You will learn fastest by practicing and teaching others. Doing this with others makes the whole journey a lot more fun as well.

Building Technical Communities was originally published in DataAI on Medium, where people are continuing the conversation by highlighting and responding to this story.

Waterfall charts are standard charts for finance and accounting. They convey a lot of information in a relatively small space and most stakeholders have seen this chart type enough to understand how to interpret the data.

However, waterfall charts in Tableau can be tricky to build. Once you understand the fundamentals though they actually teach key principles for navigating and building more advanced vizzes.

What is a waterfall chart?

Waterfall charts are a viz type that shows the cumulative effect of increases or decreases of the key metric you are looking to monitor.

For example, if you were looking to understand the relationships between sales, costs, and any strategic initiatives on total profitability then a waterfall chart is probably the easiest and fastest way to show the contributions of each initiative.

Data Preparation

To start with this is the viz we are going to be building. You’ll notice that this is just a bar chart with some sneaky missing pieces. However, the trick to building these charts is to realize that, despite what it looks like, these are not actually bar charts.

In this example we’ll use the Superstore data to build out this chart. Our goal is to look at Superstore’s profitability for the most recent year. However, the Superstore data isn’t in the correct structure to easily support a waterfall chart (see here for an explanation). In this case I’ll filter the data to only the last year (2024 at the time of this writing). I’ll also pivot the measures that I want to include in the waterfall so that I have a unique row for each feature instead of having a unique column for each feature. I’ll also calculate cost ( sum([Sales]) - sum([Profit]) ). You can see the structure below.

For simplicity I’m going to copy this data and paste it into Excel to create a new data source that we can use a little bit easier. If you are a considering implementing a waterfall chart I highly recommend pivoting your data before ingestion into Tableau through a platform like Databricks or Snowflake especially if you are already using them in your development cycles. This can also be done in Tableau by pivoting the columns in the edit data source menu. With some simple edits in Excel I can get something in this format.

Now I need to save that data somewhere I can easily access it via Tableau. Then I obviously need to connect to the data in Tableau.

Build the Waterfall

Phew! Data prep is done. Random rant, but Tableau can be very sensitive to data structures. Some vizzes are easy to do with tall data but impossible with wide data. That is the case here. We shifted our data model from a wide view to a tall view and that will make all the difference.

Now let’s get to work. I’ll add the category to the columns shelf and exclude the “Grand Total” values (at this point those are only going to be used for quality checks). Let’s also remove “Profit” from our metrics as we’ll calculate that through the waterfall.

Step 1: Create a height variable

You’re now supposed to say but that’s just a bar chart and that you were promised something different. Now we’ll get wild and crazy. Let’s create a calculated called “Waterfall Height”.

sum(
    if [Metric] = 'Sales' then [Value] 
    else -[Value] 
    end
)

All this formula does is create a negative value for cost and a positive value for sales. Let’s add this to the rows shelf to get this.

As color will be helpful for telling us what is going on let’s also add “Waterfall Height” to colors on the marks shelf. We’ll also edit the color to be 2 step diverging and centered on zero like this (I’ll be editing the default color choices because I don’t like the defaults but use what works best for you).

You should now have something that looks like this.

Step 2: Create a running sum

Now we’ll need to add a table calculation on “Waterfall Height” in the rows shelf. We will want to set the running total and can otherwise keep the default options.

You should get something that looks like this.

Now if you’re still thinking that this isn’t a waterfall chart you’re not wrong. Hang with me though as we’re almost there.

Next, change the marks type to Gantt from automatic. Earlier I had mentioned that a waterfall was not a bar chart in Tableau and this is why. The running total we calculated earlier ended up taking sales and subtracting our cost for furniture, taking the remainder and adding office supplies sales and then subtracting office supplies cost, etc. If you think about what a waterfall chart does, it does just that. It takes your first observation and then just creates a running tally of where you’re at. By changing to a Gantt chart you’ll get this.

But there aren’t any bars yet! We’re going to apply a trick with gantt charts. You can add a measure to size to the gantt which will create (in this case) vertical depth to your gantt bar. Now, if we look at the first observation for furniture sales we want the bar to go from zero to the height of the gantt. We already have that distance though. It’s just the sales value we calculated earlier in waterfall height. However, if we just add waterfall height to size we’ll get a bar from ~$220K to about ~$440K which is not what we need. Instead, we need to add the negative of the Waterfall Height metric to size. This will shift the height of the gantt down to axis like we need. Let’s do that now by moving Waterfall Height to size, double clicking, and adding a minus to the front of the calculation.

Now, this is looking like a waterfall chart, but we don’t have the total yet. Let’s add the row totals and edit the grand totals column name to show profit as that is what should be reported now.

You now have your very first waterfall chart. Congratulations! If you’d like to explore the viz or reverse engineer my work check out this viz here.

Chasing waterfalls was originally published in Retail Tableau User Group on Medium, where people are continuing the conversation by highlighting and responding to this story.