Definition
Systematischer Prozess zur Gestaltung sicherer und benutzerfreundlicher Medizinprodukte. Geregelt in IEC 62366 und gefordert durch MDR. Umfasst Analyse der Anwender, Risiken durch Fehlbedienung, Gestaltung der Benutzeroberfläche und formative sowie summative Evaluierung. Ziel: Elimination von Use Errors vor der Markteinführung.
In der Praxis
Usability Engineering ist der Prozess, der die Gebrauchstauglichkeit erzeugt — und der häufigste Fehler ist, ihn auf den Schluss zu schieben. Erstes Fehlerbild: Die summative Evaluation zwei Wochen vor der Einreichung. Dann ist jede Erkenntnis teuer, weil die Benutzerschnittstelle längst eingefroren ist; formative Schleifen während der Entwicklung kosten einen Bruchteil. Zweites Fehlerbild: Der Prozess läuft ohne das Risikomanagement. Die IEC 62366-1 ist auf die ISO 14971 zugeschnitten — Use Errors sind Gefährdungen, und die Usability-Akte und die Risikomanagement-Akte müssen ineinandergreifen, nicht nebeneinander existieren. Drittes Fehlerbild: Die Anwenderanalyse aus dem Lehrbuch statt aus dem Feld. Wer nie mit einer Pflegekraft auf Nachtschicht gesprochen hat, schreibt Nutzungskontexte, die im Audit und im Ernstfall nicht tragen. Und für Software gilt: Bei SaMD ist die Benutzerschnittstelle oft das Produkt — hier ist Usability Engineering kein Anhängsel, sondern Kern der Entwicklung, verzahnt mit dem Software-Lebenszyklus nach IEC 62304.
Verwandte Begriffe
Häufige Fragen zu Usability Engineering
Was ist der Unterschied zwischen formativer und summativer Evaluation?
Die formative Evaluation begleitet die Entwicklung: Sie testen frühe Prototypen mit Anwendern, um Schwachstellen zu finden und das Design zu verbessern — Ergebnis ist Erkenntnis, nicht Nachweis. Die summative Evaluation steht am Ende: Sie weist am fertigen oder produktionsgleichen Produkt nach, dass die sicherheitsbezogenen Nutzungsszenarien beherrscht werden — Ergebnis ist der formale Beleg für die technische Dokumentation. Beide haben unterschiedliche Regeln: Formative Tests dürfen klein, iterativ und informell sein; die summative braucht repräsentative Anwender, definierte Szenarien und dokumentierte Annahmekriterien. Der teuerste Fehler ist, formative Schleifen zu überspringen und alle Überraschungen in die summative zu verlagern — dann wird aus einem Nachweis ein Entwicklungsrisiko.
Müssen wir den Prozess nach IEC 62366-1 durchlaufen, oder reicht ein Usability-Test?
Ein einzelner Test reicht nicht — gefordert ist der Prozess. Die IEC 62366-1 beschreibt den Usability-Engineering-Prozess von der Analyse der Anwender und Nutzungskontexte über die Identifikation sicherheitsbezogener Merkmale bis zur Gestaltung, formativen und summativen Evaluation. Die Norm ist der anerkannte Stand der Technik, um die Gebrauchstauglichkeitsanforderungen der MDR zu erfüllen; die ISO 13485 verweist bei den Entwicklungseingaben ausdrücklich auf sie. Ohne dokumentierten Prozess fehlt Ihnen die Kette von der Anwenderanalyse zum Nachweis — und genau die prüft die Benannte Stelle. Ein isolierter Test am Ende ist Evidenz ohne Fundament. Skalieren dürfen Sie den Aufwand: Die Norm selbst verlangt risikobasierte Angemessenheit (IEC 62366-1).
Wie bauen wir Usability Engineering in unseren Entwicklungsprozess ein?
Verankern Sie den Prozess in der Entwicklungsplanung: Usability-Aktivitäten gehören als eigene Zeile in den Entwicklungsplan, mit Verantwortlichem und Meilensteinen. Starten Sie mit der Anwender- und Kontextanalyse, bevor die erste Benutzerschnittstelle entsteht — Interviews und Feldbeobachtungen mit echten Anwendern, nicht mit Kollegen. Definieren Sie die sicherheitsbezogenen Nutzungsszenarien gemeinsam mit dem Risikomanagement, damit Use Errors und Gefährdungen dieselbe Sprache sprechen. Planen Sie mindestens zwei formative Schleifen ein — eine am Konzept, eine am funktionsfähigen Prototypen — und die summative Evaluation erst, wenn das Design stabil ist. Führen Sie die Usability-Akte als eigenen, aber verlinkten Teil der technischen Dokumentation. Und schulen Sie die Entwickler: Usability ist eine Disziplin, keine Abteilung.