Es gibt einen Satz, der in Unfallberichten technischer Produkte auffallend häufig vorkommt: Der Anwender habe das Gerät falsch bedient. Formal stimmt das oft. Als Erklärung taugt es selten. Wenn dieselbe Verwechslung dreißig Mal an verschiedenen Orten passiert, liegt das Problem nicht bei dreißig unaufmerksamen Menschen, sondern in der Konstruktion.
Diese Einsicht hat sich in der Produktentwicklung inzwischen durchgesetzt, in sicherheitskritischen Branchen sogar als verbindliche Anforderung. Usability Engineering ist dort kein Designthema, sondern Teil des Sicherheitsnachweises.
Vom Designwunsch zur Pflicht
Der Wandel lässt sich an einem Beispiel zeigen, das in Fachkreisen oft zitiert wird: Infusionspumpen. Über Jahre häuften sich Berichte über gravierende Dosierfehler. Ein wiederkehrendes Muster war die Eingabe der Dosis über ein Tastenfeld, bei dem ein verrutschter Dezimalpunkt aus einer Einheit zehn machte. Die Geräte funktionierten technisch einwandfrei. Sie verrechneten nichts, sie gaben genau das ab, was eingegeben wurde.
Die Konsequenz war keine Kampagne für aufmerksameres Pflegepersonal, sondern eine konstruktive: Softwaresperren für unplausible Werte, Bestätigungsschritte bei kritischen Dosierungen, eindeutige Anzeigen. Die Verantwortung wanderte vom Anwender zum Hersteller.
Heute schreibt die europäische Medizinprodukteverordnung vor, dass Risiken durch Anwendungsfehler bei der Auslegung berücksichtigt werden müssen. Eine eigene Norm beschreibt, wie dieser Prozess abzulaufen hat. Für Hersteller heißt das: Ein Produkt, das sich leicht falsch bedienen lässt, ist ein Produkt mit einem Sicherheitsmangel, unabhängig davon, wie zuverlässig die Technik dahinter arbeitet. In der Entwicklung von Medizinprodukten ist der Usability-Prozess deshalb fest mit Risikomanagement und Verifizierung verzahnt und wird von Prüfstellen genauso begutachtet wie die technische Dokumentation.
Der Ablauf in der Praxis
Der Prozess beginnt lange vor dem ersten Prototyp, mit einer Beschreibung der vorgesehenen Anwendung. Wer bedient das Produkt? Unter welchen Bedingungen? Mit welcher Vorerfahrung? Ein Gerät für den Rettungsdienst wird im Halbdunkel, mit Handschuhen und unter Zeitdruck bedient. Ein Laborgerät steht in einem ruhigen Raum, bedient von geschultem Personal, das täglich damit arbeitet. Dieselbe Bedienlogik funktioniert nicht in beiden Fällen.
Daraus leiten Entwickler die sicherheitsbezogenen Bedienschritte ab. Das sind die Handlungen, bei denen ein Fehler tatsächlich Schaden anrichten kann. Nicht jeder Klick ist sicherheitsrelevant, und die Konzentration auf die kritischen Schritte hält den Aufwand im Rahmen.
Für diese Schritte werden mögliche Fehler systematisch durchgespielt. Was passiert, wenn ein Schritt übersprungen wird? Wenn zwei ähnliche Anschlüsse verwechselt werden? Wenn jemand eine Warnung wegklickt, ohne sie zu lesen? Erfahrene Teams merken hier schnell, dass die interessanten Fälle nicht die exotischen sind, sondern die naheliegenden.
Anschließend wird gestaltet, und zwar nach einer klaren Rangfolge. Zuerst versucht man, den Fehler konstruktiv unmöglich zu machen. Zwei Schläuche, die nicht verwechselt werden dürfen, bekommen unterschiedliche Steckverbindungen, die schlicht nicht zusammenpassen. Erst wenn das nicht geht, folgen Schutzmaßnahmen wie Alarme oder Sperren. Ganz am Ende steht der Hinweis in der Gebrauchsanweisung, und der gilt als schwächste Maßnahme. Ein Warnhinweis auf Seite 47 verhindert nichts.
Testen mit echten Anwendern
Der Teil, den viele Unternehmen unterschätzen, ist die Prüfung mit Nutzern. Vorgesehen sind zwei Arten von Tests. Formative Tests laufen während der Entwicklung, mit Papierprototypen oder frühen Mustern, und dienen dazu, Probleme früh zu finden. Der summative Test kommt am Ende, mit dem seriennahen Produkt und repräsentativen Anwendern, und liefert den Nachweis, dass die Bedienung sicher beherrschbar ist.
Der summative Test hat feste Regeln. Die Teilnehmenden müssen aus der tatsächlichen Zielgruppe stammen, nicht aus der Entwicklungsabteilung. Sie bekommen realistische Aufgaben und keine Hilfestellung. Beobachtet wird, was sie tun, und im Anschluss wird gefragt, warum sie es getan haben. Gerade dieses Nachgespräch bringt die wertvollsten Erkenntnisse, weil es zeigt, welches gedankliche Modell jemand vom Gerät hat.
Diese Tests sind unbequem. Entwicklungsteams sehen dabei zu, wie Menschen an einer Lösung scheitern, die im Team monatelang als selbsterklärend galt. Aber genau dieser Moment ist der Grund, warum getestet wird. Die Alternative ist, dass derselbe Fehler später im Feld passiert, dann allerdings mit Konsequenzen und einer Meldepflicht.
Ein häufiger Fehler bei der Auswertung ist übrigens, Bedienfehler nach Schweregrad der Beobachtung zu sortieren statt nach Schweregrad der Folge. Ein Teilnehmer, der lange sucht und dann doch das Richtige tut, ist weniger kritisch als einer, der zügig und selbstsicher das Falsche tut, ohne es zu bemerken. Der zweite Fall ist der gefährliche, weil er im Alltag nicht auffällt und deshalb auch nicht korrigiert wird.
Warum das auch außerhalb regulierter Branchen zählt
Die formalen Anforderungen gelten für Medizinprodukte, Maschinen und einige weitere Bereiche. Die Logik dahinter ist überall dieselbe. Ein Produkt, das falsch bedient wird, erfüllt seinen Zweck nicht, egal ob daraus ein Gesundheitsschaden entsteht oder nur ein verärgerter Kunde.
Der wirtschaftliche Hebel liegt dabei früh im Projekt. Eine Bedienlogik im Konzeptstadium zu ändern, kostet ein paar Workshoptage. Dieselbe Änderung nach der Serienfreigabe kostet ein Redesign, neue Werkzeuge und eine erneute Prüfung. Fällt der Fehler erst nach der Auslieferung auf, kommen Rückrufkosten und Reputationsschaden dazu.
Der zweite Punkt betrifft den Support. Ein erheblicher Teil aller Servicefälle ist kein Defekt, sondern ein Verständnisproblem. Wer diese Fälle auswertet, findet dort eine kostenlose und ziemlich präzise Liste der Schwachstellen im Bedienkonzept. Viele Unternehmen sammeln diese Daten, ohne sie je an die Entwicklung zurückzuspielen.
Die Gebrauchsanweisung als Teil des Produkts
Eine Konsequenz aus alldem betrifft ein Dokument, das in vielen Projekten zuletzt entsteht und entsprechend behandelt wird: die Gebrauchsanweisung. Formal ist sie Bestandteil des Produkts und wird mitgeprüft. Praktisch wird sie oft von der technischen Redaktion nach Abschluss der Entwicklung geschrieben, ohne dass jemand sie mit echten Anwendern erprobt hat.
Dabei lässt sich mit vertretbarem Aufwand viel gewinnen. Wer im Usability-Test die Teilnehmenden ausschließlich mit der Anleitung arbeiten lässt, sieht innerhalb einer Stunde, welche Formulierungen missverstanden werden. Häufig sind es dieselben Stellen, an denen später der Support anruft. Ein Hinweis, der die Reihenfolge zweier Schritte nicht eindeutig festlegt, produziert zuverlässig Fehler, und zwar bei jedem Anwender neu.
Was ein realistischer Einstieg ist
Kleinere Unternehmen schrecken oft vor dem Aufwand zurück, weil sie einen ausgewachsenen Usability-Prozess mit eigenem Labor vor Augen haben. Der Einstieg ist kleiner.
Fünf bis acht Personen aus der Zielgruppe, ein Prototyp, ein paar realistische Aufgaben und jemand, der beobachtet und mitschreibt: Damit findet man den überwiegenden Teil der gravierenden Bedienprobleme. Untersuchungen zur Testgröße kommen seit Jahrzehnten auf ähnliche Zahlen, und die Erfahrung in Projekten bestätigt sie. Die schweren Fehler zeigen sich bei den ersten Teilnehmenden, die weiteren liefern Details.
Wichtiger als die Methode ist der Zeitpunkt. Ein Test, der stattfindet, wenn das Gehäusewerkzeug bereits bestellt ist, dient der Beruhigung, nicht der Verbesserung. Wer erst dann prüft, dokumentiert im Zweifel nur sauber, was sich nicht mehr ändern lässt.
