1. Einleitung
Was passiert, wenn eine KI einen Arbeitsplatz analysiert und dabei etwas übersieht? Bei einer App-Empfehlung ist das ärgerlich. Bei einer Gefährdungsbeurteilung ist es ein Haftungsrisiko.
SafeGuard ist eine mobile App, die Sicherheitsfachkräfte in Industriebetrieben bei der Erstellung von Gefährdungsbeurteilungen nach §5 ArbSchG unterstützt. Foto aufnehmen, KI erkennt Gefahren, Fachkraft prüft und gibt frei. Der Kern des Projekts war nicht die KI selbst, sondern die Frage, wie man ein Interface baut, das Nutzer:innen zwingt, wirklich hinzuschauen, statt einfach zu bestätigen.
Links:
DokuBoard: https://www.figma.com/board/LecHpxBbpskr6JcLWjVzK2/DokuBoard?node-id=0-1&t=AmADVATrcuFon1Un-1
SafeGuard: https://www.figma.com/design/eVLJ01u4W1KOfCjarCKbRE/SafeGuard?node-id=49-617&t=hjwxBI4XCTnhGGiu-1
2. Problemstellung
Der aktuelle Prozess:
Gefährdungsbeurteilungen sind gesetzlich vorgeschrieben und müssen von einer fachkundigen Person verantwortet werden. Der Prozess läuft in vier Aktivitäten ab: Gefährdungsbeurteilung vorbereiten, Arbeitsplatz analysieren, Risiken bewerten, Maßnahmen festlegen und dokumentieren.
Das klingt strukturiert. In der Praxis sieht es anders aus.
Die Domain Research ergab klare Pain Points: Unterschiedliche Gesetze und Vorschriften sind schwer überschaubar. Bestehende Dokumentationen sind oft unstrukturiert oder veraltet, wodurch Wissen verloren geht statt wiederverwendet zu werden. Fotos zeigen nicht alle Gefahren, akustische oder psychische Belastungen bleiben unsichtbar. Die Risikobewertung hängt stark von der Erfahrung der einzelnen Person ab. Und die Dokumentation kostet so viel Zeit, dass sie in der Praxis oft nachlässig erledigt wird.
Warum KI hier ein besonderes Risiko ist:
Eine Gefährdungsbeurteilung ist ein rechtlich bindendes Dokument. Eine KI-Halluzination, also eine erfundene Gefährdung oder eine übersehene Gefahr, ist kein kosmetischer Fehler, sondern ein potenzielles Haftungsproblem für Unternehmen und Fachkraft.
Das macht Automation Bias zur zentralen Gefahr des Projekts: Wenn Nutzer:innen einem KI-Vorschlag zu schnell vertrauen, weil er kompetent und vollständig formatiert aussieht, wird die menschliche Prüfung zur reinen Formsache. Genau das, was das Gesetz verhindern soll.
Die zentrale Designfrage war deshalb: Wie gestaltet man ein Interface, das Tempo bringt, aber gleichzeitig erzwingt, dass ein Mensch jede einzelne Aussage der KI bewusst prüft und verantwortet?
3. Lösung:
Die Lösung basiert auf dem Prinzip „Human-in-the-Loop Correction“, umgesetzt über fünf konkrete Designentscheidungen:
Strukturierte Vorab-Erfassung statt Foto als einziger Input: Bevor überhaupt fotografiert wird, erfasst die App Kontext: Abteilung, Tätigkeitsart, Anzahl betroffener Personen. Ein Info-Hinweis erklärt, dass diese Angaben bestimmen, welche DGUV-Vorschriften und BetrSichV-Regelungen die KI-Analyse berücksichtigt. Die KI bekommt einen geprüften Rahmen, statt frei zu raten.
Jede Gefährdung einzeln prüfbar, nie als Paket übernehmbar: Nach der Analyse landet jede erkannte Gefährdung auf einem eigenen Screen mit Risikostufe, Beschreibung und Maßnahmen. Es gibt keinen „Alles übernehmen“-Button. Jede Gefährdung muss separat bestätigt, bearbeitet oder abgelehnt werden.
Sichtbare Herkunftskennzeichnung statt anonymer Texte: KI-Vorschläge tragen ein „KI-Vorschlag“-Label mit Konfidenz-Anzeige. Manuell ergänzte Gefährdungen sind mit „Manuell erfasst“ gekennzeichnet, ohne Konfidenzwert. So ist auf jedem Screen erkennbar, ob eine Aussage von der KI stammt oder vom Menschen.
Expliziter manueller Ergänzungsschritt („Was sieht die Kamera nicht?“): Ein eigener Schritt im Flow fragt aktiv nach Gefahrenarten, die ein Foto grundsätzlich nicht zeigen kann: Gefahrstoffe, Klima/Hitze, Beleuchtung, Lärm. Dieser Schritt ist gleichwertig im Flow verankert, nicht als nachrangiges Extra ans Ende gestellt.
Kein Abschluss ohne vollständige Prüfung: Der letzte Schritt vor dem PDF-Export zeigt an, wie viele Punkte noch offen sind, und lässt sich erst abschließen, wenn alle Punkte bestätigt wurden.
4. Umsetzung
4.1 Recherche
Das Thema war zu Beginn komplett fremd. Gefährdungsbeurteilungen, DGUV-Vorschriften, das STOP-Prinzip für Maßnahmen, der Unterschied zwischen Gefährdung und Risiko: alles musste erst verstanden werden, bevor überhaupt über Design nachgedacht werden konnte.
Die Domain Research klärte, welche Gesetze relevant sind (ArbSchG, BetrSichV, DGUV-Regeln, EU AI Act), wie der aktuelle Workflow ohne KI aussieht, wo die echten Pain Points liegen und wie weit KI in diesem Kontext sinnvoll eingesetzt werden kann.
Ein zentrales Ergebnis: Die Grenzen der KI sind hier besonders klar. Sichtbare Gefahren wie fehlende Schutzkleidung oder Lichtbogenstrahlung kann ein Modell auf einem Foto erkennen. Lärm, Stress, psychische Belastung, Teamdynamik, das kann kein Bild zeigen. Dieses Wissen hat die Entscheidung für den „Was sieht die Kamera nicht?“-Schritt direkt begründet und war der Moment, an dem aus einer Feature-Idee ein strukturelles Designprinzip wurde.
Als Rahmenwerk wurden Microsoft HAX Guidelines (G5: KI-Fehler einfach korrigierbar machen, G6: Vorschläge anbieten statt aufdrängen) und das Google PAIR Guidebook zu Calibrated Trust herangezogen.
4.2 Silicon Personas und User Story Mapping
Drei Silicon Personas wurden entwickelt, um unterschiedliche Vertrauensprofile gegenüber KI abzubilden:
Die Personas wurden mit strukturierten Interviewfragen befragt, unter anderem „Wann würdest du einem KI-Vorschlag vertrauen, und wann nicht?“ und „Welche Fehler wären in deinem Arbeitsbereich absolut kritisch?“. Die Antworten wurden in einer Konsens-vs-Konflikt-Matrix ausgewertet.
Der entscheidende gemeinsame Nenner trotz unterschiedlicher Tech-Affinität: Alle drei wollen KI als Assistenz, nicht als Entscheider. Alle wollen verstehen, was erkannt wurde und warum, nicht nur das Ergebnis. Kein pauschales Vertrauen, sondern nachvollziehbare Aussagen. Dieser Konsens hat das Action-Audit-Pattern direkt begründet.
Das User Story Mapping hat den Flow in vier Aktivitäten gegliedert und für jeden Schritt konkret bestimmt, wo KI sinnvoll helfen kann (Mustererkennung, Strukturierung, Vorschläge) und wo nicht (finale Risikobewertung, rechtliche Freigabe).
4.3 Der App-Flow
Der Flow folgt vier nummerierten Schritten, die auch im Interface sichtbar sind:
Arbeitsbereich erfassen Abteilung, Tätigkeitsart, Anzahl betroffener Personen.
Arbeitsplatz aufnehmen: Foto des Arbeitsbereichs, danach „KI-Analyse starten“. Ein Ladescreen mit sichtbaren Analyse-Phasen (Bild verarbeiten, Objekte erkennen, Risiken bewerten, Bericht erstellen) macht den Analyseprozess sichtbar und setzt realistische Erwartungen an das, was die KI leistet.
KI-Ergebnisse und Was sieht die Kamera nicht? KI-erkannte Gefährdungen einzeln prüfen, danach manuelle Ergänzung nicht-fotografierbarer Gefahrenarten.
Prüfen und Freigeben – Gesamtübersicht, Abschluss erst nach vollständiger Bestätigung aller Punkte.
Nach Abschluss speichert die App die Bewertung unveränderbar in der Historie. Korrekturen erfordern eine neue Gefährdungsbeurteilung mit erneuter Freigabe. Das ist keine technische Einschränkung, sondern eine bewusste Designentscheidung: Ein rechtlich bindendes Dokument soll sich auch so anfühlen.
4.4 Designentscheidungen
Vier-Farben-System
Die wichtigste visuelle Entscheidung war die strikte Trennung von vier Farbfamilien:
Markenblau (#4A7BA6) für Navigation, Buttons und neutrale Struktur. Blau wurde gewählt, weil es im behördlichen und sicherheitstechnischen Kontext als professionell und vertrauenswürdig wahrgenommen wird. Es wirkt vertraut, nicht bedrohlich.
KI-Herkunft (#6B5CA5) markiert alles, was von der KI vorgeschlagen wurde. Bewusst ein entsättigtes Blau-Violett, das nah genug am Markenblau liegt, um nicht fremd zu wirken, aber klar unterscheidbar bleibt.
Risikostufen (Hoch #B23A3A, Mittel #BD7B2E, Niedrig #4F8A6B) für die Risikobewertung, unabhängig von der Herkunft.
Manuell erfasste Inhalte erhalten keine eigene Akzentfarbe, weil der Kontrast zur KI-Farbe die Unterscheidung bereits leistet.
Der ursprüngliche Ansatz war, KI-Inhalte in der Markenfarbe zu zeigen. Das hätte die KI optisch als „offiziellen“ Teil der App getarnt und genau das verschleiert, was sichtbar sein muss: ob eine Information von der KI oder vom Menschen stammt. Die Entscheidung für eine eigene KI-Farbe war eine nachträgliche Korrektur, kein ursprünglicher Plan. Das war der Punkt, an dem „sieht gut aus“ und „funktioniert gut“ tatsächlich im Konflikt standen.
Konfidenzanzeige nur bei KI-Vorschlägen
Auf dem „Gefährdung bearbeiten“-Screen gibt es zwei Varianten: eine mit KI-Label und Konfidenz-Balken, eine ohne beides für manuell erfasste Einträge. Eine Konfidenzangabe bei einer menschlichen Eingabe hätte keinen Sinn ergeben und wäre für Nutzer:innen verwirrend gewesen.
4.5 Kritische Momente
Reihenfolge im Flow
Eine frühe Frage war, ob der manuelle Ergänzungsschritt vor oder nach der KI-Analyse kommen soll. „Vor“ hätte der KI mehr Kontext gegeben. „Nach“ entspricht dem natürlichen Ablauf einer Begehung: erst beobachten und aufnehmen, dann systematisch nachhaken, was das Foto nicht zeigen konnte. Entschieden wurde für „danach“, auch weil der Schritt „Was sieht die Kamera nicht?“ nur dann Sinn ergibt, wenn Nutzer:innen bereits sehen, was die KI gefunden hat, und gezielt das ergänzen können, was fehlt.
Unordnung im Figma-File
Bei iterativem Arbeiten entsteht schnell Unordnung, ohne dass sie auf den ersten Blick sichtbar ist. Den Überblick zu behalten war generell schwierig: welche Frame-Variante ist die finale, welche ist ein veralteter Zwischenstand, welche ist nur eine Kopie zum Ausprobieren? In einer der Varianten steckte noch ein Platzhaltertext („test“), der im Gesamtüberblick nicht auffiel. Das war ein konkretes Argument dafür, in Figma von Anfang an sauber zu benennen und aufzuräumen statt erst am Ende.
Verworfene Ideen
Früh gab es Ideen für eine Risikomatrix, die alle Gefährdungen auf einmal abbildet, und ein Verlaufsdiagramm für den Prüffortschritt. Beide wurden verworfen, nicht weil sie konzeptionell falsch waren, sondern weil sie die eigentliche Nutzung überlagert hätten. Sicherheitsfachkräfte sollen eine GBU erstellen, keine Datenvisualisierung interpretieren. Jede zusätzliche Komplexitätsebene hätte die Überschaubarkeit des Flows gefährdet.
KI-Warnung Banner und Feedback-Buttons
Oben auf dem KI-Ergebnisse-Screen erscheint ein persistenter Hinweis: „KI-Vorschläge müssen geprüft werden. Vollständigkeit nicht garantiert.“ Zusätzlich bietet jede KI-Karte drei Aktionen: Bearbeiten (wenn der Vorschlag teilweise stimmt), Bestätigen und Ablehnen. Das trennt die Handlung vom Korrekturprozess und macht klar, dass Ablehnen genauso eine valide Option ist wie Bestätigen.
5. Fazit, Learnings und Kursrückblick
Das Thema war zu Beginn komplett fremd. Gefährdungsbeurteilungen, DGUV-Vorschriften, Fachbegriffe wie STOP-Prinzip oder BetrSichV: es gab viel zu verstehen, bevor überhaupt über Design nachgedacht werden konnte. Auch die Frage, ob die App mobil oder als Desktop-Webanwendung funktionieren soll, hat länger gebraucht als erwartet. Und mit Figma-Komponenten und Prototyping bin ich an Grenzen gestoßen, besonders am Anfang.
Sobald das Konzept stand und klar war, was die App leisten soll, hat es Spaß gemacht. Der Moment, in dem die einzelnen Entscheidungen anfingen, zusammen zu passen, der Flow, das Farbsystem, die Interaktionslogik, war der befriedigendste Teil des Projekts.
Das wichtigste Learning: Bei KI-Interfaces ist die Interaktionslogik genauso wichtig wie das visuelle Design. Wie ein System Vertrauen kalibriert, wer was wann bestätigt, und wie sichtbar gemacht wird, was die KI weiß und was nicht, das sind Designfragen, keine Technikfragen. Automation Bias und Calibrated Trust klangen zu Beginn abstrakt. Im Projektverlauf wurden sie zu konkreten Entscheidungskriterien bei jeder einzelnen Designfrage.
Mitgenommen habe ich Figma-Kenntnisse, die am Anfang noch nicht vorhanden waren, und ein klareres Bild davon, was UX-Design in sicherheitskritischen Kontexten bedeutet.
Kursrückblick: Der Kurs hat etwas gebracht, was ich nicht erwartet hätte: das Gefühl, sinnvoll zu arbeiten statt nur Aufgaben abzuhaken. Das Feedback war klar und respektvoll, und von den Projekten der anderen zu lernen war einer der hilfreichsten Teile. UX-Design ist definitiv ein Bereich, mit dem ich mich gerne weiter beschäftigen würde.
