Agenten-Observability und -Governance gehören ins UI: Wer hat welchen Prompt/Regel geändert? Welche Datenquellen wurden herangezogen? Welche Drift-Warnungen bestehen? In air-gapped Umgebungen lässt sich das als On-Prem‑Konsole lösen, die Modellversionen, Policy-Änderungen und Vorfälle revisionssicher führt.

Souveränität, On-Prem und Air Gap: UX ist Deployment-Design

Wenn Cloud tabu ist, wird das UI auch zum Navigator durch Degradationsmodi:

  • Offline‑First. Kritische Ansichten funktionieren mit lokalem Cache und „last known good“. Aktionen werden als Jobs persistiert und synchronisiert, wenn der Link steht. UI zeigt Sync‑Status und Konflikte.
  • Signierte Updates. Das UI erklärt, warum ein Update nötig ist, welche Komponenten betroffen sind, und erzwingt Wartungsfenster/4‑Augen. Kein „Update jetzt“ mitten im Schichtbetrieb.
  • Telemetrie im Werk. Observability-Daten bleiben vor Ort. Das UI bietet Exportpfade (signierte Reports, Air‑Gap‑Transfer) für Audits.
  • Rollenbasierte Isolation. Aktionen mit Produktionswirkung sind physisch und logisch getrennt (z. B. getrennte Hardware-Taste + UI‑Bestätigung).

Diese Anforderungen prägen auch Designentscheidungen: Keine Abhängigkeit von externen Fonts/CDNs, robuste Fallbacks bei fehlenden Karten-/Bildkacheln, klare Fehlerbilder statt generischer „500er“.

Visuelles und Interaktionsdesign für raue Umgebungen

Gestalterische Details sind hier Sicherheitsdetails:

  • Touch-Ziele großzügig. Große Hit‑Areas, Buttons mit Abstand. Unterstützen Sie Handschuhbedienung: keine dicht beieinanderliegenden kritischen Aktionen.
  • Redundante Kodierung. Farbe + Icon + Klartext + Form. Farbschwächen und Blendung dürfen keine Information vernichten.
  • Kontrast und Glare. Hoher statischer Kontrast, aber ohne reines Schwarz/Weiß, um Blooming zu reduzieren. Hilfslinien und Kanten betonen Interaktionszonen.
  • Typografie und Entfernung. Beschriftungen so dimensionieren, dass sie aus dem typischen Bedienabstand lesbar sind. Nutzen Sie wenige Schnitte, klare Hierarchie, keine Leichtschrift.
  • Fokus- und Tastaturnavigation. Viele Stationen haben Hardware-Tasten/Encoder. UI muss ohne Maus bedienbar sein, mit sichtbarem Fokus und vorhersagbarer Reihenfolge.
  • Latency-Härtung. Aktionen geben sofortige haptische/akustische Bestätigung, auch wenn die Systemreaktion asynchron ist. Spinner mit Prozent/ETA nur bei reproduzierbaren Latenzen, sonst Zustandswechsel „ausstehend“ mit Job‑ID.
  • Kritische Aktionen doppelt sichern. „Halten zum Ausführen“ oder „zwei unterschiedliche Bedienelemente betätigen“ für irreversible Schritte. Keine Bestätigungsdialoge, die unter Alarmflut untergehen.

Interaktionsmuster unter Latenz- und Konsistenzbudgets

In verteilten Systemen trifft UX auf Konsistenzfragen:

  • Optimistisch vs. pessimistisch. Lokal sofort anzeigen („Job angelegt“) und später bestätigen, statt UI zu blockieren. Für sicherheitsrelevante Aktionen lieber pessimistisch mit klare Sperrlogik.
  • Konflikt-UI. Wenn zwei Akteure konkurrieren (Operator A, Remote B), brauchen wir einen Sichtmechanismus („wird gerade von B bearbeitet“) und klare Merge‑Strategien (z. B. „neueste gewinnt“ ist selten richtig).
  • Zeitfenster definieren. Jede Ansicht hat ein Aktualisierungsziel (z. B. „innerhalb des Takts aktualisiert“). UI zeigt, wenn das Ziel verfehlt wird, und was das für Entscheidungen bedeutet („Daten älter als Takt, bitte manuell verifizieren“).
  • Edge-Persistenz. Lokale Queue für Kommandos mit Status: geplant, gesendet, bestätigt, fehlgeschlagen. Retry-Strategik sichtbar und steuerbar.

Architektur und UI: gemeinsame Sprache

Ein UI ist so gut wie die API, die es füttert. Deshalb legen wir gemeinsam mit Architekten folgende Schnittstellenverträge fest:

  • Zustandsmaschinen explizit. Jede Maschine/Asset hat definierte Zustände und erlaubte Übergänge; UI spiegelt diese als Schrittketten.
  • Ereignisse sind unveränderlich. UI baut einen Event‑Log mit Kausalität, keine nachträglich „bereinigten“ Zeitreihen. Rücknahmen werden als Kompensationsereignisse modelliert, nicht als Edit.
  • Abfragen mit Semantik. Endpunkte liefern neben Daten auch Semantik (z. B. „Schwelle überschritten, Hysterese aktiv“), damit die UI keine Geschäftslogik erraten muss.
  • Versionierte Schemas. UI kann neue Felder nutzen, ohne bei älteren Edge‑Nodes zu brechen. Degradationspfade werden entworfen, nicht gehofft.

Testing und Qualitätssicherung: unter echten Bedingungen

Die beste Usability‑Studie nützt nichts, wenn sie am Laptop im Büro stattfindet. Unser Ansatz:

  • Szenariobasierte Tests in Umgebungssimulation. Lärm, Handschuhe, Blendung, Vibration – und echte Zeitbudgets. Aufgaben messen wir nicht in Klicks, sondern in „Zeit bis sichere Entscheidung“.
  • Fehlerinjektion. Paketverlust, Clock‑Skew, Sensor-Timeouts, „split brain“ zwischen Edge und Leitwarte. UI muss Fehlersignaturen zeigen, die Diagnose erlauben.
  • Screenshot- und Zustandsdiffs. Regressionen im Layout und in Zustandsautomaten werden automatisiert detektiert.
  • Shadow-Logging. Vor Ausrollen von Autovervollständigung, Vorschlägen etc. läuft alles im Beobachtermodus mit und wird mit echten Bedienentscheidungen korreliert.

Metriken für den Betrieb: was wir messen, verbessert sich

Keine Vanity‑KPIs. Sinnvolle Metriken sind:

  • Zeit bis Quittierung und bis Maßnahmenstart, pro Alarmklasse.
  • Alarmrücklaufquote nach Quittierung (Hysterese zu eng?).
  • Anteil „Unsicher / eskaliert“ vs. „automatisch vorgeschlagen / bestätigt“ bei KI‑Vorschlägen.
  • Kontextwechsel pro kritischer Aufgabe (wie oft wechselt ein Operator zwischen Ansichten?).
  • Fehlerkategorien bei Falschbedienung (z. B. versehentliche Aktivierung vs. Fehleinschätzung).
  • Datenfrische vs. getroffene Entscheidungen (Korrelation aus Altdaten und Fehlentscheidungen).

Diese Zahlen gehören ins Betreiber‑UI – nicht als Marketing‑Dashboard, sondern als internes Werkzeug, um UI und Prozesse nachzuschärfen.

Konkretes Beispiel: UI‑Flow für KI‑gestützte visuelle Qualitätskontrolle

Angenommen, eine Station prüft Bauteile per Kamera, eine KI schlägt „defekt“ vor. Ein robustes UI könnte so aussehen:

  • Overview oben: Taktstatus, Zahl in Bearbeitung, Alarmindikatoren mit Frischeanzeige.
  • Hauptbereich: aktuelles Bild mit Overlays der erkannten Merkmale. Schalter für Overlay‑Ebenen (Roh, Segmentierung, Abweichung).
  • Entscheidungskarte: KI‑Vorschlag mit Konfidenzband und ähnlichen Fällen. Buttons: „Freigeben“, „Ausschuss“, „Zur Nacharbeit“. „Halten zum Ausführen“ bei Ausschuss.
  • Begründung kompakt: „Abweichung an Kante B02: 4/6 Merkmale außerhalb Toleranz; ähnliche Fälle: M‑42, M‑77; empfohlene Maßnahme: Nacharbeiten.“
  • Eskalation: „Unsicher“ legt Fall in die QS‑Queue, fordert Remote‑Review an, zeigt ETA.
  • Auditpane: Modellversion, Datenquelle(n), letzte Policy‑Prüfung, generierter Job‑ID-Link zur Nachverfolgung.
  • Degradation: Wenn KI offline, bietet UI den manuellen Messmodus an und kennzeichnet Serien, die ohne KI geprüft wurden.