§4.5
Dashboard Decision Systems
A dashboard is not successful because every chart is attractive. It is successful when the reader knows what to monitor, what to diagnose, and what decision or next test follows. The Progresso soup dashboard already has a strong visual story. The teaching opportunity is to turn that story into a decision system.
The executive question: how should a dashboard move from monitoring to diagnosis to action?
The existing soup dashboard has four strong ingredients: monthly category volume, seasonal pricing, a store map, and category share. It also has an intuitive headline: demand weakens in summer while Progresso price rises. That is a good dashboard seed because the pattern is visual, memorable, and strategically uncomfortable. The redesign challenge is to keep the strong case evidence while making the decision path explicit.
The redesign question is not whether the dashboard looks polished. It does. The question is whether the dashboard ends in a better managerial decision question. A visual system that stops at "interesting" is unfinished.
Figure 1 treats the current dashboard as a critique object. Each panel gets a job. Each job gets an upgrade. The point is to teach a reusable design discipline: monitor, diagnose, decide.
Progresso soup decision dashboard
One screen, three modes: monitor the cycle, diagnose the heterogeneity, decide the next test.
Summer trough
Monitor-54%
Jun category volume vs Jan
Price into weakness
Monitor+47%
Jun Progresso price index (Jan=100)
Share spread
Diagnose34% vs 12%
East vs South winter share
Month-adj. slope
Decide-2.46
national log-log price→volume
Category volume by month
MonitorWinter vs non-winter share by region
DiagnoseWinter share with uncertainty band
DiagnoseWhere Progresso is strong (winter share)
DiagnoseBinned by census region — an approximation. Map approximations are a caveat that belongs next to the chart.
Next test, not a verdict
The dashboard shows countercyclical pricing that varies by region. It cannot prove price caused the volume drop. The decision it earns is the next one: estimate elasticity with a design that separates price from seasonal demand, and run it region by region where the share levels differ most.
Critique: each panel gets a job, each job gets an upgrade
Monthly category volume
MonitorShows the category demand seasonality.
Add active store count and state the seasonal trough explicitly.
Seasonality of pricing
DiagnoseShows Progresso price rising into the demand trough.
Add a benchmark line for Campbell and annotate winter/non-winter.
Good and bad markets map
DiagnoseShows geographic variation in Progresso share.
Clarify classification rule and avoid relying on external map fetch.
Share of category volume
DecideShows share collapse when Campbell expands.
Add next-step question: test whether price policy or seasonality explains the pattern.
Redesigned dashboard sequence
Step 1
Executive question
Is Progresso pricing against the seasonal demand cycle?
One-sentence headline with winter/non-winter comparison.
Decide whether the pattern deserves a pricing test.
Step 2
Demand baseline
When is category demand strongest and weakest?
Monthly volume indexed to January plus active store counts.
Separate seasonal demand from price action.
Step 3
Price response
Does price rise when demand weakens?
Progresso and Campbell monthly price lines.
Identify the countercyclical pricing pattern.
Step 4
Market heterogeneity
Is the pattern national or regional?
Region small multiples for price and share.
Avoid one national recommendation if regions differ.
Step 5
Statistical preview
How steep is the price-volume association?
Log price vs log volume scatter with coefficient intervals.
Bridge to later elasticity and identification chapters.
Step 6
Next test
What would we need to know before changing price?
Action panel: descriptive pattern, causal limit, recommended experiment or quasi-experimental design.
Do not treat the dashboard as causal proof.
The strongest dashboard move in Figure 1 is the final step. A descriptive dashboard should not end by declaring that Progresso should lower price. It should end by naming what must be learned next: whether price changes caused lower volume, whether promotions or inventory explain the pattern, and which regions deserve separate pricing tests.
Monitor, diagnose, decide
A dashboard sequence has three modes.
Monitor asks whether something important changed. In the soup case, monthly category volume monitors the seasonal demand cycle.
Diagnose asks where the change came from. Seasonal price, share, region, and store maps diagnose whether the Progresso pattern is broad, regional, or competitive.
Decide asks what action or test follows. The decision panel should distinguish what the dashboard shows from what it cannot prove.
This distinction keeps the dashboard honest. A monitor panel should not pretend to identify causes. A diagnostic panel should not skip the next question. A decision panel should not hide uncertainty.
Concept check
Three questions spanning the decision-ending dashboard, the monitor-diagnose-decide handoff to causal work, and editing a visual brief around the question.
- 1.The soup dashboard makes one pattern unmistakable: volume falls in summer while Progresso's price rises. A reviewer calls it "finished" because the insight is obvious at a glance. What is the design flaw this praise is hiding?
- 2.In the monitor-diagnose-decide sequence, the decide panel shows volume dropping as price rises. A manager wants the caption to read "raising price lowered volume; cut price." Why should the dashboard refuse?
- 3.Building the capstone's six-panel decision brief, you have computed revenue, AOV, repeat rate, gross margin, revenue per active customer, and a rolling trend. The instinct is to give each its own panel "for completeness." What does the brief discipline require instead?