HMI & Operator UI Wireframe Pack

Purpose

This wireframe pack provides practical, production-ready UI patterns for operator HMIs and related displays. The goal is speed, clarity, and safe action at the point of work: show only the information people need, make the next action obvious, reduce ambiguity under stress, and support fast acknowledgement, escalation, and cross‑shift handoff.

What’s included

• Compact active‑job screen — a dense, glanceable dashboard that prioritizes job status, current step, elapsed time, and immediate exceptions.
• Alert modal with required acknowledgment — interrupting modal pattern with clear title, severity, action choices, required acknowledgement, and automatic escalation path if not acknowledged.
• Stepwise digital work instruction sample — sequential steps with required confirmations, embedded media, and 'I'm stuck' escalation options.
• Responsive mobile layout notes — design adaptations and interaction differences for maintenance or supervisor mobile workflows with accessibility considerations.
• Component guidelines — typography, spacing, color semantics, iconography, and state rules intended for rapid implementation and consistent behavior across screens.
• Implementation & testing checklist — concrete acceptance criteria for development, QA, and user testing on the shop floor.

Annotated wireframe summaries

Compact active‑job screen — goals & layout

Goal: minimize scanning time and make the next operator action obvious.

• Primary band (top): job identifier, part number, customer priority badge, current status chip (color coded), and elapsed cycle/time-to-go.
• Main area: current step title, short instruction line, required tools/fixtures icons, and a large primary action button (e.g., "Start Step", "Next").
• Left column (small): small OEE widget (Availability/Performance/Quality), last event (e.g., "tool change"), and active alerts count.
• Right column (small): operator name, shift, quick links: 'Escalate', 'Request Maintenance', 'View Last 3 Logs'.
• Footer: readout of cycle time target vs actual and a clear escalation indicator if thresholds are exceeded.

Alert modal with required acknowledgment — behavior model

Goal: ensure critical events are noticed, acknowledged, and routed correctly without blocking essential information permanently.

• Modal content: severity icon (red/yellow/blue), short problem statement (1 line), suggested immediate action, consequences if ignored, and two buttons: 'Acknowledge' (required) and 'Escalate/Call'.
• Required acknowledgement path: selecting 'Acknowledge' opens a tiny reason selector (predefined reasons + 'other') and records operator ID and timestamp.
• Timeout/escalation: if modal not acknowledged within configured window, automatically send an Andon message to supervision and optionally flash a plant‑level display.
• Non‑blocking history: allow the operator to re-open a summary of recent alerts from the active-job screen so actions are traceable for handoff.

Stepwise digital work instruction — safety & verification

Goal: integrate standard work with short confirmations to improve first-pass yield and make deviations auditable.

• Each step: short instruction header, one-line rationale (when helpful), image or video thumbnail, completion checkbox, and optional 'measurement' input (numeric or pass/fail).
• Mandatory verification: for safety or quality critical steps, require a two‑tap confirmation and an optional photo upload for audit trail.
• 'I'm stuck' flow: single tap opens a pre-filled maintenance request with context (job/step/time) and offers 'call', 'text', or 'assign ticket'.
• Handoff summary: 'End of shift' action generates a brief summary of incomplete steps, open alerts, and notes for the incoming operator.

Responsive & mobile notes

Mobile views prioritize single-column vertical stacks, large touch targets, and short input flows for maintenance staff or supervisors:

• Use collapsible sections for job context to keep the main button visible.
• Prominent 'Escalate' floating action button on maintenance views; avoid full-screen blocking modals on phones.
• Offline-first: cache last-known job and allow queued submissions for areas with poor connectivity.

Component & visual guidelines

• Typography: 18–22px for primary action text on touch screens; 14–16px for secondary labels on HMI panels.
• Contrast and color: reserve saturated red for safety/stop, amber for cautions, green only for verified 'ok' states. Maintain WCAG AA contrast ratios.
• Icons: use simple pictograms with text labels; do not rely on color alone to communicate severity.
• Touch targets: minimum 44×44px; spacing consistent with production touchscreens.
• Animation: use brief (150–250ms) transition for state changes; avoid motion that distracts during high workload.

Integration & data requirements (developer notes)

Provide these data fields from upstream systems or MES for each screen:

• jobId, partNumber, stepId, stepTitle
• operatorId, shiftId, stationId
• cycleTimeTarget, cycleTimeActual, OEE components
• activeAlerts[], alertSeverity, alertTimestamp, alertActionRequired
• workInstruction media links (image/video) and required verification flags

Events to emit:

• acknowledgeAlert {alertId, operatorId, reasonCode, timestamp}
• stepComplete {jobId, stepId, operatorId, measurements, attachments}
• escalation {jobId, alertId, escalationLevel, notifiedRoles}

Accessibility & safety checklist

• Screen reader labels for all controls and dynamic alerts.
• High contrast and color‑independent indicators (icons, text).
• Consistent keyboard navigation and external input support (for panel keyboards or assistive devices).
• Large, well‑spaced touch targets for gloves.
• Audible acknowledgement cues for required confirmations with adjustable volume and mute option for sensitive areas.

Implementation & testing checklist

1. UX review with at‑least one operator, one lead, and one maintenance technician using a clickable prototype.
2. Verify alert acknowledgement captures operator, reason, and timestamp and triggers configured escalation after timeout.
3. Confirm required verification steps prevent advancing without explicit confirmation and that overrides are auditable.
4. Test on actual hardware (panel and mobile) with gloves and realistic lighting conditions.
5. Run accessibility checks (screen reader, contrast, keyboard navigation) and gather operator feedback.
6. Integrate event payloads with MES/logging and confirm end‑to‑end logging and traceability.

How to adapt this pack for your plant

Start with the compact active‑job screen and the alert modal. Customize the reason codes, escalation windows, and required verification steps to match your risk profile and quality gates. Keep the visual language stable across screens so operators build reliable expectations.

Deliverables & recommended assets

• Exportable Figma/Sketch wireframes (recommended): screens + component library.
• Annotated JSON for each screen listing required data fields and events.
• Prototype builds for panel (1024×768 or target HMI resolution) and mobile (iOS/Android sizes).

Next steps

Use the implementation checklist for an initial pilot on one line, iterate with operators for two weeks, then scale the refined templates across similar stations. Collect usage and incident data to validate whether UI changes reduce acknowledge time, escalation frequency, or error rates.