Manufacturing Dashboard Design Cookbook

Welcome — build dashboards that make better decisions, faster

Dashboards are useful when they connect a clear decision to accurate data, a predictable cadence, and an owner who knows what to do. This cookbook helps you design shop‑floor, shift, and executive dashboards that reduce guesswork and speed action — without becoming noisy collections of vanity metrics.

Principles (use these as your north star)

• One purpose per screen: Each dashboard exists to inform one primary set of decisions (e.g., stop the line, dispatch maintenance, plan next shift, escalate to management).
• Audience-first: Design for the role that must act now. Show what they need to know, no more.
• Exception-driven layout: Surface deviations and trends first; context and details second.
• Owned definitions: Every KPI must have a single source-of-truth definition, calculation, owner, and update cadence.
• Actionable, not pretty: Visual clarity beats visual novelty. Use craft to reduce cognitive load, not to impress.

Audience & Purpose Templates

Use these templates to decide what to include and how to arrange it.

Shift Leader (shop floor)

• Primary decision: Keep production steady; react to equipment, quality, or flow issues during a shift.
• Must-see items: current OEE (or its components), active downtime events, top 3 anomalies, live throughput vs plan, safety flags.
• Refresh cadence: near-real-time (30s–5min) for key signals; minute delays acceptable for non-critical items.

Maintenance Dispatcher

• Primary decision: Prioritize and assign maintenance work to reduce mean time to repair.
• Must-see items: queued work orders, equipment health scores, active incidents, estimated repair time, spare parts availability.
• Refresh cadence: real-time or event-driven for active incidents; hourly for backlog.

Plant Manager / Operations Manager

• Primary decision: Shift resources, approve overtime, coordinate supply or quality escalations.
• Must-see items: shift-to-date throughput, trend vs plan, major downtime incidents, scrap rate, critical supplier alerts.
• Refresh cadence: 15–60 minutes.

Executive Dashboards

• Primary decision: Strategic resource allocation and escalation decisions across sites.
• Must-see items: rolling OEE trends, on-time delivery, margins by product, major operational risks flagged by plants.
• Refresh cadence: daily or business-day aligned.

Choose the right KPI and display

A good KPI is measurable, owned, and directly tied to a decision. Prefer component metrics when they better explain issues (e.g., show Availability, Performance, Quality rather than only an aggregated OEE when troubleshooting).

• Numbers that need immediate reaction: use big numeric tiles with a single clear trend sparkline and color-coded status.
• Problem lists: show a sortable table of active exceptions (time, line, symptom, impact, owner).
• Trends and context: compact line charts showing recent behavior and a simple expected band or target.
• Root-cause links: each exception should link to the next artifact (work order, playbook, run-chart) that helps resolve it.

Color, typography, and visual rules

• Limit palette to 3–4 functional colors. Reserve bright color for exceptions and calls-to-action.
• Avoid red/green only — add shape or text cues for colorblind accessibility.
• Use consistent semantics for color across dashboards (e.g., red=needs action, amber=watch, green=ok).
• Prefer plain fonts, clear spacing, and contrast that works on the shop floor (high ambient light).
• Remove decorative elements that don't support decisions (fancy backgrounds, 3D charts).

Alerts and thresholds — make them meaningful

Too many alerts erode trust. Use thresholds tied to decisions and owners.

• Only alert when someone is expected to act within the alert window.
• Classify alerts by urgency and required response (informational, investigate, stop-line).
• Include reason codes and suggested first actions in alert details.
• Log alerts and outcomes to refine thresholds over time.

Annotation & storytelling

Use annotation to explain unusual spikes or planned events. A small, editable 'notes' area that tags timeframe and author is more valuable than an unreadable legend.

Governance and data hygiene

Governance prevents well-meaning dashboards from becoming misleading.

• Create a Metric Dictionary entry for every KPI: name, business definition, calculation SQL or formula, source tables, refresh cadence, owner, and contact.
• Enforce a review cadence for dashboard correctness (quarterly) and for relevance (every 6–12 months).
• Assign a dashboard owner who is accountable for its accuracy and the decision it supports.
• Require change requests to include the decision rationale and expected user impact.

Before / After — common problem fixed

Before: One dashboard shows dozens of metrics with no owner, many conflicting definitions, and a lot of red numbers that invite panic but don’t say what to do.

After: The screen is reorganized into a top row of three decision tiles (what's broken, what must be prioritized, what is on track), with an exceptions list and a link to the resolution playbook. Each tile has an owner and an elapsed time counter.

(Replace with a screenshot showing the ‘Before’ and ‘After’ layout — search: "manufacturing dashboard before after layout" or use the provided design mockups.)

Quick Audit — use this to evaluate any dashboard

1. Purpose: Is the primary decision the dashboard supports clearly stated? (Yes/No)
2. Audience: Is the layout tailored to a specific role? (Yes/No)
3. Ownership: Is there a named owner for the dashboard and each KPI? (Yes/No)
4. Definitions: Are KPI calculations documented and consistent? (Yes/No)
5. Actionability: For each red/amber state, is the next action explicit? (Yes/No)
6. Refresh: Does the data cadence match the decision cadence? (Yes/No)
7. Noise: Are there metrics that don’t influence decisions? (List them)

BI Handoff Checklist (use when requesting a new dashboard)

Deliver this to BI with mockups and examples. It reduces rework and avoids ambiguous assumptions.

• Purpose & Audience: One-sentence primary decision and the primary role (include name and shift/timezone if relevant).
• Top KPIs: List each KPI with target/threshold, calculation formula, source table, and example SQL or column mapping.
• Data freshness: Desired refresh cadence and tolerable latency.
• Exception logic: Rules that define exceptions and severity levels.
• Owner & escalation path: Dashboard owner, KPI owners, and escalation contacts.
• Mockup and wireframe: Annotated mockup showing placement, drill paths, and required interactions.
• Access & security: Who needs view vs edit vs export permissions.
• Acceptance tests: A short list of scenarios the dashboard must demonstrate before sign-off (e.g., show a simulated downtime event and the correct alert/owner display).
• Accessibility & device needs: Shop-floor TVs, tablets, or executive mobile access requirements.

Common mistakes to avoid

• Using aggregated metrics that hide the root cause (show components when troubleshooting).
• Over-alerting — alerts that users learn to ignore.
• No ownership or stale metric definitions.
• Mixing audiences on one screen (executive KPIs mixed with line-level details).

Next steps — how to start

1. Run the Quick Audit on your top three dashboards.
2. Pick one dashboard that fails the audit and rebuild it using the Audience & Purpose template.
3. Create Metric Dictionary entries for the top 10 KPIs across your plant.
4. Use the BI Handoff Checklist for the rebuild and insist on acceptance tests.

Image guidance

Suggested image search phrase for mockups and sample screenshots: "dashboard design manufacturing". Replace placeholder images with real before/after screenshots from your plant where possible — real examples accelerate adoption.

Handy starting KPI list (examples)

• OEE and its components: Availability, Performance, Quality
• Throughput vs Plan (units/hour)
• Active Downtime Events (count and minutes)
• First Pass Yield or Scrap %
• Work Orders Open / Mean Time To Repair
• On-time Delivery % (plant-level)

Good dashboards are living tools. Use this cookbook as a baseline, iterate with users, and treat governance as the practice that keeps dashboards reliable and trusted.