UX für industrielle Entscheidungssysteme: Wenn Interaktion über Sicherheit entscheidet

In der Industrie wird UX nicht an Conversion Rates gemessen, sondern an Sekunden, Fehlhandlungen und Sicherheitsmargen. Bediener treffen Entscheidungen unter Zeitdruck, häufig bei mangelhafter Datenqualität, eingeschränkter Sicht und mit Handschuhen. In dieser Realität ist „schön“ zweitrangig – „robust, klar und fehlertolerant“ ist das Ziel. Dieser Beitrag skizziert, wie man Interfaces für komplexe, KI-gestützte Systeme so entwirft, dass sie im Ernstfall tragen. Er verbindet Gestaltung mit technischen Randbedingungen und konkreten Architekturmustern aus Projekten in Fertigung, Bahn, Verteidigung und Luftfahrt.

1) Systemische Randbedingungen, die das UI bestimmen

Bevor wir über Layouts sprechen, klären wir die harten Constraints. Viele UI-Fehler entstehen, weil diese Randbedingungen ignoriert werden:

  • Latenz und Determinismus: Entscheidungen erfordern Feedback in <100 ms für Steuerhandlungen und <500 ms für Situationsüberblick. Cloud-Roundtrips sind hier untragbar. On-Prem- und Edge-Architekturen sind keine Ideologie, sondern eine Latenz- und Verfügbarkeitsanforderung.
  • Datenqualität und -frische: Zeitreihen sind unvollständig, asynchron, haben Ausreißer. UI muss Freshness (z. B. „Sensor A: 12 s alt“), Konfidenz und Ersatzwerte sichtbar machen – sonst werden falsche Situationen „sauber“ visualisiert.
  • Netzwerkrealität: Verbindungen sind jitterbehaftet, intermittierend (Tunnel, Rangierbetrieb, Feldbus-Gateways). Offline-first und Store-and-Forward sind UX-Themen, keine reinen Backend-Details.
  • Umgebungsbedingungen: Sonnenlicht, Staub, Vibration, 85–100 dBA Lärm, Handschuhe, IP65-Fronten. Touch-Targets, Kontrast, Rückmeldungsformen und Bedienabläufe müssen darauf optimiert werden.
  • Regulatorik und Sicherheit: In sicherheitskritischen Domänen bestimmen Normen die Interaktion (z. B. IEC 61508 Functional Safety, EEMUA 191/ISA 18.2 Alarmmanagement, ISO 9241 Ergonomie). UI-Entscheidungen sind Teil des Sicherheitsnachweises.
  • Souveränität und Datenschutz: DSGVO, ITAR/BAFA, Betriebsgeheimnisse. Modelle, Logs, Prompts und Entscheidungsverläufe dürfen das Werksnetz nicht verlassen. Das beeinflusst sowohl Architektur (On-Prem-LLM-Serving) als auch UI (Transparenz über Datenwege, Modellstände).

2) Alarm- und Entscheidungsinteraktion: Von der Signalisierung zum Handeln

Alarmphilosophie ist UX. Wer hier patzt, erzeugt Alarmmüdigkeit oder Fehlhandlungen.

Kernprinzipien:

  • Status-at-a-glance: In <3 Sekunden erkennen, ob Eingriff nötig ist. Das gelingt mit
  • begrenzter Farbpalette und harter Semantik (z. B. Grau = normal, Gelb = Achtung, Rot = sofortiger Handlungsbedarf)
  • konsistenten Formen (Dreieck Warnung, Kreis Info), damit Farbenblindheit nicht zum Problem wird
  • klarer Topologievisualisierung (Anlagenkarte, Flussdiagramm) statt isolierter Widgets.
  • Alarmpriorisierung nach EEMUA/ISA: Nicht jeder Grenzwert ist ein Alarm. UI muss anzeigen:
  • „Suppressed by design“, „Out of service“, „Shelved (bis 14:30)“, inklusive Begründung und Ablauf einer Shelving-Zeit.
  • Hysterese/Deadband, um Chattering zu vermeiden; im UI erkennbar (z. B. sparklines mit Band).
  • Handlungssicherheit:
  • Zwei-Schritt-Bestätigung für gefährliche Aktionen (Doppeltippen + Halten, nicht nur „OK“).
  • Dual Control/Vier-Augen für irreversible Operationen (Konfiguration, Freigaben).
  • „Dry run“-Vorschau: Was ändert sich wo? Welche Signale sind betroffen?
  • Eskalationslogik: Wenn eine Eingriffsfrist ausläuft, ändert sich nicht nur die Farbe – die Interaktion ändert sich (z. B. Handlungsbutton prominent, weniger sekundäre Aktionen, starke haptische/akustische Signale).
  • Auditierbarkeit: Jede Handlung ist signiert, nachvollziehbar, mit Ursache, Kontext und Modellversionen verknüpft. Tamper-evident Logs (z. B. Merkle-Hash-Ketten) sind in sicherheitsnahen Bereichen empfehlenswert.

3) Dashboards für industrielle IoT-Daten: Aus Rauschen Signal machen

Das Standardproblem: 50+ KPIs, 2000 Sensoren, 5 Aktualisierungen pro Sekunde – und der Bediener sieht nichts. Designen Sie für Sinnesökonomie.

  • Ebenenmodell:
  • Ebene 0: Anlagenzustand (grün/gelb/rot) und Kapazitätsspielräume.
  • Ebene 1: Ursache-Wirkung-Zusammenhänge (z. B. Pfad vom anomalen Motor über Temperaturanstieg zur Produktqualitätsabweichung).
  • Ebene 2: Diagnose-Details (Zeitreihen, Ereignislisten, Modelldiagnostik).
  • Ebene 3: Wartung/Engineering (Parametrierung, Historienanalysen).
  • Zeitreihen, richtig:
  • Downsampling mit Erhalt von Extrema (z. B. LTTB – Largest Triangle Three Buckets) plus Min/Max-Bänder; niemals Mittelwerte „glätten“, die Spitzen verschlucken.
  • Zeitliche Bezugssysteme: absolute Zeit, relative Zeit (seit Schichtbeginn), Takt-/Los-ID.
  • Anomaliekontext inline (Batch-IDs, Rezepturen, Umgebungsdaten), nicht in separaten Tabs.
  • Data Quality sichtbar:
  • Freshness, Completeness, Validity als Badges je Widget.
  • Sensor Confidence Score: z. B. basierend auf Selbstdiagnose, Kalibrieralter, Plausibilitätschecks.
  • Einheitenkonsistenz und automatische Umrechnung (SI vs. US); Einheitenänderung muss auffällig kommuniziert werden.
  • Golden Signals übertragen: Aus SRE entlehnt – Fehler, Latenz, Durchsatz, Sättigung. Für Produktionslinien: Ausschussrate, Taktzeit, Pufferfüllstände, Rüstzeiten. Diese vier Signale oben links, konsistent in jeder Ansicht.
  • Interaktion unter Last:
  • 60 fps sind nett, aber stabil 30 fps mit Priorisierung kritischer Layer ist besser als ruckelige 60. Trennen Sie Render-Threads von Daten-Threads, nutzen Sie Snapshot+Delta-Modelle.
  • Backpressure sichtbar: Wenn Datenflut > UI-Verarbeitung, zeigen Sie „eingehende Rate, verarbeitete Rate, Dropped Frames“ an – Verdecktes Dropping zerstört Vertrauen.

4) KI-gestützte Entscheidungssysteme: Unsicherheit zeigen, Handeln absichern

„KI sagt: tauschen“ ist wertlos, wenn man Unsicherheit, Kosten und Alternativen nicht sieht.

  • Unsicherheit explizit:
  • Konfidenz als kalibrierte Größe (nicht nur Prozent). Zeigen Sie:
  • Streuung (z. B. Bandbreiten, Prediction Intervals)
  • Alternativenrankings mit Delta
  • Abstention („Nicht sicher – menschliche Bestätigung nötig“)
  • Conformal Prediction oder Selektionsfunktionen visualisieren (z. B. „90%-Abdeckung bei Fehlerrate X“).
  • Erklärbarkeit, die handlungsrelevant ist:
  • Gegenmaßnahmen statt nur Feature-Heatmaps: „Reduziere Zuführgeschwindigkeit um 8–12 %, um Temperaturspitzen zu vermeiden.“
  • Gegenfaktische Beispiele: „Wäre Toleranz der Welle +5 μm, läge Risiko <2 %.“
  • Datenursprung und Modellstand: „Modell v2.3 (Datensatz 2025-03, 1.2 Mio. Samples), Gültig für Linie B, Legierung 6082.“
  • Mensch-in-der-Schleife:
  • Bestätigungspfade abgestuft nach Risiko; niedrige Risiken: 1 Klick, hohe Risiken: 2 Personen + Begründung.
  • UI sammelt Feedback als Trainingssignal: „War Vorschlag hilfreich? Warum?“ – aber minimalinvasiv und offline speicherbar.