Data Visualization and Dashboard Design Questions

Direct answer
Visualize forecast uncertainty as a fan chart: a central line for the point forecast, nested shaded bands widening with distance into the future for the prediction intervals (e.g. 10th-90th and 25th-75th percentiles), with alternative scenarios and key assumptions called out as labeled annotations rather than additional overlapping lines.

Structured elaboration

1. Computing the percentile bands: simulate (or analytically derive) a distribution of plausible future paths given the model's assumptions (drift/growth rate and volatility), then take percentiles (e.g. 10th, 25th, 50th, 75th, 90th) across simulated paths at each future period.
2. Visual encoding: shade the 10th-90th band lightly and the 25th-75th band more darkly (nested bands), with a solid line for the median (50th percentile); this nested-band "fan" shape is what gives the chart its name and communicates that uncertainty widens the further out the forecast goes.
3. Alternative scenarios: rather than a third overlapping line competing visually with the fan, label named scenario lines (best/likely/worst) distinctly if scenario-based analysis is separately required, or fold scenario logic into the percentile-band simulation itself if the scenarios are just different assumption sets.
4. Key assumptions: state the growth-rate and volatility assumptions used to generate the bands directly in a caption or annotation, since the bands' width is only as trustworthy as those assumptions.
5. Legend: label the median line "Point forecast" directly (not just "median," which is technically correct but less immediately meaningful to an executive reader); label the two shaded bands "80% range (P10-P90)" and "50% range (P25-P75)" respectively, so a viewer knows exactly what each band means without recalling percentile terminology; and if named scenario lines are also shown, give them their own legend entries ("Best case," "Likely case," "Worst case") distinct from the percentile-band entries so the two types of uncertainty representation, statistical bands versus named scenarios, aren't visually conflated.

Worked example (executed)
Simulating 5,000 monthly revenue paths from a $1,000,000 starting point with a 2% expected monthly growth rate and 6% monthly volatility, the resulting percentile bands widen substantially over a 12-month horizon: month 1's 10th-90th range is [$942,221, $1,096,477] (a band width of about $154,000), while month 12's 10th-90th range widens to [$956,651, $1,619,409] (a band width of about $663,000), a roughly 4.3x widening driven purely by uncertainty compounding over the forecast horizon.

import numpy as np
rng = np.random.default_rng(11)
paths = np.zeros((5000, 12))
paths[:, 0] = 1_000_000 * (1 + rng.normal(0.02, 0.06, 5000))
for t in range(1, 12):
    paths[:, t] = paths[:, t-1] * (1 + rng.normal(0.02, 0.06, 5000))
bands = {p: np.percentile(paths, p, axis=0) for p in [10, 25, 50, 75, 90]}

Trade-offs and pitfalls
A fan chart's widening bands can look alarming to a stakeholder unused to seeing forecast uncertainty made explicit; pair it with a brief explanation that widening bands reflect honest compounding uncertainty over time, not a sign the model is getting worse.

Direct answer
Map nominal data (unordered categories) to color hue or shape, ordinal data (ordered categories without meaningful numeric spacing) to a sequential color scale or position along an ordered axis, and interval or ratio data (meaningful numeric spacing, with ratio data also having a true zero) to position, length, or area, since those channels support precise magnitude comparison that nominal/ordinal data doesn't need or support.

Structured elaboration

• Nominal: categories with no inherent order (e.g. product line, region); map to hue (a categorical color palette) or shape, since there's no magnitude to encode, only identity.
• Ordinal: categories with a meaningful order but no consistent numeric spacing (e.g. customer satisfaction: low/medium/high); map to a sequential color scale (light to dark) or an ordered position on an axis, preserving the ORDER without implying the gaps between categories are numerically equal.
• Interval: numeric data with meaningful spacing but no true zero (e.g. a calendar date, or a temperature-like index); position along an axis works well, but ratio statements ("twice as much") aren't meaningful, so avoid area or a zero-anchored bar chart implying a ratio comparison that isn't valid.
• Angle: a weaker channel than position or length for ratio data (per Cleveland-McGill: William Cleveland and Robert McGill's classic 1984 study that ranked how accurately people judge different visual channels, from position and length at the top down to angle, area, and color at the bottom; humans judge angles less accurately), most familiar as pie or donut slice size; usable for ratio data in a pinch, but a sorted bar chart is generally the more precise choice when exact ranking matters.
• Ratio: numeric data with a true zero (e.g. revenue, count of users); this is where length, area, and zero-based bar charts are fully valid, since "twice the length/area" genuinely means "twice the value."
• Why some encodings are more perceptually accurate: position and length are judged by the human visual system with the least error across viewers (per Cleveland-McGill), which is why ratio/interval data (where those channels are valid) should generally prefer them over area or color when precision matters.

*Worked example (e-commerce sales dashboard)

• Nominal: payment method (credit card, PayPal, etc.) shown as distinct colored segments in a stacked bar, since there's no inherent order.
• Ordinal: customer satisfaction tier (low/medium/high) shown with a sequential color scale from light to dark, preserving order visually.
• Interval-like: a day-of-week index used for seasonal pattern coloring, where position matters but "Wednesday is twice Monday" isn't a meaningful statement.
• Ratio: revenue by region shown as bar length, where a bar twice as long genuinely means twice the revenue.

Trade-offs and pitfalls
Using a bar chart (implying a ratio, zero-based comparison) for interval data without a true zero, or using color to represent ratio data where a viewer needs precise comparison, are the two most common mismatches between data type and encoding.

Direct answer
Choose histogram bin width using a data-driven rule like the Freedman-Diaconis rule (width = 2 * IQR / n^(1/3)) or Scott's rule (width = 3.49 * std / n^(1/3)), and to make histograms comparable ACROSS groups, compute the bin width (and bin edges) once from the pooled/combined data rather than independently per group, since independently-computed widths will differ purely because of each group's own sample size, even when the underlying distributions are identical.

Structured elaboration

1. Freedman-Diaconis: uses the interquartile range (robust to outliers) and sample size; generally preferred over Scott's rule when the data has heavy tails or outliers, since it doesn't assume a roughly normal shape.
2. Scott's rule: uses the standard deviation and sample size; simpler and works well for roughly normal data, but is more sensitive to outliers than Freedman-Diaconis since standard deviation itself is outlier-sensitive.
3. The cross-group comparability pitfall (verified by execution): computing Freedman-Diaconis bin width independently for two samples of the SAME underlying normal distribution (mean 50, std 10) but different sizes (n=500 vs. n=5000) produced widths of 3.369 and 1.542 respectively, and correspondingly 22 versus 47 bins, purely because of the n^(1/3) term in the formula, not because the underlying distributions actually differ.
4. Fix: compute the bin width from the POOLED data across all groups being compared (or fix explicit shared bin edges), so every group's histogram uses the identical width; in the same executed example, the pooled Freedman-Diaconis width came out to 1.493 (49 shared bins), used consistently for every group's histogram.
5. Pitfalls when distributions differ in scale or sample size: a small-sample group with a genuinely different scale can still end up mis-binned if you use pooled bin width blindly; sanity-check that the shared bin width still resolves the smaller group's shape reasonably (not too few bins) before finalizing.

Worked example (executed)

import numpy as np
def freedman_diaconis_bin_width(x):
    q75, q25 = np.percentile(x, [75, 25])
    iqr = q75 - q25
    return 2 * iqr / (len(x) ** (1/3))

np.random.seed(42)
group_a = np.random.normal(50, 10, 500)
group_b = np.random.normal(50, 10, 5000)
combined = np.concatenate([group_a, group_b])
shared_width = freedman_diaconis_bin_width(combined)  # 1.493

Independently: group A width 3.369 (22 bins), group B width 1.542 (47 bins), for the SAME underlying distribution: comparing the two histograms side by side at these independently-chosen widths would visually suggest they differ in granularity for no real reason. Using the shared pooled width of 1.493 for both fixes the comparison.

Trade-offs and pitfalls
Both rules assume a reasonably continuous, unimodal-ish distribution; for a genuinely multimodal or highly skewed variable, a data-driven bin-width rule can still produce a misleading histogram, and a log-transform or a different chart (like a violin plot) may serve better than tuning bin width alone.

Direct answer
Use a sequential palette (one hue, increasing intensity) for a single quantity that runs low-to-high, a diverging palette (two hues meeting at a neutral midpoint) when there's a meaningful zero or target to diverge from, and a categorical palette (distinct, non-ordered hues) for unordered groups; keep any multi-series legend to the smallest set of colors a viewer can hold in memory.

Structured elaboration

• Sequential: for a quantity like "revenue per region" where only magnitude matters, one hue from light to dark (or low to high saturation) preserves the sense of order.
• Diverging: for a quantity like "percent change vs. last quarter" or "actual minus target," use two contrasting hues (e.g. blue-to-red) meeting at white/gray at zero, so the viewer instantly sees direction as well as magnitude.
• Categorical: for genuinely unordered groups (product lines, regions, channels), pick 4-6 maximally distinguishable hues; going past 8-10 categorical colors makes the legend unreadable regardless of how distinct the hues are.
• Continuous vs. discrete color scales: a continuous scale blends smoothly across the full range of values (e.g. a choropleth, a map where each region is shaded according to its value, shaded on a smooth gradient), which best conveys fine-grained magnitude differences; a discrete/binned scale groups values into a small number of steps (e.g. 5 quantile buckets), which trades precision for a legend a viewer can actually name and remember, and is usually the better choice once the audience needs to talk about "the top bucket" rather than an exact value.
• Multi-series legend design: order series in the legend to match their visual order in the chart (e.g. top-to-bottom matching the lines' end positions), use consistent colors for the same entity across every chart in a dashboard, and give each series a clear, descriptive name rather than a generic label like "Series 3", vary line style (solid/dashed/dotted) alongside color so series stay distinguishable in grayscale or for colorblind viewers, and make the legend interactive (click to isolate/hide a series) when there are more than 4-5 series.

Worked example
A dashboard showing "gross margin by product line" for three product lines, Alpha at 22% margin, Beta at 18% margin, and Gamma at 9% margin (unordered categories), should use a 3-color categorical palette (blue for Alpha, orange for Beta, green for Gamma) so each line reads as a distinct entity rather than an ordered scale; a companion tile showing "margin vs. target" for the same three lines, Alpha +4pts, Beta +1pt, Gamma -3pts, should instead use a diverging red-white-green palette centered at 0, so Gamma's bar renders in red, Beta's in near-white, and Alpha's in green, letting a viewer read direction (over or under target) at a glance without reading the numbers.

Trade-offs and pitfalls
The most common error is using a rainbow (unordered, high-saturation) palette for genuinely ordered/quantitative data, which implies false category boundaries where there are none; a second common error is reusing the same hue for a different entity across two different charts on the same dashboard, which silently breaks the color-to-entity mapping a viewer has learned.

Direct answer
Use a grouped (clustered) bar chart when you need to compare individual category values precisely across a few time periods or groups; use a stacked bar when the TOTAL and the composition both matter; and use a 100%-stacked bar specifically when only the relative MIX (not the absolute total) matters, since 100%-stacking deliberately discards the total.

Structured elaboration

• Grouped/clustered bars: place each category's bars side by side per period; best for a business question like "how did revenue for each of our 3 product lines compare quarter to quarter", where the audience needs to read off each product line's precise value in each quarter, not just the combined total; readability degrades past roughly 3-4 categories per group, since the bars become thin and hard to compare.
• Stacked bars: stack categories within one bar per period, showing both the total (bar height) and each category's absolute contribution; best for a business question like "how has total support ticket volume changed, and how much of that total comes from each priority level", where both the overall trend and the composition matter together. Comparing a MIDDLE segment's size across bars is genuinely hard, since middle segments don't share a common baseline.
• 100%-stacked bars: normalize every bar to the same height, showing only the proportional mix; best for a business question purely about composition shift over time (e.g. "is our channel mix shifting toward paid?"), but actively hides whether the total itself grew or shrank, which can mislead if the audience assumes the totals are also comparable.
• Readability with many categories/groups: past a handful of categories, any of the three becomes cluttered; consider limiting to the top categories plus "other," or switching to small multiples (one chart per category, all with a shared axis) instead.

Worked example
A channel-mix analysis: a 100%-stacked bar clearly shows that paid channels grew from 20% to 35% of total revenue over four quarters, but without a companion note or a paired stacked (non-normalized) bar, a viewer might wrongly assume total revenue grew too, when in fact total revenue was flat and only the MIX shifted.

Trade-offs and pitfalls
Always pair a 100%-stacked bar with the absolute total displayed somewhere (a companion KPI or a second small chart), since presenting mix-shift alone risks the audience conflating a proportional change with an absolute one.