• Priorisierung nach Handlung: Drei-Zonen-Layout:
  • Zone A (Top/Links, 20–30 % Fläche): Aktionsliste und Alarme. Jeder Eintrag ist klickbar, führt direkt zu betroffenen Assets und Zeiträumen.
  • Zone B (Mitte, 40–50 %): Zustandsübersicht nach Linien, Zellen, Assets. Ampeln nur mit Erklärung, Drill-Down bis Komponente.
  • Zone C (Rechts/Unten, 20–30 %): Detail-Trends und Kontextkarte/Matrix, dynamisch, abhängig von Auswahl.
  • Zeitnavigation als Primärachse: Brush-and-Link-Interaktion über alle Charts, Marker für Ereignisse (Alarm, Schichtwechsel, Wartung). Downsampling progressiv: erst grob, dann fein, um Performance zu sichern.
  • Alarmflut-Resistenz: Gruppieren verwandter Alarme, Deduplizieren, Eskalieren nach Dauer und kritischer Folge. UI zeigt Alarm-Ursachenketten (z. B. „Druckabfall → Pumpenstörung → Linienstillstand“) statt 30 Einzelmeldungen.
  • Korrelation ohne Halluzination: Biete vorkonfigurierte Korrelationen (domänenspezifisch), nicht freie x-beliebige Kreuzungen, die Scheinkorrelationen fördern. Zeige Korrelation zusammen mit Zeitversatz und Hebelrichtung, nie nur mit r.
  • Wand vs. Tablet: Für Leitstände optimieren (hohe Dichte, Maus/Tastatur), für mobile Instandhaltung getrennte Oberflächen (große Targets, offline Cache, Kamera-Integration). Eine UI für alles endet oft in zwei unbrauchbaren UIs.
  • Transportprotokoll-bewusst: Hot-Path-Daten via WebSocket-Push, Warm/Cold per paginierter Abfrage. Heartbeat visualisieren, um Stille von Ausfall zu unterscheiden. UI darf nicht „einfrieren“, wenn der Stream stockt – Status muss explizit sein.

4) Safety-kritische Interaktionsmuster

Wenn ein Klick reale Energie bewegt, sind ein paar Grundsätze nicht verhandelbar:

  • Non-destructive Defaults: Der primäre Button ist sicher (z. B. „Prüfen“), der gefährliche steht rechts, braucht eine bewusste Geste (z. B. langes Gedrückthalten) und eine zweite Bestätigung. Timeout und Sperre nach zu vielen Fehlversuchen.
  • Modus-Sichtbarkeit: Bedienmodi (Manuell, Halbautomatik, Automatik) sind großflächig sichtbar, farblich und textlich, mit Tooltips, die den Modus erklären. „Mode Errors“ sind eine der häufigsten Unfallursachen in komplexen UIs.
  • Redundante Kodierung: Niemals nur Farbe. Immer Text und Form. Ampel-Grün im Sommerlicht ist unsichtbar – ein Dreieck mit Ausrufezeichen und „Achtung“ bleibt erkennbar.
  • Interlocks in der UI: Vor gefährlichen Aktionen führt ein Check durch sicherheitsrelevante Abhängigkeiten (z. B. „Druck < X?“, „Zone frei?“). Die UI zeigt die Sensorwerte, die den Interlock blockieren, und verweist auf das Playbook.
  • Latency-aware Design: Wenn Rückmeldungen verzögert kommen (Netzwerk, SPS-Zyklus), visualisiere „ausstehende Aktion“ mit Spinner und Countdown. Der Bediener muss wissen, ob sein Befehl „auf dem Draht“ ist oder erneut gesendet werden muss.
  • Post-Incident-Review: Jede kritische Interaktion landet mit Kontext im Audit-Log: Wer, wann, welcher Zustand, welche KI-Empfehlung, warum abgelehnt/akzeptiert, Ergebnis. UI bietet eine „Zeitreise“-Ansicht für Ursachenanalysen.

5) Accessibility in harschen Umgebungen

Industriearbeitsplätze sind selten ein stilles Büro. Barrieren sind physisch, sensorisch und kognitiv.

  • Handschuhe und Touch:
  • Zielgrößen mindestens Daumenbreite. Auf resistiven Touchscreens vermeiden: Multi-Touch-Gesten, kleine Slider, dünne Scrollbars.
  • Buttons mit klaren Zuständen (normal, hover/fokus, aktiv, gesperrt). Aktiver Zustand muss fühlbar sein: akustisch und visuell, optional haptisch über Endgerät.
  • Staub, Öl, Feuchtigkeit:
  • Hoher Kontrast, matte Themes als Default. Starke Konturkanten statt pasteller Farbflächen.
  • Eingaben mit Debounce und expliziten Bestätigungen – keine „Ghost Clicks“ bei nassem Screen.
  • Sonnenlicht/Nachtbetrieb:
  • Zwei Farbschemata (Day/Night), manuell und sensorbasiert umschaltbar. Gleiche Semantik, kein Redesign. Schriftgrößen skalierbar ohne Layout-Bruch.
  • Lärm und Gehörschutz:
  • Zusätzlich zu Tönen mit Licht und Text arbeiten. Blinkmuster dürfen nicht überreizen; nutze eindeutige, langsame Muster für Kritikalität.
  • Mehrsprachigkeit und klare Sprache:
  • Umschaltbar zur Laufzeit. Gleiche Layouts, Texte kurz, verifizierbar. Icons nur mit Labels, keine Insider-Abkürzungen.
  • Kognitive Entlastung:
  • Immer denselben Ort für dieselbe Funktion. Progressive Offenlegung: erst das Nötigste, Details auf Nachfrage. Keine 20 KPIs gleichzeitig, sondern „Top-3 Abweichungen“ mit Link auf die Langliste.

6) Governance und Datensouveränität als UX-Anforderungen

Vertrauen entsteht, wenn Bediener und Eigentümer wissen: Nichts verlässt das Werkstor unkontrolliert, und jede Entscheidung ist nachvollziehbar.

  • On-Prem LLM/Agenten: RAG und Tool-Use lokal, Wissensquellen aus internen DMS/CMMS. Das UI zeigt die Herkunft jedes Snippets. Kein externer Prompt-Versand. Policy-Checks vor Ausführung.
  • RBAC/ABAC: Rollen- und attributbasierte Sicht – wer darf was sehen und auslösen? UI zeigt, warum eine Aktion gesperrt ist („Rolle fehlt“, „Zwei-Personen-Regel aktiv“) und verweist auf Freigabewege.
  • Datenminimierung: Für Telemetrie und Trainingsdaten nur das aufbewahren, was für Betrieb, Sicherheit und Audit nötig ist. UI bietet Aufbewahrungsfristen transparent an und ermöglicht das Purgen nicht benötigter personenbezogener Felder.
  • Audits ohne Cloud: Exportierbare, signierte Entscheidungsprotokolle. Abspielbare Agenten-Traces (Prompts, Tool-Aufrufe, Ergebnisse) – hier leistet eine Plattform wie Alpi-M Governance und Observability, ohne rechtliche Grauzonen.

7) Umsetzungs-Blueprint: Von der Linie zum Interface

Ein praxistauglicher, souveräner Stack sieht oft so aus: