Security-Produkte gestalten, die Menschen wirklich bedienen können

Ich gestalte seit rund fünfundzwanzig Jahren digitale Produkte, einige davon in der Cybersecurity: drei Jahre als Design Lead bei Exein im Bereich Embedded Security, und heute als Mitgründer und CTO von Shorium.

Die Lektion, die ich immer wieder neu lerne, ist einfach. Ein Security-Produkt ist nur so gut wie die Entscheidungen, die Menschen damit treffen können.

Erkennung, Analyse und Kryptografie können hervorragend sein. Wenn die Person vor dem Bildschirm nicht erkennt, was wichtig ist, warum, und was als Nächstes zu tun ist, versagt das Produkt genau dann, wenn es gebraucht wird.

Die zwei Arten, wie Security-Oberflächen scheitern

Sie zeigen alles. Jeder Alarm, jeder Befund, jede Logzeile, alle mit demselben visuellen Gewicht. Die Oberfläche ist technisch vollständig und praktisch unbenutzbar. Menschen lernen, sie zu ignorieren, und das ist schlimmer, als gar nichts zu haben.

Sie verbergen alles. Ein einziger Score, ein grünes Abzeichen, eine Ampel. Das wirkt einfach und beruhigend. Aber wenn jemand fragt „Warum ist das rot?“ oder „Sind wir sicher, dass das grün ist?“, hat die Oberfläche keine Antwort.

Beides entsteht aus demselben Fehler: Einfachheit als Entfernen von Information zu verstehen statt als ihre Ordnung.

Prinzipien, die ich anwende

1. Bei der Entscheidung anfangen, nicht bei den Daten. Bevor Sie einen Bildschirm gestalten, schreiben Sie auf, welche Entscheidungen die Nutzerin dort treffen muss. Jetzt patchen oder später? Eskalieren oder schließen? Welches Produkt ist betroffen? Jedes Element sollte einer dieser Entscheidungen dienen.

2. Schweregrad mit Bedeutung füllen. Der Schweregrad sollte verbinden, wie schlimm ein Problem ist und wie exponiert genau dieses System ist. Eine kritische Schwachstelle in einer nicht erreichbaren Komponente ist nicht dasselbe wie eine mittlere an einer offenen Schnittstelle. Zeigen Sie, warum etwas so eingestuft ist.

3. Immer die Herkunft zeigen. Woher kommt dieser Befund? Welcher Scan, welche Regel, welche Daten, wann? In der Sicherheit hängt das Vertrauen in ein Werkzeug davon ab, es überprüfen zu können.

4. Folgen vor Aktionen zeigen. Wenn jemand gleich ein Zertifikat widerruft, einen Schlüssel rotiert oder ein Update ausrollt, zeigen Sie zuerst, was davon abhängt. Die teuersten Fehler in der Sicherheit sind gut gemeinte Änderungen mit unsichtbaren Nebenwirkungen.

5. Für den Vorfall gestalten, nicht für die Demo. Demos finden an ruhigen Tagen mit sauberen Daten statt. Echte Nutzung passiert um 2 Uhr nachts, unter Druck, mit unvollständigen Informationen. Testen Sie die Oberfläche unter diesen Bedingungen: müde Nutzer, lückenhafte Daten, viele gleichzeitige Alarme.

6. Festhalten, was entschieden wurde. Security-Arbeit wird geprüft, und Regelwerke wie der Cyber Resilience Act verlangen Nachweise. Die Oberfläche sollte es leicht machen festzuhalten, wer was auf welcher Grundlage entschieden hat.

7. Barrierefrei gestalten. Security-Teams bestehen aus Menschen mit unterschiedlichen Fähigkeiten, die auf unterschiedlichen Geräten arbeiten, oft unter Stress. Barrierefreiheit ist hier keine Höflichkeit, sondern operative Resilienz.

Komplexität ist nicht der Feind

Sicherheit ist komplex, weil die Systeme, die sie schützt, komplex sind. Aufgabe des Designs ist nicht, diese Komplexität verschwinden zu lassen, sondern sie begehbar zu machen: erst der Überblick, Details auf Abruf, und ein klarer Weg von „etwas stimmt nicht“ zu „das tun wir jetzt“.

Dieses Prinzip prägt, wie wir bei Shorium über den Trust Twin nachdenken. Ein Modell kryptografischer Abhängigkeiten ist nur nützlich, wenn ein Mensch damit denken kann. Darüber habe ich in Warum ich Shorium aufbaue geschrieben.

Gutes Security-Design sorgt nicht dafür, dass Menschen sich sicher fühlen. Es hilft ihnen, richtig zu liegen.