Dashboard Design

Dashboard Design

When to Use

Use this skill when:

• A user needs to design a new dashboard from scratch and wants a complete specification covering purpose, panels, layout, and interactivity -- not just chart type choices
• A user has a set of metrics, KPIs, or data sources and needs help organizing them into a coherent, navigable visual experience for a specific audience
• A user is preparing a dashboard for a recurring business ritual (weekly sales review, monthly executive meeting, daily ops standup) and needs the layout to match how the meeting flows
• A user is migrating or rebuilding a dashboard and wants to audit and rationalize what panels to keep, remove, or restructure
• A user is designing a multi-page or multi-tab dashboard suite (e.g., an executive overview linked to departmental detail views) and needs a logical information architecture
• A user describes a monitoring problem -- "I need to know when something goes wrong" or "leadership wants to see everything in one place" -- that implies the need for a persistent visual interface
• A user has already listed their metrics but does not know how to arrange, prioritize, or group them visually

Do NOT use when:

• The user only needs help choosing which chart type is appropriate for a single visualization -- use chart-type-selector instead
• The user needs to define which metrics to track, establish metric formulas, or set performance targets -- use kpi-definition first, then return to this skill
• The user wants to reformat, restyle, or fix an existing chart (axis labels, colors, font sizes) -- use chart-formatting
• The user wants to write a prose or slide-based narrative around data findings -- use data-storytelling
• The user is asking about database query design, ETL pipelines, or data model structure to feed a dashboard -- use the appropriate data-engineering skill
• The user wants a one-time data analysis or report, not a persistent monitoring tool -- a dashboard implies recurring use; a report implies a single delivery
• The user is asking which BI tool to buy or evaluate -- that is a tool-selection or procurement question outside this skill's scope

Process

Step 1: Establish the Dashboard's Purpose and Contract

Before specifying a single panel, lock in the purpose. A dashboard without a defined primary question will accumulate panels indefinitely.

• Identify the primary question: Ask the user to complete the sentence "This dashboard exists to answer the question: ___." If they cannot complete it, the dashboard lacks a north star. The primary question should be answerable in one glance at the top row.
• Name the audience tier: Executives consume dashboards in 60-90 seconds and need verdict, not data. Operational staff monitor dashboards continuously and need current-state accuracy. Analysts use dashboards as a launchpad for investigation and need filters and drill-down. Mixed audiences require separate sections or separate pages.
• Determine the consumption pattern: Is the dashboard displayed on a TV monitor (no interaction, wide format, large text, auto-refresh)? Viewed in a weekly meeting (projected, someone narrates it)? Opened on demand in a browser by individuals (interactive, filterable)? Each pattern affects layout width, font size, interactivity, and default state.
• Define the viewing cadence: Real-time (seconds to minutes) means operational -- data staleness is critical. Daily means business-day rhythm -- a "data as of" timestamp matters. Weekly or monthly means trend-focused -- period comparisons dominate. This cadence governs which metrics belong and at what granularity.
• Identify the decision or action the dashboard enables: If viewing the dashboard cannot change anyone's behavior, it should not be built. Every panel should trace to at least one decision: escalate, investigate, approve, alert, reallocate.
• Confirm the data availability: Each metric the user wants must exist as a queryable, joinable field somewhere. If the user lists a metric whose data does not exist or requires manual entry, flag it immediately and note it as a future panel or a data gap.

Step 2: Classify the Dashboard Type and Set Panel Constraints

Choose one of three archetypes -- or a hybrid -- and enforce the panel limit that comes with it.

• Strategic / Executive dashboard: 4-8 panels maximum. Primary chart types: KPI scorecards, trend sparklines, bullet charts. No raw data tables. No micro-level detail. Color coding indicates status (on track / at risk / off track). Viewed by decision-makers who need a verdict, not a data dump. The entire screen should convey performance posture in under 90 seconds.
• Operational / Monitoring dashboard: 6-12 panels. Real-time or near-real-time data. Includes alert indicators, threshold lines, and status badges. May include tables with row-level detail for specific entities (agents, machines, orders). Designed to be scanned repeatedly throughout a shift or workday. Often displayed on a shared screen or TV.
• Analytical / Diagnostic dashboard: 8-14 panels with filter controls, drill-down paths, and detail tables. Audience is analysts or power users who investigate anomalies. Accepts more visual complexity because users spend time with it. Must include prominent filter controls -- without them, analysts will not trust what they see.
• Hybrid: A strategic top section (3-4 KPI scorecards filling the first viewport) with an analytical lower section (filterable charts below the fold). Use a visual separator between sections. Label the sections explicitly ("Executive Summary" / "Detail View").
• Hard limits by type: Strategic: 8 panels maximum. Operational: 12 panels maximum. Analytical: 14 panels maximum. Any dashboard exceeding these limits must be split across pages or tabs. A single page beyond 14 panels is indefensible -- research on dashboard cognition shows users stop processing new information after roughly 7-9 visual elements in a single session.

Step 3: Define Every Panel Using the Five-Question Test

For each panel the user wants to include, apply this test before specifying it:

1. What question does this panel answer? State it as a specific question (e.g., "Is our 7-day rolling win rate above the 25% floor?"). If the answer is vague ("it shows sales data"), reject the panel or reframe it.
2. Who needs this answer? If the audience is an executive dashboard but the question only matters to a sales analyst, the panel belongs on the analytical dashboard, not this one.
3. What is the right chart type for this question? Apply the standard logic: comparison across categories = bar chart (horizontal for many categories, vertical for few); change over time = line chart (continuous data) or bar chart (discrete periods); part-to-whole = stacked bar or donut (donut only for 2-5 segments); distribution = histogram or box plot; correlation = scatter plot; current value vs. target = bullet chart or gauge. Do not use pie charts for more than 5 segments. Do not use 3D charts. Do not use gauges unless the audience is operational and the single-value status read is genuinely needed.
4. What is the comparison? Every panel must show the metric in context: versus target, versus prior period, versus benchmark, versus threshold, or versus another entity. A number in isolation is meaningless -- context is mandatory.
5. How often does this data update? Determine the refresh cadence per panel. If panels on the same dashboard have different refresh rates, group them visually and label their data freshness.

For each confirmed panel, specify:

• Panel title (states what it shows, not what it is called internally)
• Chart type and why
• Primary metric and its definition (including any filters, conditions, or calculation notes)
• Comparison baseline
• Data source (table name, query, or API endpoint -- be specific)
• Update frequency
• Status thresholds (green / yellow / red) if it is a KPI scorecard or monitoring panel

Step 4: Design the Layout Grid

Use a 12-column grid. Every panel occupies a whole number of columns. Every row must add up to exactly 12 columns. Height is specified in units relative to one another (e.g., scorecards are 1 unit tall, trend charts are 2 units tall, large tables are 3 units tall).

Layout hierarchy rules:

• Top row (the verdict row): The first row must answer the primary question at a glance. Use 2-4 large KPI scorecards spanning the full width. If the primary question requires a trend (not just a current value), use a full-width or 2/3-width line chart here instead.
• Second row (context row): Supporting charts that explain the top-row verdict. Typically 2-3 equal panels (4 columns each). These are the "why is the top number what it is?" charts.
• Third row and below (diagnostic rows): Detail panels, breakdowns by segment or entity, tables, distribution charts. These require scrolling on most screens and serve analysts or operators who drill in.
• Sidebar layout (for analytical dashboards): Reserve columns 1-2 of every row for a filter panel when the dashboard is heavily filtered. Panels then occupy columns 3-12. Never use a sidebar for strategic dashboards -- it wastes valuable space.
• Width guidance by chart type: KPI scorecard: 2-4 columns. Line/bar trend chart: 6-12 columns (needs horizontal space to show trend). Table with multiple columns: 8-12 columns. Donut chart: 3-4 columns. Scatter plot: 6-8 columns. Geographic map: 6-12 columns.
• The fold: Assume the primary viewport shows the top 600-700px of the dashboard. The most critical information must live above the fold. Anything requiring scroll is secondary.
• Whitespace: Each row should have at least one panel that is noticeably wider or taller than the others -- this creates visual hierarchy and directs the eye. A grid where every panel is the same size is visually flat and harder to scan.

Step 5: Specify Filters and Interactivity

Filters are not cosmetic -- they define the analytical surface area of the dashboard. Under-filtered dashboards show averages that obscure problems. Over-filtered dashboards paralyze users with options.

• Global filters: Apply to all panels simultaneously. Mandatory filters for almost every dashboard: date range (with sensible default -- last 30 days for operational, current quarter for strategic), primary segmentation dimension (region, product line, business unit). Expose as dropdown selectors or date pickers at the top of the dashboard, above all panels.
• Local filters: Apply to one panel only. Use sparingly -- only when a panel genuinely needs a different slice than the global context (e.g., a competitive benchmark panel that should not change when the user filters to a single region).
• Default filter state: Define the default for every filter. The default state is the dashboard's "opening argument" -- what it says before the user touches anything. Align the default to the most common use case: for a quarterly review dashboard, default to current quarter. For a daily ops dashboard, default to today.
• Drill-down paths: Specify which panels support click-through. A drill-down click should navigate to a detail view (another dashboard page, a filtered table, or a linked report) -- not simply zoom. Document the destination: "clicking a bar in Rep Performance navigates to Rep Detail page filtered to that rep."
• Cross-filtering: When a user clicks a data point in one panel and it filters all other panels, this is cross-filtering. It is powerful but disorienting if not communicated clearly. Only recommend cross-filtering for analytical dashboards where users understand filter context. Always show a visible "clear filter" control.
• Tooltips: Every chart should show a tooltip on hover that includes: the precise metric value (with full number format, not abbreviated), the comparison value, and the % difference from comparison. Do not show raw field names in tooltips -- show human-readable labels.
• No-interaction mode: For TV dashboards or projected dashboards, disable all interactivity. Set a 5-minute auto-refresh. Use large fonts (minimum 16pt labels, 36pt metric values). Remove filter controls entirely -- they confuse stakeholders and imply the view is not authoritative.

Step 6: Define Visual Standards

Visual standards must be defined at the dashboard level, not panel by panel. Inconsistent visual standards are the most common reason dashboards look amateurish.

• Color palette: Maximum 5 functional colors plus gray. Assign semantic meaning: one color for the primary metric (neutral, no judgment -- typically navy or slate blue), one for positive deviation (green family: #27AE60 or similar), one for negative deviation (red family: #E74C3C or similar), one for warning/caution (amber: #F39C12), one for a secondary metric or comparison line (lighter or muted version of primary). Gray (#95A5A6 or #BDC3C7) for grid lines, axis labels, and non-critical annotations. Do not use color simply to differentiate categories if there are more than 5-6 -- use position or labels instead.
• Typography: Use two font sizes: large (28-36pt) for scorecard metric values, medium (12-14pt bold) for panel titles, small (10-11pt) for axis labels and data labels. Metric values should be in a bold, tabular-numeral font so digits align in columns. Avoid decorative fonts entirely.
• Number formatting: Define a standard and apply it everywhere. Currency: use $X,XXX for values above $1,000, $X.XM for values above $1,000,000. Percentages: always one decimal (XX.X%). Large counts: use K suffix above 10,000, M suffix above 1,000,000. Date formats: spell out month abbreviations (Jan, Feb) rather than numeric month formats to avoid regional ambiguity.
• Status thresholds: Define all green / yellow / red thresholds before building. Thresholds should be derived from business logic, not arbitrary split points. For revenue attainment: green >= 90% of prorated target, yellow 70-89%, red < 70% is a common starting point -- but confirm with the business owner, who may have different risk tolerance. Document the threshold rationale in the specification so it can be revisited.
• Grid lines and borders: Use light gray grid lines (#ECEFF1) at minimum opacity. Do not use heavy borders around panels -- this fragments the visual space. Use whitespace as the separator between panels, not lines or boxes.
• Annotations: Any panel that shows a historical anomaly (a spike or drop that will trigger questions) should have a pre-placed annotation explaining it (e.g., "Holiday week" or "System outage"). Dashboards reviewed in meetings without annotations cause the presenter to spend the first five minutes explaining the same anomalies every time.

Step 7: Write the Dashboard Specification Document

Produce the complete specification in the output format defined below. The specification must be self-contained -- a developer, analyst, or BI engineer who receives only this document should be able to build the dashboard without additional clarification.

• State the layout grid as an ASCII diagram showing every row and column assignment
• Define every panel with all five specification fields: question answered, chart type, data source, comparison, and thresholds
• List every filter with its type, scope, and default
• State the visual standard table
• Flag any data gaps or assumptions -- panels that rely on data that has not been confirmed as available should be marked with [DATA UNCONFIRMED] so the builder knows to validate before implementing
• Note the planned page/tab structure if the dashboard has multiple pages
• Include a "Questions this dashboard does NOT answer" section if the user listed metrics that were excluded -- this prevents scope creep during build

Output Format

## Dashboard Specification

### Summary

| Element | Value |
|---------|-------|
| Dashboard name | [Name] |
| Version | v1.0 |
| Audience | [Who views this -- be specific about role] |
| Consumption pattern | [Projected / TV monitor / Individual browser / Mobile] |
| Primary question | [The single question answered at a glance by Row 1] |
| Dashboard type | [Strategic / Operational / Analytical / Hybrid] |
| Total panels | [N] |
| Page count | [N pages or 1 page] |
| Data refresh | [Real-time / Hourly / Daily at Xam / Weekly] |
| Default filter state | [e.g., Current quarter, All regions] |

---

### Questions This Dashboard Answers

| Priority | Question | Panel(s) That Answer It |
|----------|----------|------------------------|
| Primary | [Most important question] | [Panel name(s)] |
| Secondary | [Second question] | [Panel name(s)] |
| Secondary | [Third question] | [Panel name(s)] |
| Supporting | [Fourth question] | [Panel name(s)] |
| Supporting | [Fifth question] | [Panel name(s)] |

### Questions This Dashboard Does NOT Answer
(Explicitly excluded scope -- prevents scope creep during build)
- [Metric or question excluded, and why or where it belongs instead]

---

### Panel Specifications

#### Panel [N]: [Descriptive Title]

| Element | Value |
|---------|-------|
| Primary question answered | [Specific question this panel answers] |
| Position | Row [N], Columns [N]-[N] of 12 |
| Height units | [1 = scorecard / 2 = standard chart / 3 = large chart or table] |
| Chart type | [Specific type with justification: e.g., "Horizontal bar -- comparing named categories"] |
| Primary metric | [Metric name: definition including any filters or conditions] |
| Secondary metric / comparison | [Metric name: what it is compared against] |
| Data source | [Table or view name, query summary, or API endpoint] |
| Aggregation | [Sum / Count / Average / Median / etc. and the grain] |
| Update frequency | [Real-time / Hourly / Daily / Weekly] |
| Status thresholds | Green: [condition] / Yellow: [condition] / Red: [condition] |
| Interactivity | [None / Drill-down to X / Cross-filter / Tooltip: fields shown] |
| Data confirmed | [Yes / No -- DATA UNCONFIRMED] |
| Notes | [Any caveats, calculation complexity, or display guidance] |

(Repeat for each panel)

---

### Layout Grid

Page: [Page name]

     Col 1-2   Col 3-4   Col 5-6   Col 7-8   Col 9-10  Col 11-12

Row 1: [Panel name spanning cols 1-8 ] [Panel 2 (9-12) ] Row 2: [Panel 3 (1-4) ] [Panel 4 (5-8) ] [Panel 5 (9-12) ] Row 3: [Panel 6 (1-6) ] [Panel 7 (7-12) ] Row 4: [Panel 8 spanning full width (1-12) ]

Height map:
- Row 1: 1.5 units (scorecard height)
- Row 2: 2 units (standard chart height)
- Row 3: 2.5 units (detail chart height)
- Row 4: 3 units (table height)

Fold line: Above Row [N] is visible without scrolling on a 1080p display

---

### Filters and Interactivity

| Filter Name | Type | Scope | Default Value | Options |
|-------------|------|-------|---------------|---------|
| Date range | Date range picker | Global | [Default period] | [Available options] |
| [Dimension 1] | Dropdown (single) | Global | All | [Values or "All values in dim"] |
| [Dimension 2] | Dropdown (multi) | Global | All | [Values] |
| [Local filter] | Dropdown | Panel [N] only | [Default] | [Values] |

Drill-down paths:
- [Panel name] → clicking [element] navigates to [destination page/view] filtered by [filter applied]

Cross-filtering:
- [Enabled / Disabled]. If enabled: clicking [panel name] filters [list of affected panels].

Auto-refresh: [Enabled at X-minute interval / Disabled]

---

### Visual Standards

| Element | Standard |
|---------|----------|
| Primary metric color | [Hex code] -- used for main data series |
| Positive / above target | [Hex code, green family] |
| Negative / below target | [Hex code, red family] |
| Warning / approaching threshold | [Hex code, amber family] |
| Comparison / secondary series | [Hex code, muted or lighter] |
| Neutral / non-data elements | [Hex code, gray] |
| Dashboard background | [Hex code -- white #FFFFFF or near-white #F8F9FA] |
| Panel background | [Hex code -- white or very light gray] |
| Grid lines | [Hex code -- #ECEFF1, minimum opacity] |
| Primary font (titles) | [Font name, size, weight: e.g., Inter 14pt Bold] |
| Metric value font (scorecards) | [Font name, size, weight: e.g., Inter 32pt Bold] |
| Axis / label font | [Font name, size, weight: e.g., Inter 10pt Regular] |
| Currency format | [e.g., $X,XXX no decimals; $X.XM for millions] |
| Percentage format | [e.g., XX.X% always one decimal] |
| Large number format | [e.g., X.XK above 10K; X.XM above 1M] |
| Date format | [e.g., MMM DD or Q1 FY25 -- never MM/DD/YYYY] |

---

### Data Gaps and Assumptions

| Item | Status | Resolution Required |
|------|--------|-------------------|
| [Metric or field] | Confirmed / Unconfirmed | [What needs to be verified] |
| [Calculation assumption] | Assumed | [Confirm with business owner] |

---

### Build Notes

- [Any sequencing note: "Build Panel 1 and 2 first for executive review before building rows 3-4"]
- [Any dependency: "Pipeline by Stage requires Stage field to be standardized -- confirm with data team"]
- [Any phasing: "Phase 1 includes Panels 1-5; Phase 2 adds Panels 6-8 after data pipeline is confirmed"]

Rules

1. NEVER build a dashboard without a stated primary question. If the user says "I want to see everything about sales," push back immediately. Ask "What is the single question a viewer should be able to answer in 10 seconds by looking at this dashboard?" Everything else is secondary. A dashboard without a primary question becomes a data dump that no one trusts.

2. NEVER exceed 12 panels on a single page for a strategic or operational dashboard, and 14 for analytical. Cognitive load research consistently shows diminishing returns beyond 7-9 visual elements in a single session. When a user insists on 20 panels, do not comply -- restructure into pages or tabs with a clear navigation hierarchy. The top page should always be the overview.

3. ALWAYS put the primary question's answer in the top-left or top-center position. Eye-tracking studies of dashboard usage show an F-pattern and Z-pattern reading behavior -- the top-left is processed first, every time. The most important KPI scorecard or headline chart belongs there. Placing the logo or a decorative chart in that position wastes the highest-value real estate on the screen.

4. EVERY panel must have a comparison value -- no exceptions. A revenue number of $1.2M is meaningless without knowing whether the target was $1.0M (great) or $2.0M (bad). Every KPI scorecard must show: current value, comparison value, and the delta expressed as both absolute and percentage. "%" alone is ambiguous -- "$200K below target (-14.3%)" is not.

5. Status thresholds (red/yellow/green) must be defined from business logic, not split evenly. A common mistake is to set thresholds at 0-50% red, 50-80% yellow, 80-100% green. These are arbitrary. The correct thresholds come from the business: what level of attainment triggers an escalation? What level is acceptable but warrants attention? Confirm thresholds with a business owner and document the rationale. The specific numbers matter because they will be used in automated alerts.

6. NEVER use a pie chart for more than 4 segments, and never use 3D chart types. Pie charts with 5+ segments are unreadable -- use a horizontal bar chart sorted descending instead. 3D charts distort perception of magnitude and have no legitimate use case in a data dashboard. Gauges are acceptable only on operational dashboards where the audience is specifically trained to read them.

7. Date range filters must default to the most relevant period for the audience, not "all time." An executive reviewing a quarterly dashboard should see the current quarter by default. An operator monitoring a call center should see today by default. "All time" as a default forces users to constantly re-filter and makes trend charts unreadable. Define the default date range as part of the specification and confirm it with the user.

8. Group panels by update frequency when multiple frequencies exist. Never place a real-time panel next to a monthly-aggregate panel without clearly labeling each one's data freshness. Use section headers and "Last updated: [timestamp]" labels. Mixed refresh rates without labeling cause stakeholders to question data accuracy across all panels, not just the stale one.

9. Use sorted layouts in bar charts by default. A bar chart showing 15 sales reps in alphabetical order is almost useless -- it requires the viewer to search, not scan. Always specify "sorted by [metric] descending" or "sorted by [metric] ascending" in the panel specification. The only exception is when the order itself is meaningful (e.g., pipeline stages in funnel order, months in chronological order).

10. Dashboard specifications must include a "Questions Not Answered" section. When working with a user, they will inevitably propose panels that do not belong on this dashboard. These must be documented explicitly as out-of-scope. If they are not documented, they will be re-requested during the build review as "missing" items. Capturing them as excluded scope with a reason ("Sales rep compensation data -- belongs on HR dashboard, not sales performance") prevents scope creep and documents the deliberate decision.

11. A data table is a panel of last resort, not a default. Users often request a "data table showing all the transactions" as a dashboard panel. A table showing 200 rows with 12 columns provides no at-a-glance insight. If a table is genuinely needed, limit it to a maximum of 10 rows (the top N ranked entities) and 5-6 columns showing only the critical fields. Add a "View full report" link for users who need all rows.

12. Mobile layout is a separate specification, not a subset of the desktop layout. If the dashboard will be viewed on mobile devices, a 12-column grid collapses to a single-column stack. The mobile specification must re-prioritize panels: only the top 4-5 most critical panels survive on mobile; the rest require a "full view" tap. Never assume the desktop layout translates automatically -- specify the mobile panel order explicitly.

Edge Cases

User has only 2-3 metrics to display: Do not pad the dashboard with unnecessary panels to fill the screen. Design a single-row layout with 2-3 large KPI scorecards using full-height display. Each scorecard should show: the metric value in large type, a sparkline of the last 12-13 periods, comparison to target and to prior period, and status color. The entire dashboard is one row. Use a subtitle or page header to convey context. A clean three-panel dashboard with full data context communicates more than a cluttered eight-panel dashboard with half the context per panel.

User wants both real-time and historical data on the same dashboard: Separate them into two named sections with a visible section divider and distinct "data freshness" labels. Top section: "Live Operations" -- real-time panels, auto-refreshing every 1-5 minutes, timestamps visible on each panel. Bottom section: "Historical Context" -- daily or monthly aggregate panels, stamped with "Data as of [date]." Never allow a real-time panel to sit next to a monthly aggregate without the divider -- viewers conflate the time horizons and draw incorrect conclusions. Consider using a subtle background color difference between sections.

Audience is genuinely mixed (C-suite and analysts using the same URL): Design a layered architecture, not a compromise layout. The first screen (above the fold) is the executive section: 3-4 KPI scorecards only, no labels below 14pt, no filters visible. Below the fold begins the analytical section with filters, detail charts, and tables. Alternatively, use a tabbed structure: Tab 1 labeled "Overview" (executive-appropriate, no filters, no interactivity), Tab 2 labeled "Details" (filter panel, drill-down charts, tables). The tabs share the same underlying data and filter state -- switching from Detail back to Overview should reflect any filters applied.

User needs to track more than 15 distinct metrics: This is a dashboard architecture problem, not a layout problem. A single page cannot effectively present 15+ metrics. The correct response is to design a dashboard suite: one overview page (4-6 headline KPIs, navigation to sub-pages) plus 2-4 focused sub-pages (one per functional domain: Sales, Marketing, Product, Operations). Each sub-page has 6-10 panels. The overview page is the entry point and navigation hub. Design the overview page first, confirm it with the user, then design each sub-page. All sub-pages should share a consistent layout template so navigation feels coherent.

Data updates at different frequencies across panels (mix of real-time, daily, and weekly): Never mix refresh rates silently. Three strategies: (1) Group by frequency -- dedicate page sections to each frequency with clear labels and dividers. (2) Display individual panel timestamps -- each panel shows "Last updated: 2 min ago" or "Data as of: Jan 14, 9:00am." (3) Throttle everything to the slowest frequency and state it prominently -- acceptable only for strategic dashboards where operational accuracy is not needed. Option 2 is recommended for analytical dashboards. Option 3 is appropriate for executive or strategic dashboards where the audience does not need sub-daily precision.

User describes a dashboard for a TV monitor or ambient display (no interaction): Apply TV mode specifications: minimum 24pt font for all labels, minimum 48pt for metric values, no filter controls, no hover tooltips, no drill-down links, auto-refresh every 3-5 minutes. Use the full screen width without sidebars. Limit to 6-8 panels maximum -- smaller text on a wall-mounted screen at viewing distance of 3-4 meters becomes unreadable. Prefer bold, high-contrast color pairs (dark background with bright metric values, or white background with dark heavy text). Auto-rotation between pages is acceptable if multiple topics must be covered -- set rotation intervals of 20-30 seconds per page.

User wants to add a geographic map panel: Maps are appropriate only when geography is the analytical dimension (comparing performance by state, region, or territory). Maps are inappropriate when the data happens to have a location field but the question is not geographic (e.g., using a country dot map to show customer count when a ranked bar chart would be faster to read). If a map is warranted, specify: the geographic grain (country, state/province, ZIP code, custom territory), the metric encoded as the map dimension (fill color, bubble size, or choropleth gradient), the color scale and its midpoint, and what clicking a geography does (filters the other panels, or navigates to a territory detail page). Choropleth maps require a diverging color scale centered at the target or average -- not a sequential scale starting at zero, which distorts perception for metrics where the interesting range is near the midpoint.

User's dashboard has been "designed" already but is not working -- a rebuild request: Before redesigning, conduct a brief audit of the existing dashboard. Ask: (1) Which panels are actually used? (2) Which questions cannot be answered? (3) What filters are used versus ignored? (4) What data is wrong or stale? Do not simply replicate the existing layout with better formatting -- the existing layout is likely the problem. Use the audit findings to justify removing panels (typically 30-40% of panels on legacy dashboards are vestigial), consolidating redundant charts, and restructuring the layout hierarchy. Document what was removed and why in the "Questions Not Answered" section of the new specification.

Example

Input: "I need a dashboard for our e-commerce operations team. They monitor the business every day and need to see order volume, revenue, site traffic, conversion rate, average order value, fulfillment performance (on-time ship rate, average ship time), and customer service load (open tickets, first response time). About 8-10 people will use this daily, mostly operations managers and one VP who checks it every morning. We have Shopify for orders, Google Analytics for traffic, and a custom fulfillment database."

Output:

Dashboard Specification

Summary

Questions This Dashboard Answers

Questions This Dashboard Does NOT Answer

• Returns and refund rate -- excluded from v1.0; belongs on Finance dashboard; requires returns data not yet available in Shopify integration
• Inventory levels and stockouts -- excluded; belongs on Inventory Management dashboard with separate warehouse data feed
• Marketing channel attribution -- excluded; GA source/medium breakdown is a Marketing dashboard concern, not daily ops
• Customer-level order detail -- row-level order data is too granular for this dashboard; link to Shopify admin for order lookup

Panel Specifications

Panel 1: Daily Revenue vs. Target

Panel 2: Orders Today vs. Target

Panel 3: Average Order Value (AOV)

Panel 4: Site Traffic and Conversion Rate

Panel 5: Hourly Revenue Trend (Today vs. SDLY)

…(truncated)