Data Visualization and Dashboard Design Questions

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
Maintain a versioned library of shared visualization components (color palettes, KPI-tile templates, chart-type wrappers) with clear governance and discoverability, so every team builds on the same visual language instead of re-inventing (and subtly diverging from) it dashboard by dashboard.

Structured elaboration

1. Component scope: shared color palettes (sequential, diverging, categorical, all pre-validated for accessibility), KPI-tile and chart-type templates with consistent styling, and (if building custom visuals) a documented component API (props for title, data, annotations).
2. Governance: a small owning team reviews and approves new components or changes to existing ones, so the shared library doesn't fragment into competing versions.
3. Versioning: semantic versioning (a version number like 2.4.1, where the first number only changes for a breaking change, the second for a backward-compatible addition, and the third for a bug fix) so consuming dashboards can pin to a known-good version and upgrade deliberately rather than being broken by an unannounced change.
4. Discoverability: a documented, searchable catalog (with visual previews) so teams can find and reuse an existing component instead of building a near-duplicate.
5. Backward compatibility: deprecate old component versions with a clear migration path and sunset timeline rather than breaking consuming dashboards outright.
6. Testing: visual regression tests (does the component still render as expected) and accessibility tests (contrast, keyboard navigation) run on every component change before it's published.

Worked example
A shared "KPI tile" component with a documented API (value, trend, target, threshold-color props) is adopted across 40 dashboards; when the design team updates the palette for accessibility, every consuming dashboard picks up the improvement automatically on its next version bump, rather than 40 teams needing to independently update their own copy-pasted styling.

Trade-offs and pitfalls
A shared component library that isn't actively governed tends to drift into inconsistent forks anyway, as teams patch their local copy rather than contributing back; investing in a lightweight but real review/approval process is what actually prevents the fragmentation the library was built to solve.

Direct answer
A good tooltip shows the exact value with its unit, a comparison (change vs. a prior period or target), and one piece of context (e.g. a rank or a small trend), keeping to 3-4 pieces of information so it doesn't become a second chart the user has to read.

Structured elaboration

1. What to include: the precise value (often more precise than what's shown on the visual axis), a labeled unit, a period-over-period or target comparison, and optionally a micro-visual (a tiny sparkline or bar) if it adds real context rather than decoration.
2. Avoiding overload: cap the tooltip at a handful of fields; anything beyond that belongs in a drill-through view, not a hover tooltip that has to be readable in a couple of seconds.
3. Inline vs. tooltip: put the information every viewer needs at a glance directly on the chart (labels, key annotations); reserve the tooltip for supplementary precision and context that most viewers don't need every time but some viewers occasionally do.
4. Micro-visuals in tooltips: a small inline sparkline showing the last several periods' trend can be valuable in a tooltip when the main chart itself doesn't show history (e.g. hovering a single bar in a bar chart), but avoid stacking multiple mini-charts into one tooltip.

Worked example
Hovering a KPI tile labeled "Monthly Active Users": the tooltip reads "MAU: 1.24M; +8% MoM; 30-day avg: 1.19M," giving the exact value, a comparison, and one piece of useful context in three lines, rather than a dense block listing every dimension available in the underlying dataset.

Trade-offs and pitfalls
A tooltip crammed with 10+ fields defeats its purpose (a fast, glanceable supplement) and effectively becomes an unreadable mini-report; if that much detail is genuinely needed, that's a sign the interaction should be a drill-through to a dedicated view, not a bigger tooltip.

Direct answer
Make a chart accessible by pairing every visual encoding with a non-visual equivalent: a colorblind-safe, high-contrast palette plus redundant encoding (pattern, position, or direct labels) for anyone who can't distinguish the colors, and a structured, readable alternative (a data table or text summary) plus keyboard navigation for anyone using a screen reader.

Structured elaboration

1. Choropleth map: color alone should never be the only way to read the value; add a legend with explicit numeric bins, and provide an accessible data table (region -> value) as an alternative view, since a screen reader cannot interpret map shading or a keyboard user cannot easily probe a map's regions.
2. Stacked bar chart: use a colorblind-safe categorical palette (avoiding red-green as the sole distinguishing pair) plus direct labels or hatch patterns for the segments; provide an accessible table with the same category-by-value breakdown, and ensure each bar segment is keyboard-focusable with a text description ("Region A, Channel 1: $40K").
3. Interactive network diagram: the hardest case; provide a structured textual summary of the key relationships ("Node A connects to 5 nodes, most strongly to Node B") and an accessible adjacency table, since a screen reader cannot meaningfully narrate a force-directed layout (a network-diagram arrangement where connected nodes are pulled together and unconnected ones pushed apart like magnets, so the same data can settle into a different-looking arrangement each time it's drawn).
4. General WCAG practice: verify contrast ratios (4.5:1 minimum for text, higher for small elements), ensure every interactive element (filter, tooltip trigger) is reachable and operable via keyboard alone, and validate with an automated contrast/ARIA checker (ARIA: markup attributes that tell a screen reader what an interactive element is and how to use it, e.g. that a clickable icon is actually a "button" that toggles a filter) plus a manual screen-reader pass (not automated tooling alone, since automated tools miss narrative/logical-order issues).

Worked example
For the choropleth, a colorblind-safe blue-to-orange diverging scale plus a companion sortable table ("County, % change, rank") lets a screen-reader user get the same insight (which counties changed most) that a sighted user gets from the map's darkest regions.

Trade-offs and pitfalls
Building a full accessible-table alternative for every complex chart adds real engineering and design time; prioritize it for the charts that carry a decision-relevant insight, not for purely decorative or low-stakes visuals, and treat accessibility as a release-gating checklist item rather than a stretch goal.