Usability-Testing-Dokumentation strukturieren
KI strukturiert Usability-Testprotokolle nach IEC 62366 und generiert Bewertungsberichte aus Rohdaten der Nutzerstudien.
Mit KI-Agenten recherchiert und geschrieben, verantwortlich: Redaktion KI-Syndikat. So arbeiten wir Fehler melden
- Problem
- Usability-Engineering-Dokumentation nach IEC 62366 ist komplex, Testprotokolle, Auswertungen und Summary Reports erfordern hohe Präzision.
- KI-Lösung
- Ein LLM-basiertes System (NLP-Klassifikation) transkribiert Testsessions via Whisper, kategorisiert Usability-Probleme nach IEC-62366-Kriterien und generiert strukturierte Bewertungsberichte für den Notified Body.
- Typischer Nutzen
- Weniger Schreib- und Sortierarbeit bei Protokollauswertung und Summary Report, einheitlichere Schweregradvorschläge. Gemessene Zahlen dazu haben wir nicht gefunden, die Seite rechnet mit einer Annahme von 27 bis 55 Stunden je summativer Studie, die du am eigenen Stundenbuch prüfst.
- Setup-Zeit
- 10–16 Wochen bis Pilotbetrieb
- Kosteneinschätzung
- 20–40 Std. Einrichtung intern, ab 50 $/Monat Team-Tarif
Es ist Freitagabend, 18:15 Uhr.
Miriam, Human Factors Engineer bei einem Münchner Medizintechnikunternehmen, hat gerade die letzte Testsession der summativen Bewertung für ihr neues Insulinpumpen-System abgeschlossen. Drei Tage, 15 Probanden, je 90 Minuten, aufgezeichnet, notiert, beobachtet. Auf dem Tisch liegen 15 ausgefüllte Testbögen, drei Notebooks mit Beobachtungsnotizen, eine Excel-Datei mit Time-on-Task-Messungen und USB-Sticks mit 22 Stunden Videomaterial.
Der Usability Engineering Summary Report für den Notified Body soll in vier Wochen fertig sein.
Miriam öffnet ihren Laptop und fragt sich, wo sie anfangen soll. Die IEC 62366-1 verlangt für die summative Bewertung eine vollständige Darstellung aller Aufgaben, aller Fehler, aller Workarounds, der Schweregrad-Klassifizierung jedes Usability-Problems und die Schlussfolgerung, ob die Restrisiken aus Usability-Sicht akzeptabel sind. Alles rückverfolgbar auf die Risikoanalyse nach ISO 14971.
Vier Wochen für 22 Stunden Videomaterial, 15 Testbögen und einen Bericht, der vom Notified Body quer über alle Testaufgaben hinweg nachvollzogen werden kann. Ohne KI-Unterstützung: Miriam wird kaum Wochenenden sehen.
Für Unternehmen
Nicht nur lesen, umsetzen.
Wir setzen Anwendungsfälle wie diesen mit euch um oder trainieren euer Team darauf. Das Erstgespräch kostet nichts.
Das echte Ausmaß des Problems
Usability Engineering nach IEC 62366-1 ist Pflicht für alle Medizinprodukte, die unter MDR fallen, und der Aufwand für die Dokumentation ist systematisch unterschätzt.
Ein vollständiges Usability Engineering File (UEF) nach IEC 62366-1 umfasst:
- Usability Engineering Plan (Planungsdokument)
- Nutzungsprofile und Anwendungsumgebungen
- Aufgabenanalyse und -spezifikation
- Identifizierung kritischer Aufgaben
- Benutzeroberflächenspezifikation
- Formative Evaluation: Protokolle aller Iterationen
- Summative Evaluation: Testplan, Testprotokolle (je Proband), Rohdaten-Auswertung, Summary Report
- Verbindung zum Risikomanagement nach ISO 14971
Für ein Medizinprodukt mit 15–25 kritischen Aufgaben und einer summativen Bewertung mit 10–15 Probanden rechnet diese Seite allein für die Protokollauswertung mit 40 bis 80 Stunden, ohne Testdurchführung, Vorbereitung und Freigabeprozesse. Das ist eine Annahme, keine Messung, die Herleitung steht unter der Tabelle.
Das eigentliche Problem ist die Heterogenität der Rohdaten: Videoaufzeichnungen müssen transkribiert oder zumindest ausgewertet werden, Beobachtungsnotizen aus verschiedenen Quellen müssen zusammengeführt werden, quantitative Daten (Task Completion Rate, Time on Task, Use Errors) müssen mit qualitativen Beobachtungen verknüpft werden, und das alles muss in einer Struktur landen, die der Notified Body in einer Tabelle mit Rückverfolgbarkeit von Aufgabe zu Risiko zu Bewertung nachvollziehen kann.
Besonders kritisch: Inkonsistente Schweregradbewertungen von Usability-Problemen sind ein häufiger Grund für Notified-Body-Rückfragen. Wenn zwei Beobachter das gleiche Usability-Problem unterschiedlich klassifizieren, weil die Bewertungskriterien nicht explizit genug dokumentiert sind, entstehen Inkonsistenzen, die den Prüfer misstrauisch machen.
Mit vs. ohne KI, ein ehrlicher Vergleich
| Kennzahl | Ohne KI | Mit KI-Unterstützung |
|---|---|---|
| Auswertungsaufwand summative Evaluation (15 Probanden) | 40–80 Std. | 20–40 Std. ¹ |
| Kategorisierung von Usability-Problemen | manuell, inkonsistent | standardisiert nach vordefinierten Kriterien |
| Schweregradbewertung von Use Errors | subjektiv und variabel | regelbasiert, nachvollziehbar dokumentiert |
| Erstellung Usability Engineering Summary Report | 10–20 Std. Schreibarbeit | 3–5 Std. mit KI-generiertem Entwurf ¹ |
| Rückverfolgbarkeit Aufgabe → Fehler → Risiko | manuelle Tabellen-Pflege | strukturiert und automatisch verlinkbar |
¹ Keine Messung, sondern eine Annahme dieser Seite. Eine belastbare Studie zum Auswertungsaufwand haben wir nicht gefunden. Ableitung aus dem Beispiel oben: 22 Stunden Video einmal zu sichten kostet 22 Stunden, mit Kodieren und Abgleich der Beobachternotizen eher das Doppelte. Zusammen ergibt die Tabelle 27 bis 55 gesparte Stunden je summativer Studie, wenn die Annahmen zutreffen.
Eine Grenze gehört dazu: Whisper transkribiert, was gesagt wird. Viele Benutzungsfehler sieht man aber nur, etwa ein falsch herum eingelegtes Reservoir. Diese Fehler kommen aus den Live-Notizen der Beobachter oder aus der Videosichtung, nicht aus dem Transkript. Die KI spart deshalb vor allem beim Sortieren, Kategorisieren und Schreiben, kaum beim Hinsehen.
Der Schlüssel liegt oft nicht im Schreiben selbst, sondern in der strukturierten Kategorisierung: Wenn 15 Testprotokolle in einem einheitlichen Format vorliegen, kann KI die Auswertung erheblich beschleunigen.
Einschätzung auf einen Blick
Zeitersparnis, hoch (4/5) 27 bis 55 Stunden weniger je summativer Studie, wenn die Annahmen der Tabelle halten, sind bedeutsam, besonders für kleine Teams, die Human-Factors-Engineering als Nebenaufgabe führen. Nicht ganz auf dem Niveau der Technischen Dokumentation oder der PMS-Automatisierung, weil Usability Engineering einen höheren Anteil an inhaltlichen Bewertungen hat, die echtes Fachwissen erfordern, und nicht nur strukturierte Datenaggregation.
Kosteneinsparung, niedrig (2/5) Die Einsparungen entstehen über Arbeitsstunden, und interne Stunden werden erst Geld, wenn dafür etwas wegfällt: externe Beraterstunden oder Überstunden wie im Beispiel oben, in denen Miriam ihre Wochenenden opfert. Externe Usability-Consultants kosten 120–200 Euro/Stunde, und für eine vollständige Usability-Bewertung können 60–100 externe Stunden anfallen. KI-Unterstützung kann einen Teil davon ersetzen, wie groß, hat niemand gemessen. Dazu kommt: Wer die KI-Auswertung extern gegenprüfen lässt, bezahlt dafür wieder Beraterstunden, und externe Usability-Expertise wird für die inhaltliche Bewertung weiterhin benötigt. Der schlanke Weg kostet wenig, mit einer eQMS-Integration für 10.000 bis 30.000 Euro trägt sich die Sache über Usability allein kaum.
Schnelle Umsetzung, mittel (3/5) Einfacher als die beiden anderen Anwendungsfälle in dieser Kategorie: Kein komplexes Datenbankintegrationsprojekt, keine Anbindung an EUDAMED oder Vigilanzsysteme. Das Grundprinzip ist: Testprotokolle in ein strukturiertes Format bringen, KI-Assistent konfigurieren, Kategorisierungsregeln definieren. 10 bis 16 Wochen bis zum ersten produktiven Einsatz sind realistisch, wenn die Testdokumentation bereits in einem halbwegs strukturierten Format vorliegt.
ROI-Sicherheit, hoch (4/5) Wie bei der Technischen Dokumentation: Die Metriken sind klar, Stunden für Protokollauswertung, Stunden für Berichtserstellung, Anzahl Notified-Body-Rückfragen zu Usability-Themen. Diese Zahlen kann jedes Regulatory-Team aus den letzten Projekten rekonstruieren und nach 12 Monaten vergleichen. Der ROI ist nicht so binär messbar wie bei PMS-Fristen, aber klarer als bei indirekten Prozessverbesserungen.
Skalierbarkeit, mittel (3/5) Ein konfiguriertes Usability-Engineering-System kann auf weitere Produkte übertragen werden, aber Usability Engineering ist produktspezifisch. Jedes neue Produkt hat neue Aufgaben, neue Nutzerprofile, neue kritische Interaktionen. Das System spart Zeit bei gleichartigen Produktkategorien (ähnliche Geräteklassen, ähnliche Nutzergruppen), aber die Konfiguration muss für jede neue Produktfamilie angepasst werden.
Richtwerte, stark abhängig von Produktkomplexität, Anzahl kritischer Aufgaben und Testumfang.
Was das System konkret macht
KI-Unterstützung für Usability Engineering greift an drei Stellen an:
1. Transkription und Strukturierung von Testdaten Videoaufzeichnungen und Audio-Notizen aus Usability-Tests können mit Automatisierung durch Transkriptions-KI (wie Whisper oder vergleichbare Dienste) in Text umgewandelt werden. Dieser Text kann dann nach vordefinierten Kategorien (Aufgabe, Fehlerart, Reaktion des Probanden, Workaround) sortiert werden, erheblich schneller als manuelles Durchschauen von Videomaterial.
2. Usability-Problem-Kategorisierung und Schweregradbewertung Auf Basis der strukturierten Testdaten kann ein KI-Assistent, mit klar definierten Bewertungskriterien, Beobachtungen in die üblichen Kategorien sortieren: Benutzungsfehler (Use Error, so heißt der Begriff in der deutschen Fassung der IEC 62366-1), Beinahe-Fehler (Close Call), Anwendungsschwierigkeit (Use Difficulty) und abnormale Benutzung (Abnormal Use), die IEC 62366-1 anders behandelt als einen Benutzungsfehler. Beinahe-Fehler und Anwendungsschwierigkeit sind keine Definitionen der Norm, sondern Auswertungskategorien aus der Human-Factors-Praxis. Für jeden identifizierten Fehler kann die KI einen Schweregrad-Vorschlag generieren, basierend auf den im Testprotokoll dokumentierten Konsequenzen, zur menschlichen Überprüfung und finalen Bewertung.
3. Berichtsgenerierung und Rückverfolgbarkeits-Dokumentation Der Usability Engineering Summary Report folgt einer definierten Struktur: Zusammenfassung der Testmethode, Auflistung aller kritischen Aufgaben, Ergebnisse je Aufgabe (Task Completion Rate, Use Errors), Bewertung jedes Usability-Problems, Schlussfolgerung zur Restrisikobewertung. KI kann aus den strukturierten Daten diesen Bericht als Entwurf generieren, mit direkten Verweisen auf die zugehörigen Testprotokolldaten.
Der wichtigste Effekt: Inkonsistenzen werden früher sichtbar. Wenn die KI-Kategorisierung zeigt, dass ein Use Error in Session 7 anders klassifiziert wurde als ein identisches Ereignis in Session 12, weil die Tester unterschiedliche Sprache verwenden, kann das behoben werden, bevor der Notified Body es findet.
Konkrete Werkzeuge, was wann passt
Whisper (open source von OpenAI), Für die Transkription von Videoaufzeichnungen und Audio-Notizen aus Testsessions. Läuft lokal, keine Cloud-Übertragung, EU-DSGVO-konform. Erfordert technisches Setup, aber für Datenschutz-sensible Usability-Daten mit Patientenbeteiligung die sichere Wahl.
Claude , Für die strukturierte Auswertung von Testprotokollen und die Erstellung von Berichtsentwürfen. Starke Fähigkeiten bei der Kategorisierung und Klassifizierung von Freitext-Daten. Für Testdaten nur im Team-Tarif mit Auftragsverarbeitungsvertrag, nicht im privaten Pro-Abo, und nur pseudonymisiert. Team gibt es ab zwei Plätzen.
Greenlight Guru , Das eQMS bietet strukturierte Workflows für Human Factors und Design Controls mit Traceability zwischen Testprotokollen und Risikoregister. Für Unternehmen, die ohnehin Greenlight Guru für ihr QMS nutzen, der naheliegendste Weg, alles in einem System. Nachteil: keine automatische Transkription oder KI-gestützte Analyse von Rohdaten.
Formwork von OpenRegulatory , Für Startups und kleine Hersteller: Die kostenlose Community Edition ermöglicht strukturierte Dokumentenführung für das Usability Engineering File. Sie ist laut unserer Toolseite auf 10 Dokumente und 10 Records begrenzt, das reicht für ein UEF, aber nicht zusätzlich für ein ganzes QMS. Keine KI-Analyse-Features, aber als strukturiertes Dokumentenmanagement ein sinnvoller Einstieg.
Spezialisierte Human-Factors-Consulting-Dienste, Für einmalige summative Evaluationen ist es oft effizienter, eine externe Human-Factors-Firma zu beauftragen, die eigene Tools mitbringt, statt für eine einzelne Studie eine eigene Infrastruktur aufzubauen. Ab wann sich ein eigener Workflow lohnt, hängt an der Zahl der Studien im Jahr. Eine gemessene Schwelle kennen wir nicht, die Kostenaufstellung unten zeigt, womit du selbst rechnest.
Zusammenfassung: Wann welcher Ansatz
- Transkription von Testsessions, Datenschutz-sensibel → Whisper (lokal)
- Auswertung strukturierter Protokolldaten, Berichtsentwurf → Claude Team oder ChatGPT Business, jeweils mit AVV
- Integriertes QMS + Human Factors + Risikoregister → Greenlight Guru
- Startup, erstes Produkt, kein Tool-Budget → Formwork (kostenlos) + KI-Assistent
- Einmalige summative Evaluation → externe Human-Factors-Consulting
Rechtliche Besonderheiten
IEC 62366-1 ist unter der MDR nicht harmonisiert. Die Liste harmonisierter Normen zur MDR im Durchführungsbeschluss (EU) 2021/1182 führt sie auch in der konsolidierten Fassung vom 17.06.2026 nicht. Die Vermutungswirkung nach Art. 8 MDR gibt sie deshalb nicht. Praktisch ändert das wenig: Benannte Stellen erwarten die Norm als Stand der Technik für die Gebrauchstauglichkeitsanforderungen aus Anhang I, und wer davon abweicht, muss den Nachweis anders führen. Der Notified Body prüft das UEF explizit.
Zwei Fehler, die KI-Unterstützung nicht ausgleichen kann:
-
Falsche Probandenauswahl: Die summative Bewertung muss mit tatsächlichen repräsentativen Nutzern durchgeführt werden, d. h. echte medizinische Fachpersonen oder Laienanwender, je nach Zweckbestimmung. Simulierte Nutzer oder Mitarbeitende des Herstellers sind nicht akzeptabel. KI kann die Dokumentation dieser Tests verbessern, aber nicht die Tests selbst ersetzen oder korrigieren.
-
Abgeleitete Schweregradbewertung ohne Verknüpfung zur Risikoanalyse: IEC 62366-1 verlangt, dass Usability-Probleme mit sicherheitsbezogener Relevanz mit der Risikoanalyse nach ISO 14971 verknüpft werden. Ein Usability-Problem, das das Risikobild des Produkts verändert, muss die Risikoakte aktualisieren. KI kann diese Verlinkung vorschlagen, aber die fachliche Entscheidung, ob ein Use Error eine neue Risikobewertung auslöst, liegt beim Regulatory-Team.
Datenminimierung vor externen KI-Diensten: Usability-Tests mit Probanden generieren personenbezogene Daten (Videoaufnahmen, Testprotokolle mit Probandenidentifikatoren), bei Patienten als Laienanwendern oft auch Gesundheitsdaten nach Art. 9 DSGVO. Bevor Texte in Cloud-KI-Dienste gehen, Patientennamen, Krankenhausnamen und andere identifizierende Informationen entfernen. Pseudonymisierte Daten bleiben trotzdem personenbezogen (Erwägungsgrund 26 DSGVO), solange bei dir die Zuordnungsliste liegt. Der Dienst braucht deshalb einen Auftragsverarbeitungsvertrag, egal wie gründlich pseudonymisiert wurde.
Datenschutz und Datenhaltung
Usability-Tests mit medizinischen Anwendenden oder Patienten erzeugen personenbezogene Daten. Das ist der sensibelste Datenschutz-Aspekt in diesem Anwendungsfall.
Die Empfehlung lautet klar: Transkription lokal, Analyse cloud-optional
- Videomaterial und Rohaudio auf lokalen Systemen mit Whisper transkribieren, keine Übertragung in externe Cloud
- Transkripte pseudonymisieren (Probanden-IDs statt Namen, Klinikname entfernen)
- Pseudonymisierte Texte dann nur in Tarife mit Auftragsverarbeitungsvertrag geben, also Claude Team, ChatGPT Business oder die API, nicht in private Plus- oder Pro-Abos. Pseudonymisierung senkt das Risiko, macht die Daten aber nicht anonym
- Für KI-Tools, die in Firmensystemen betrieben werden (z. B. Azure OpenAI im EU-Rechenzentrum): direktere Nutzung möglich, aber AVV-Abschluss bleibt Pflicht
Mit meddevo oder Formwork als EU-basierter Dokumentationsplattform entfällt die Frage nach US-Datentransfer, aber die Pseudonymisierung der Rohdaten bleibt trotzdem sinnvoll.
Klingt das nach eurem Alltag? Ob sich dieser Use Case bei euch rechnet, klären wir im Erstgespräch: 30 Minuten, kostenlos.
Erstgespräch anfragenWas es kostet, realistisch gerechnet
Einmalige Einrichtungskosten
- Konfiguration des Transkriptions-Workflows (Whisper lokal): 5–10 Stunden Setup, primär interne IT-Zeit
- Erstellung von Testprotokoll-Vorlagen und Kategorisierungs-Schemata: 10–20 Stunden Regulatory-Zeit
- Entwicklung des KI-Prompts für Protokollauswertung: 3–8 Stunden
- Bei eQMS-Integration (Greenlight Guru): Onboarding und Design-Controls-Konfiguration 10.000–30.000 Euro. Wer Greenlight Guru noch nicht nutzt, zahlt zusätzlich die Lizenz, laut unserer Toolseite ab rund 25.000 bis 35.000 US-Dollar im Jahr bei zwei bis drei Jahren Mindestlaufzeit. Das rechnet sich über Usability allein nicht.
Ohne eQMS sind das zusammen 18 bis 38 interne Stunden, also rund 20 bis 40.
Laufende Kosten (monatlich)
- Whisper: kostenlos (open source, selbst gehostet)
- Claude Team für die Auswertung: ab zwei Plätzen, also 2 mal 25 US-Dollar im Monat. ChatGPT Business kostet je Platz ebenso 25 US-Dollar, ebenfalls ab zwei Plätzen.
- Greenlight Guru (wenn ohnehin im Einsatz): enthaltene Funktion, kein Aufpreis
- Externer Usability-Consultant für inhaltliche Überprüfung: 120–200 Euro/Stunde, 5–15 Stunden je Bewertungszyklus, also 600 bis 3.000 Euro je Studie
Was du dagegenrechnen kannst Externe Human-Factors-Consulting für eine vollständige summative Bewertung: 8.000 bis 20.000 Euro je Produkt. Wie viel davon wegfällt, wenn dein Team die Strukturierungsarbeit mit KI selbst erledigt, hat niemand gemessen, und die Berater bestimmen ihren Umfang selbst. Kassenwirksam ist nur, was du beim nächsten Angebot tatsächlich herausverhandelst, abzüglich der 600 bis 3.000 Euro für die externe Prüfung der KI-Auswertung. Die internen 27 bis 55 Stunden sind nur dann Geld, wenn dafür Überstunden oder eine Zusatzkraft wegfallen. Die Rechnung für den schlanken Weg geht auf, sobald die wegfallenden Beraterstunden die 20 bis 40 internen Einrichtungsstunden, 12 mal 50 US-Dollar Tarif im Jahr und die externe Prüfung decken. Mit eQMS-Integration geht sie über Usability allein nicht auf.
Wie du den Nutzen tatsächlich misst Stundenbuch führen: Wie lange dauert die Auswertung einer Testsession (Transkription, Kategorisierung, Bewertung) vor und nach der KI-Einführung? Wie viele Notified-Body-Rückfragen zu Usability-Themen gab es in den letzten 3 Produkteinreichungen? Wie viele Stunden wurden für externe Human-Factors-Consultants bezahlt? Diese Zahlen jetzt dokumentieren, und in 12 Monaten vergleichen.
Typische Einstiegsfehler
1. Die Testprotokoll-Struktur nicht vorab standardisieren. KI-Auswertung ist nur so gut wie die Eingangsdaten. Wenn jeder Beobachter in Testsessions anders protokolliert, unterschiedliche Felder, unterschiedliche Terminologie, unterschiedliche Detailtiefe, kann KI diese Heterogenität nicht zuverlässig harmonisieren. Der erste Schritt vor jeder Automatisierung: ein einheitliches Testprotokoll-Template definieren, das alle Beobachter verbindlich verwenden.
2. KI als Entscheider für die Schweregradbewertung einsetzen. Ein KI-Assistent kann Vorschläge für die Schweregradbewertung von Usability-Problemen machen, basierend auf definierten Kriterien. Aber die Entscheidung, ob ein Use Error ein sicherheitsrelevantes Risiko darstellt, ist eine inhaltliche und regulatorisch relevante Entscheidung, die eine fachkundige Person mit Kenntnis des Produkts, der Nutzergruppe und der klinischen Konsequenzen treffen muss. KI berät, Mensch entscheidet.
3. Video-Rohmaterial direkt in Cloud-Services laden. Videoaufnahmen aus Usability-Tests enthalten in der Regel Bildaufnahmen von Personen (Probanden) und potenziell klinische Umgebungen (Krankenhausräume, Geräte mit Patientendaten). Das direkte Hochladen in Cloud-Dienste verletzt in der Praxis fast immer DSGVO-Anforderungen. Schritt zwei nicht vor Schritt eins: immer zuerst pseudonymisieren und Gesichter/Identifikatoren entfernen.
4. Das UEF erst nach der Produktentwicklung schreiben. Der häufigste Fehler überhaupt im Usability Engineering: Das Usability Engineering File wird rückwirkend zusammengestellt, statt begleitend während der Entwicklung aufgebaut zu werden. IEC 62366-1 verlangt einen prozessbegleitenden Ansatz, Formative Evaluation während der Entwicklung, summative Bewertung am Ende. KI kann nachträgliche Strukturierung erleichtern, aber ein Notified Body erkennt retrospektiv erstellte Dokumente oft an fehlenden Zeitstempeln und Versionierungen.
Was mit der Einführung wirklich passiert, und was nicht
In der Praxis begegnen Human-Factors-Projekte zwei typischen Widerstands-Mustern:
Das Erfahrungs-Silo-Problem: In mittelständischen Medizintechnikunternehmen gibt es oft eine Person, die alle summativen Bewertungen durchgeführt hat und das UEF in ihrer Systematik kennt. Diese Person ist entscheidend, nicht als Widerstandspunkt, sondern als Wissensträger. Ihr Kategorisierungssystem, ihre Bewertungskriterien müssen in das KI-Prompt und die Konfiguration überführt werden. Wer das überspringt und ein generisches System einrichtet, bekommt ein System, das gut klingt, aber an den entscheidenden Stellen (Schweregradbewertung, Risikoverbindung) nicht das tut, was erfahrungsgemäß funktioniert.
Das Skeptizismus-Problem bei externen Reviewern: Wenn ein externer Notified-Body-Reviewer eine Usability-Akte sieht, die deutlich strukturierter und konsistenter aussieht als frühere Einreichungen, kann das Fragen aufwerfen: „Wurde das wirklich so sorgfältig dokumentiert, oder wurde hier nachträglich aufgeräumt?” Die Antwort liegt in der Versionierungshistorie und in der Qualität der Primärdaten. Wenn die Rohtestprotokolle gut strukturiert sind und KI transparent als Hilfsmittel dokumentiert ist, ist das kein Problem, es ist ein Vorteil.
Was konkret hilft:
- Testprotokoll-Templates gemeinsam mit der erfahrensten Human-Factors-Person entwickeln
- Die Kategorisierungslogik der KI mit einem Vergleich gegen manuell bewertete Testdaten validieren, erst dann produktiv einsetzen
- Im UEF explizit dokumentieren, dass KI-Unterstützung für bestimmte Schritte eingesetzt wurde, mit Beschreibung der manuellen Überprüfungsschritte
Realistischer Zeitplan mit Risikohinweisen
| Phase | Dauer | Was passiert | Typisches Risiko |
|---|---|---|---|
| Protokoll-Standardisierung | Woche 1–3 | Testprotokoll-Template entwickeln, Beobachter-Training | Widerstand gegen Änderung etablierter Workflows, frühzeitig einbinden |
| Transkriptions-Setup | Woche 2–5 | Whisper lokal einrichten, Pseudonymisierungsworkflow definieren | Technisches Setup braucht IT-Unterstützung, Kapazität einplanen |
| KI-Konfiguration und Validierung | Woche 4–12 | Auswertungs-Prompt entwickeln, mit Beispieldaten testen, Kategorisierungslogik kalibrieren | Erste Ergebnisse weichen von manuellem Standard ab, Kalibrierungsiterationen einplanen |
| Pilotauswertung | Woche 10–16 | Erste echte Testsession vollständig KI-gestützt auswerten | Datenqualität der Testprotokolle schlechter als erwartet, Protokoll-Template nachschärfen |
| Produktiver Einsatz | ab Woche 14–18 | Komplette summative Evaluation mit KI-Unterstützung | Einzelne Beobachter weichen vom Protokoll ab, regelmäßige Kalibrierungssessions nötig |
Häufige Einwände, und was dahintersteckt
„Usability Engineering ist zu komplex für KI, das erfordert echtes Human-Factors-Fachwissen.” Richtig. Aber die meisten Stunden, die für Usability-Dokumentation aufgewendet werden, sind kein Fachwissen-Einsatz, sie sind Strukturierungsarbeit: Protokolle transkribieren, Felder ausfüllen, Tabellen erstellen, Entwurfstexte schreiben. Genau das übernimmt KI. Der Fachwissen-Teil, ob ein Usability-Problem sicherheitsrelevant ist, ob die Probandengruppe repräsentativ war, bleibt beim Menschen.
„Unsere Tests werden von externen Consultants durchgeführt, das betrifft uns nicht.” Selbst wenn die Tests extern durchgeführt werden: Die Dokumentation liegt beim Hersteller. Das UEF gehört zur technischen Akte und muss vom Hersteller freigegeben werden. KI-Unterstützung bei der internen Auswertung und Einbindung externer Testergebnisse ist auch dann relevant, wenn die Tests selbst ausgelagert sind.
„Wir haben nur ein Produkt, der Aufwand für eine eigene Lösung ist zu groß.” Für ein einziges Produkt mit seltenen Usability-Evaluationen ist das möglicherweise richtig. Die Alternative: einen gut konfigurierten KI-Assistenten ad-hoc für die Protokollauswertung einsetzen, ohne feste Infrastruktur. Kosten dafür: wenige Stunden Setup und für die Monate der Auswertung ein Tarif mit Auftragsverarbeitungsvertrag, bei Claude Team 2 mal 25 US-Dollar im Monat. Kein Tool-Investment, aber Zeitersparnis bei der Auswertung.
Woran du merkst, dass das zu dir passt
- Usability-Testauswertung bindet regelmäßig mehr als eine Arbeitswoche Kapazität pro Studie
- Das Team führt formative oder summative Evaluationen für mehr als ein Produkt pro Jahr durch
- Rückfragen vom Notified Body betrafen inkonsistente Schweregradbewertungen oder fehlende Rückverfolgbarkeit im UEF
- Das Protokollierungs-System variiert je nachdem, wer die Testsession beobachtet, keine einheitlichen Vorlagen
- Videomaterial liegt unausgewertet auf einem Server, weil die Kapazität für systematische Auswertung fehlt
Wann es sich (noch) nicht lohnt, drei harte Ausschlusskriterien:
-
Klasse-I-Produkte ohne sicherheitsrelevante Nutzerschnittstelle. Für einfache Klasse-I-Geräte ohne kritische Nutzungsszenarien sind die Usability-Anforderungen weniger umfangreich, der Einrichtungsaufwand eines strukturierten Systems ist dort nicht gerechtfertigt.
-
Noch keine Usability-Engineering-Prozesse etabliert. KI-Unterstützung setzt voraus, dass der Grundprozess, wer führt welche Tests durch, welche Dokumente entstehen, bereits definiert ist. Wenn das Unternehmen noch kein UEF-Template hat und nie systematisch nach IEC 62366-1 vorgegangen ist, ist die erste Priorität der Aufbau des Prozesses, nicht seine Automatisierung.
-
Kein dediziertes Human-Factors-Wissen intern oder extern. Die inhaltliche Qualität der summativen Bewertung, ob die richtigen Probanden ausgewählt wurden, ob kritische Aufgaben vollständig abgedeckt sind, ob Use Errors korrekt klassifiziert werden, kann KI nicht sicherstellen. Ohne eine fachkundige Person, die diese Entscheidungen trifft, produziert das System konsistente, aber möglicherweise inhaltlich falsche Dokumente.
Das kannst du heute noch tun
Starte mit der Auswertung von drei abgeschlossenen Testprotokollen aus einem zurückliegenden Usability-Test. Strukturiere die Rohdaten in eine einfache Tabelle, ersetze Namen, Klinik und Gesundheitsangaben durch neutrale Kürzel und nutze einen Tarif mit Auftragsverarbeitungsvertrag, nicht dein privates Abo. Dann verwende diesen Prompt:
Mitarbeiter:in
KI-Assistent
Quellen & Methodik
- IEC 62366-1:2015/Amd 1:2020: Internationale Norm „Medical devices, Application of usability engineering to medical devices”, verfügbar über IEC-Webstore und DIN.
- Anforderungen Usability Engineering File (UEF): Greenlight Guru, „IEC 62366: What You Need To Know About Usability Engineering” (2024); MDX CRO, „IEC 62366 Usability Engineering for Medical Devices: Complete Guide” (2026).
- Auswertungsaufwand 40–80 Stunden und Zeitersparnis: Annahme dieser Seite, keine Messung. Hergeleitet aus der Videomenge einer summativen Studie mit 15 Probanden, siehe Fußnote unter der Vergleichstabelle.
- Kosten externe Human-Factors-Consultants: Eigene Einschätzung auf Basis zugänglicher Tagessätze, keine veröffentlichte Erhebung.
- Pseudonymisierung und Personenbezug: Verordnung (EU) 2016/679 (DSGVO), Art. 4 Nr. 5 (Begriff der Pseudonymisierung), Art. 25 (Datenschutz durch Technikgestaltung), Erwägungsgrund 26 (pseudonymisierte Daten bleiben personenbezogen), Art. 28 (Auftragsverarbeitung).
- Keine MDR-Harmonisierung von IEC 62366-1: Durchführungsbeschluss (EU) 2021/1182 über harmonisierte Normen für Medizinprodukte, konsolidierte Fassung vom 17.06.2026 (eur-lex.europa.eu, abgerufen am 19.09.2026). EN 62366-1 steht nicht in der Liste; Vermutungswirkung nach Art. 8 MDR nur für gelistete Normen.
Du willst wissen, wie ihr eure bestehenden Usability-Testprotokolle schnell in eine IEC-62366-konforme Struktur bringen könnt? Meld dich, wir schauen es uns gemeinsam an.