Blog

Autor: Dr.-Ing. Marcus Jenke

Datenschutz in Usability-Studien von Anfang an planen

Hinweis

Dieser Beitrag ist eine fachliche Einordnung aus Sicht des Usability Engineering. Er stellt keine Rechtsberatung dar.

1 Warum Datenschutz in Usability-Studien zur Studienarchitektur gehört

In vielen Entwicklungsprojekten werden zuerst Forschungsfragen, Benutzergruppen, Aufgaben und Nutzungsszenarien festgelegt. Datenschutz in Usability-Studien rückt oft erst in den Blick, wenn die Rekrutierung startet. Bis dahin ist bereits viel entschieden:

  • welche Methode eingesetzt wird,
  • welche Benutzergruppen teilnehmen,
  • ob online, im simulierten Nutzungskontext oder im realen Umfeld getestet wird,
  • welche Kameras, Plattformen und Beobachtungsräume vorgesehen sind,
  • wer live zuschaut und wer später Aufzeichnungen erhält.

Jede dieser Entscheidungen verändert, welche personenbezogenen Daten entstehen und wer sie sieht. Drei Beispiele zeigen, wie schnell das passiert: Ein zusätzliches internationales Team möchte kurz vor Studienbeginn live beobachten. Die Videokonferenzplattform aktiviert eine automatische Transkription. Ausgewählte Videosequenzen sollen später in einer internen Schulung gezeigt werden. In allen drei Fällen verändern sich Empfängerkreis, beteiligte Dienstleister oder Verarbeitungszweck.

Die Datenschutz-Grundverordnung (DSGVO) nennt in Art. 5 unter anderem Rechtmäßigkeit, Transparenz, Zweckbindung, Datenminimierung, Speicherbegrenzung sowie Integrität und Vertraulichkeit als Grundsätze. Diese Grundsätze erfüllt keine Unterschrift. Sie müssen in der Art, wie die Studie aufgebaut ist, umgesetzt sein.

Teilnehmerinformation und Einwilligung dokumentieren das Datenschutzkonzept. Sie ersetzen es nicht.

Perspektivwechsel: Was Teilnehmende wissen wollen

Perspektivwechsel

Betrachten Sie die Studie einmal aus Sicht einer Pflegefachkraft oder einer Ärztin, die für eine Studie angefragt wird. Vor einer Zusage stellen sich Teilnehmende berechtigterweise ganz praktische Fragen: Wer sieht mich während der Session? Wird mein Gesicht aufgezeichnet oder nur meine Hände? Wer bekommt die Aufnahme, und wie lange wird sie gespeichert? Erfährt der Hersteller meinen Namen oder meinen Arbeitgeber?

Diese Fragen lassen sich nur ehrlich beantworten, wenn das Studienteam die Antworten vorher kennt. Beteiligung braucht Transparenz. Wer seine Praxiserfahrung in eine Studie einbringt, soll verstehen, wozu seine Einschätzung dient und was mit seinen Daten geschieht. Diese Klarheit ist nicht nur eine Pflicht, sondern Teil der Studienqualität: Teilnehmende, die wissen, woran sie sind, können sich auf die Aufgaben konzentrieren.

2 Warum „User Study“ keine Einordnung ist

„User Study“ ist ein Sammelbegriff. Er kann ein exploratives Interview, eine Kontextbeobachtung, eine formative Usability Evaluation, eine summative Usability Evaluation, eine Post-Market-Aktivität oder eine klinische Prüfung bezeichnen. Diese Aktivitäten unterscheiden sich nicht nur in der Methode. Sie können auch unterschiedliche regulatorische, ethische und datenschutzrechtliche Anforderungen auslösen.

Eine formative Evaluation dient dazu, während der Entwicklung Stärken und Schwächen der Benutzungsschnittstelle sowie mögliche Anwendungsfehler zu erkennen. Eine summative Evaluation beziehungsweise Human-Factors-Validierung liefert dagegen an einem weitgehend finalen Design Nachweise zur sicheren Nutzung durch repräsentative Benutzer. Beide sind Teil des risikobasierten Prozesses nach IEC 62366-1 und der FDA Human Factors Guidance.

Ob eine Studie mit Menschen eine klinische Prüfung im Sinne der MDR ist, hängt nicht von ihrem Namen ab. Die Medical Device Coordination Group beantwortet in MDCG 2021-6 ausdrücklich die Frage, ob Usability-Tests klinische Prüfungen sind: Je nach Studiendesign können sie unter die Definition fallen oder nicht. Entscheidend sind Zweck, Umfang und die Frage, ob Teilnehmende produktbezogenen Risiken ausgesetzt werden. Wenn Menschen beteiligt sind, empfiehlt das Dokument, zu begründen und zu dokumentieren, warum ein Usability-Test keine klinische Prüfung ist.

Die Bezeichnung „User Study“ beantwortet also noch nicht,

  • ob nur Nutzungshandlungen beobachtet oder klinische Daten erhoben werden,
  • ob das Produkt tatsächlich an Patient:innen angewendet wird,
  • ob Teilnehmende produktbezogenen Risiken ausgesetzt sind,
  • ob eine Ethikkommission oder Behörde einzubeziehen ist.

Die Bezeichnung einer Studie ersetzt nicht ihre Einordnung. Entscheidend sind Ziel, Produktstatus, Durchführung und tatsächliche Datenerhebung.

3 Studienarten und ihre typischen Datenschutzfragen

3.1 Explorative Studien und Kontextanalysen

Interviews, kontextuelle Interviews, Arbeitsplatzbeobachtungen und Workflow-Analysen helfen, den Nutzungskontext zu verstehen. Schon hier entstehen personenbezogene Daten. Angaben zu Fachgebiet, Berufserfahrung, Funktion und Einrichtung können eine Person in spezialisierten Bereichen indirekt identifizierbar machen.

Bei Beobachtungen in Kliniken und Praxen wird zudem ein informationsreicher Arbeitskontext sichtbar: Patientendaten auf Monitoren, Dokumente, Namensschilder, Gespräche und zufällig anwesende Personen. Vor Beginn sollte deshalb feststehen, welche Bereiche beobachtet werden, ob Aufnahmen nötig sind und wie mit unbeabsichtigt erfassten Informationen umgegangen wird.

3.2 Formative Evaluationen

Formative Studien sind iterativ. Erkenntnisse aus den ersten Sessions verändern das Design oder werfen neue Fragen auf. Diese Flexibilität ist methodisch gewollt, muss sich aber im Datenschutzkonzept wiederfinden. Kommen nach den ersten Sessions Videoaufnahmen, weitere Beobachtende, Transkriptionen oder neue Screener-Fragen hinzu, verändert sich der Datenfluss.

Planen Sie deshalb vorab, welche Anpassungen vom ursprünglichen Studienzweck abgedeckt sind und ab wann Teilnehmerinformation oder Einwilligung erneut geprüft werden.

3.3 Summative Evaluationen und Human-Factors-Validierung

Summative Studien brauchen eine hohe Nachvollziehbarkeit. Daraus folgt aber nicht, dass alle Beteiligten die Identität der Teilnehmenden kennen müssen. Ein belastbares Datenkonzept kann zum Beispiel vorsehen:

  • Teilnehmende werden über Studien-IDs geführt.
  • Identitäts- und Studiendaten werden getrennt gespeichert.
  • Kontaktdaten bleiben beim Teilnehmermanagement.
  • Das Entwicklungsteam erhält anonymisierte oder zusammengefasste Ergebnisse und Beobachtungsprotokolle ohne Namen.
  • Berichte enthalten aggregierte Angaben zur Stichprobe.

Pseudonymisiert ist nicht anonym

Pseudonymisierte Daten bleiben nach DSGVO personenbezogene Daten, weil sie sich mit zusätzlichen Informationen wieder einer Person zuordnen lassen (Art. 4 Nr. 5, Erwägungsgrund 26). Erst wenn eine Reidentifizierung nicht mehr vernünftigerweise möglich ist, gelten Daten als anonym. Gesicht und Stimme in Videos sind in der Regel identifizierend, auch ohne Namen.

Die zentrale Frage lautet: Welche Merkmale sind nötig, um Eignung und Repräsentativität der Stichprobe nachvollziehbar zu machen, ohne den Personenbezug unnötig auszuweiten? Regulatorische Nachvollziehbarkeit und Datenschutz sind keine Gegensätze. Sie brauchen eine passende Datenstruktur.

3.4 Real-Use-Aktivitäten

„Real Use“ ist keine eigene regulatorische oder datenschutzrechtliche Kategorie. Eine Real-Use-Aktivität kann eine Kontextbeobachtung, eine Post-Market-Aktivität, eine PMCF-Aktivität oder unter bestimmten Voraussetzungen eine klinische Prüfung sein. Früh zu klären ist, ob das Produkt tatsächlich an Patient:innen angewendet wird, ob es CE-gekennzeichnet und innerhalb seiner Zweckbestimmung im Einsatz ist und ob Behandlungsdaten oder nicht rekrutierte Personen erfasst werden.

Eine Studie kann methodisch wie ein Usability-Test aussehen und regulatorisch dennoch weitergehende Anforderungen auslösen.

4 Drei Settings, drei Datenschutzprofile

4.1 Online-Studien

Online-Studien erlauben oft eine klare Trennung zwischen Teilnehmenden und Entwicklungsteam: Studien-IDs statt Namen, begrenzter Beobachterkreis, kontrollierte Bereitstellung von Aufzeichnungen. Gleichzeitig bringen sie eigene Risiken mit: externe Plattformen, automatische Cloud-Aufzeichnung und Transkription, Unterauftragnehmer, Serverstandorte außerhalb der EU, internationale Beobachtende, Screenshots und private Informationen im Hintergrund des Teilnehmenden.

Vor Beginn sollten Sie deshalb klären:

  • Welche Plattform wird eingesetzt, und wo speichert sie Daten?
  • Welche Unterauftragnehmer sind beteiligt?
  • Ist automatische Aufzeichnung oder Transkription aktiviert?
  • Aus welchen Ländern greifen Beobachtende zu?
  • Sind lokale Aufzeichnungen und Screenshots ausgeschlossen?
  • Welche Informationen können beim Teilen des Bildschirms sichtbar werden?

Online heißt also nicht automatisch datenschutzfreundlich. Entscheidend sind Plattform, Konfiguration, Empfängerkreis und tatsächlicher Datenfluss.

4.2 Simulated-Use-Studien

Im Usability Lab oder in einer simulierten klinischen Umgebung lässt sich vieles gezielt gestalten. Kameraperspektiven werden geplant, Patientendaten durch simulierte Datensätze ersetzt, Teilnehmende und Beobachtende räumlich getrennt und Beobachtende namentlich freigegeben. Die zentralen Planungsfragen lauten: Muss das Gesicht aufgezeichnet werden, oder genügen Hände, Produkt und Benutzeroberfläche? Ist Audio für die Ursachenanalyse nötig? Welche Aufzeichnungen erhält der Auftraggeber? Eine Trennung von Identität und Beobachtung ist auch im Labor möglich, wenn das Research-Team die Sessions durchführt und Live-Beobachtung sowie Aufzeichnungen nach festen, vertraglich vereinbarten Regeln erfolgen.

4.3 Real-Use-Studien im klinischen Umfeld

Kliniken und Praxen lassen sich nicht vollständig isolieren. Zusätzliche Risiken entstehen durch Patientendaten auf Displays, erkennbare Stationen, vertrauliche Gespräche und berufliche Abhängigkeiten. Bewährte Schutzmaßnahmen sind definierte Beobachtungsbereiche, begrenzte Kameraperspektiven, Abdeckung patientenbezogener Bildschirminhalte, Verzicht auf Ton, wo er nicht gebraucht wird, und klare Ansprechpartner in der Einrichtung. Der Schutz liegt hier weniger in Verblindung als in Transparenz, Zweckbegrenzung und Kontrolle der tatsächlich erhobenen Daten.

Klassischer AnsatzNeuer Ansatz
Einwilligungsvorlage auswählen und Studiendaten eintragenDatenfluss der Studie planen und daraus die Dokumente ableiten
Datenschutz wird vor der Rekrutierung „erledigt“Datenschutz begleitet jede Änderung an Setting, Plattform und Beobachtung
Vollständige Videos für alle BeteiligtenAufzeichnung und Zugriff nach tatsächlichem Analysebedarf
Online gilt als unkritisch, vor Ort als kritischJedes Setting bekommt ein eigenes Schutzkonzept
Teilnehmerinformation als PflichtdokumentTeilnehmerinformation als ehrliche Antwort auf die Fragen der Teilnehmenden

5 Der Studienlebenszyklus als Datenfluss

Datenschutzentscheidungen fallen nicht nur in der Session. Sie begleiten die gesamte Studie.

5.1 Kontakt und Rekrutierung

Der erste Datenfluss beginnt lange vor der Session. Woher stammen die Kontaktdaten? Wer spricht die Person an, und welche Informationen erhält sie dabei? Wie kann sie weiteren Kontakt ablehnen? Werden Daten nicht direkt bei der Person erhoben, bestehen nach Art. 14 DSGVO zusätzliche Informationspflichten, unter anderem zur Herkunft der Daten.

5.2 Screening und Auswahl

Screener sind oft der detaillierteste Datensatz einer Studie. Sie erfassen Qualifikation, Erfahrung, Tätigkeitsumfeld, Produktkenntnis und manchmal gesundheitliche Ausschlusskriterien. Bei hochspezialisierten Healthcare Professionals kann schon die Kombination weniger beruflicher Merkmale eine Person identifizierbar machen. Zu entscheiden ist deshalb, welche Kriterien wirklich nötig sind, wer vollständige Antworten sieht, ob der Auftraggeber einzelne Personen auswählt und was mit den Daten nicht ausgewählter Personen passiert.

Rekrutierung ist Teil der Studienqualität

Ein guter Screener fragt nur, was für die Auswahl repräsentativer Teilnehmender nötig ist. Das schützt die Daten der Bewerbenden und verbessert gleichzeitig die Auswahl. Mehr dazu im Artikel HCP Recruiting für Usability Tests.

5.3 Durchführung

Vor der ersten Session sollten Beobachtungs- und Aufzeichnungskonzept feststehen: Wer moderiert, wer beobachtet, wird live gestreamt? Werden Bild, Stimme oder Bildschirm aufgezeichnet, und welche Bildausschnitte sind sichtbar? Können Dritte oder Patienteninformationen erfasst werden?

5.4 Analyse und Datenübergabe

Bei der Übergabe zeigt sich, ob der Informationsbedarf früh genug geklärt wurde. Erhält der Auftraggeber Rohdaten oder Ergebnisse? Bleiben Videos beim Research-Partner? Wer hat Zugriff auf die Zuordnungsliste, und über welchen Kanal werden Daten übermittelt? Soll ein identifizierbares Video an weitere Empfänger gehen, muss das vor der Aufnahme geklärt und den Teilnehmenden mitgeteilt sein.

5.5 Aufbewahrung, Löschung und weitere Nutzung

Nach der Studie ist festzulegen, welche Daten aufbewahrt, gelöscht oder anonymisiert werden und ob eine weitere Nutzung geplant ist. Die Aufnahme in ein Testpanel für künftige Studien ist ein eigener Zweck. Die Zustimmung zu einer einzelnen Studie umfasst nicht automatisch die dauerhafte Speicherung für spätere Einladungen.

Wer den Lebenszyklus kennt, kann die richtigen Fragen in der richtigen Reihenfolge stellen. Genau dafür dient der folgende Entscheidungspfad.

6 Entscheidungspfad: In sieben Fragen zum passenden Konzept

Ein Datenschutzkonzept sollte nicht aus einer bevorzugten Vorlage entstehen, sondern aus dem tatsächlichen Erkenntnisbedarf.

  1. Welche Erkenntnisse werden tatsächlich gebraucht? Aggregierte Ergebnisse, Beobachtungsdaten, Video oder einzelne Teilnehmerprofile? Je genauer der Bedarf beschrieben ist, desto gezielter lassen sich die Daten bestimmen.
  2. Muss der Auftraggeber einzelne Teilnehmende identifizieren? Reichen aggregierte Angaben zu Qualifikation und Erfahrung, kann die Identität beim Research-Partner bleiben.
  3. Welche Rohdaten sind nötig? Für viele Fragen genügen Beobachtungsprotokolle, Aufnahmen von Händen und Produkt, Bildschirmaufzeichnungen oder ausgewählte Sequenzen. Nicht jede Analyse braucht dieselbe Identifizierbarkeit.
  4. Wer entscheidet über Auswahl, Aufzeichnung, Empfänger und Aufbewahrung? Diese Entscheidungen bestimmen die datenschutzrechtlichen Rollen. Teil 2 dieser Reihe geht darauf ausführlich ein.
  5. Welche Trennung ist im gewählten Setting möglich? Online ist eine starke Trennung oft einfach. Bei Real-Use-Studien vor Ort ist eine Verblindung in der Regel nicht möglich, dort gewinnen Transparenz und kontrollierte Erhebung an Gewicht.
  6. In welchen Ländern werden Daten erhoben, gespeichert und abgerufen? Relevant sind auch Plattformstandorte, Dienstleister und der Sitz der Beobachtenden.
  7. Was geschieht nach Abschluss der Studie? Löschung, Aufbewahrung, Anonymisierung und eine mögliche weitere Nutzung sollten vor Beginn feststehen.

Datenschutz entsteht nicht durch weniger Research, sondern durch präziser gestalteten Research.

Fazit

Usability-Studien brauchen reale Einblicke, und diese Einblicke erzeugen personenbezogene Daten, oft schon beim ersten Kontakt. Je realistischer das Setting, je spezialisierter die Benutzergruppe und je internationaler die Durchführung, desto wichtiger wird eine frühe Planung des Datenflusses.

Eine belastbare Planung beginnt deshalb nicht mit der Einwilligungsvorlage, sondern mit der Einordnung der Studie, dem Setting und der Frage, wer welche Daten wirklich braucht. Daraus ergeben sich Teilnehmerinformation und Einwilligung fast von selbst. Und die Teilnehmenden erhalten das, was sie für ihre Zusage brauchen: ehrliche und konkrete Antworten.

Bei USE-Ing. planen wir Rekrutierung, Screening und Studiendurchführung so, dass Datenfluss und Teilnehmerinformation von Anfang an zusammenpassen. Wenn Sie eine Studie mit Healthcare Professionals vorbereiten, sprechen Sie uns gern früh an.

Häufig gestellte Fragen zu Datenschutz in Usability-Studien

Nein. Laut MDCG 2021-6 hängt das vom Studiendesign ab, insbesondere von Zweck, Umfang und davon, ob Teilnehmende produktbezogenen Risiken ausgesetzt sind. Wenn Menschen beteiligt sind, sollte dokumentiert werden, warum ein Usability-Test keine klinische Prüfung ist.

Nein. Die Einwilligung beschreibt das Datenschutzkonzept, ersetzt es aber nicht. Vorher müssen Datenfluss, Empfänger, Speicherorte und Aufbewahrung geklärt sein. Nur dann kann die Teilnehmerinformation korrekt sein.

Nein. Pseudonymisierte Daten lassen sich mit Zusatzinformationen wieder einer Person zuordnen und bleiben personenbezogen. Videos mit Gesicht oder Stimme sind in der Regel identifizierend, auch ohne Namen.

Nicht automatisch. Online-Studien erleichtern die Trennung zwischen Teilnehmenden und Auftraggeber, bringen aber eigene Risiken durch Plattformen, Cloud-Aufzeichnung, Transkription und internationale Zugriffe mit.

Parallel zur Studienkonzeption, also bevor Setting, Plattform, Beobachtende und Aufzeichnungen festgelegt werden. Spätere Änderungen sollten jeweils gegen das Konzept geprüft werden.

Weiterführende Inhalte

Quellen

HCP Recruiting für Usability Tests: Warum falsche Teilnehmer zum Problem werden

1 HCP Recruiting für Usability Tests: Wenn falsche Teilnehmer zum Problem werden

Usability Tests sind ein zentraler Bestandteil des Usability Engineering Prozesses gemäß IEC 62366-1 und gelten als wesentliche Grundlage für die Bewertung der Gebrauchstauglichkeit von Medizinprodukten. Entsprechend liegt in vielen Projekten ein starker Fokus auf Studiendesign, Use Error Analyse oder die Ausgestaltung realistischer Testaufgaben.

Ein entscheidender Erfolgsfaktor wird dabei jedoch häufig unterschätzt: die Auswahl der richtigen Testpersonen im Rahmen des HCP Recruiting für Usability Tests.

In der Praxis zeigt sich immer wieder ein ähnliches Muster: Unter Zeitdruck und organisatorischen Rahmenbedingungen wird das Recruiting von Healthcare Professionals häufig nach Verfügbarkeit statt nach tatsächlicher Relevanz organisiert.

Typische Konsequenzen:

  • Studien werden mit kurzfristig verfügbaren Personen durchgeführt
  • Die Differenzierung der Zielgruppen bleibt oberflächlich
  • Relevante Nutzungskontexte werden nicht ausreichend abgebildet 
  • Kritische Unterschiede zwischen Nutzergruppen bleiben unberücksichtigt

Parallel dazu bleibt auch der reale Nutzungskontext häufig unterrepräsentiert. Damit entsteht bereits vor Beginn der eigentlichen Studie eine Abweichung zwischen Testumgebung und realer Anwendung.

Diese Vorgehensweise ist nachvollziehbar und in vielen Projekten zunächst notwendig, um Studien überhaupt durchführen zu können. Gleichzeitig führt sie jedoch zu einem strukturellen Problem: Die Qualität der Ergebnisse wird bereits im Recruiting maßgeblich vorgeprägt – häufig ohne dass dies im Projektverlauf unmittelbar sichtbar wird.

1.1 Warum falsche Teilnehmer kritisch sind

Die Aussagekraft von Usability Tests hängt unmittelbar davon ab, ob die eingebundenen Personen die tatsächlichen Nutzer eines Medizinprodukts realistisch repräsentieren. Gerade im Kontext des HCP Recruiting für Usability Tests ist diese Passung entscheidend, da sich klinische Nutzungssituationen stark unterscheiden können.

Unterschiede zwischen Healthcare Professionals zeigen sich nicht nur oberflächlich, sondern betreffen grundlegende Aspekte der Anwendung. Dazu zählen beispielsweise Entscheidungsprozesse, Arbeitsabläufe oder Prioritäten unter Zeitdruck. Eine Pflegekraft auf der Intensivstation agiert unter anderen Bedingungen als eine Pflegekraft im ambulanten Bereich; ein erfahrener Facharzt trifft andere Entscheidungen als ein Assistenzarzt in der Ausbildung.

Diese Unterschiede beeinflussen direkt, wie ein Produkt verwendet wird – und damit auch, welche Use Errors auftreten können.

Werden diese Unterschiede im HCP Recruiting nicht berücksichtigt, entstehen typische Verzerrungen, die sich erst im Nachgang der Studie wirklich zeigen:

  • Kritische Nutzungssituationen werden nicht getestet
  • Relevante Use Errors bleiben unentdeckt
  • Optimierungsmaßnahmen basieren auf Annahmen, die im realen klinischen Einsatz nicht valide sind

Auf diese Weise entsteht eine trügerische Validität. Der Usability Test liefert nachvollziehbare Ergebnisse, bildet jedoch nicht die Realität ab, in der das Produkt später eingesetzt wird. Gerade im Kontext der Medizinprodukteentwicklung kann dies weitreichende Konsequenzen haben.

Usability Engineering fuer Medizintechnik 1

1.2 Auswirkungen auf Regulierung und Risiko

Die Relevanz dieser Problematik wird besonders im regulatorischen Kontext deutlich. Im Rahmen von Human Factors Engineering und Usability Validation wird nicht nur erwartet, dass Use Errors identifiziert und bewertet werden, sondern auch, dass die zugrunde liegenden Studien unter realistischen Bedingungen durchgeführt wurden.

Sowohl FDA Guidelines als auch die IEC 62366-1 fordern explizit, dass Usability Studien mit repräsentativen Nutzergruppen und in realistischen Nutzungskontexten durchgeführt werden. Entscheidend ist dabei nicht nur die Durchführung der Tests, sondern auch die nachvollziehbare Begründung, warum genau diese Teilnehmer ausgewählt wurden.

Wenn diese Anforderungen im HCP Recruiting für Usability Tests nicht erfüllt sind, entstehen konkrete Risiken. Studienergebnisse können in ihrer Aussagekraft eingeschränkt sein, regulatorische Rückfragen treten häufiger auf und im ungünstigsten Fall müssen Studien wiederholt oder ergänzt werden. Der Aufwand verlagert sich damit von einem initial scheinbar effizienten Recruiting hin zu deutlich höheren Kosten im weiteren Projektverlauf.

Vor diesem Hintergrund verschiebt sich die Rolle von Recruiting grundlegend. Es ist nicht länger ein vorbereitender Schritt, sondern ein entscheidender Einflussfaktor auf die regulatorische Belastbarkeit und letztlich auch auf die Sicherheit des Produkts.

Der eigentliche blinde Fleck

Ein zentraler Punkt wird in vielen Projekten erst spät oder gar nicht erkannt: Nicht das Studiendesign ist die häufigste Ursache für unzureichende Ergebnisse, sondern die Auswahl der falschen Teilnehmer.

2 Warum HCP Recruiting für Usability Tests besonders schwierig ist

Die Herausforderungen im HCP Recruiting für Usability Tests & Human Factors Recruiting treten in der Praxis nur selten als isolierte Probleme einzelner Projekte auf. Vielmehr handelt es sich um ein strukturelles Thema, das sich aus den spezifischen Rahmenbedingungen des medizinischen Arbeitsumfelds ergibt. Genau diese Rahmenbedingungen unterscheiden das Recruiting von Healthcare Professionals grundlegend von klassischem UX Recruiting in anderen Branchen.

Ein zentraler Faktor ist die begrenzte Verfügbarkeit von medizinischem Fachpersonal. Healthcare Professionals arbeiten in einem Umfeld, das durch hohe Arbeitsbelastung, Zeitdruck und eine konsequente Ausrichtung auf die Patientenversorgung geprägt ist. Zusätzliche Aktivitäten wie die Teilnahme an Usability Tests müssen daher immer in bestehende klinische Abläufe integriert werden.

Diese Situation wird zusätzlich dadurch erschwert, dass der Zugang zu Healthcare Professionals meist nicht direkt erfolgt. Im Gegenteil: HCP Recruiting für Usability Tests ist häufig durch mehrstufige Zugangsstrukturen geprägt. Zwischen Studienverantwortlichen und potenziellen Teilnehmern liegen oft organisatorische Ebenen wie Klinikleitungen, administrative Prozesse oder interne Freigaben.

Neben Verfügbarkeit und Zugang stellt die Spezialisierung der Nutzergruppen eine weitere zentrale Herausforderung dar. Während Zielgruppen im Recruiting häufig auf einer abstrakten Ebene beschrieben werden, entscheidet in der Realität der konkrete Arbeitskontext über die Relevanz der Ergebnisse.

Für das HCP Recruiting von Teilnehmern für Usability Tests bedeutet das: Eine präzise Differenzierung von Nutzergruppen ist nicht optional, sondern Voraussetzung für valide Studien. Diese hohe Kontextabhängigkeit wirkt sich unmittelbar auf die Qualität von Usability Tests aus. Nur wenn Testpersonen reale Arbeitsabläufe, Entscheidungslogiken und Nutzungssituationen nachvollziehbar abbilden, lassen sich belastbare Erkenntnisse generieren.

In der Praxis entsteht daraus eine komplexe Ausgangssituation: Begrenzte Verfügbarkeit, indirekter Zugang und hohe Spezialisierung wirken gleichzeitig und verstärken sich gegenseitig. Das führt dazu, dass HCP Recruiting nur eingeschränkt planbar ist und häufig einen erheblichen Koordinationsaufwand erfordert.

Diese Dynamik macht deutlich, warum klassische Recruiting Ansätze im MedTech Kontext oft nicht ausreichen. Der eigentliche Aufwand liegt daher weniger im Recruiting selbst, sondern im Aufbau und der Nutzung von Zugangsstrukturen.

Zwischenfazit: Drei strukturelle Ursachen

Die Herausforderungen im HCP Recruiting für Usability Tests lassen sich im Kern auf drei miteinander verknüpfte Ursachen zurückführen:
• Eingeschränkte Verfügbarkeit medizinischen Fachpersonals
• Indirekter und häufig mehrstufiger Zugang zu geeigneten Teilnehmern
• Hohe Spezialisierung und Kontextabhängigkeit der Nutzergruppen
Diese Faktoren wirken nicht isoliert, sondern verstärken sich gegenseitig – und prägen damit maßgeblich die Qualität von Usability Studien.

Die Herausforderungen im HCP Recruiting für Usability Tests lassen sich im Kern auf drei miteinander verknüpfte Ursachen zurückführen: die eingeschränkte Verfügbarkeit medizinischen Fachpersonals, der indirekte und häufig mehrstufige Zugang zu Teilnehmern sowie die hohe Spezialisierung und Kontextabhängigkeit der Nutzergruppen.

Erst im Zusammenspiel dieser Faktoren wird deutlich, warum Recruiting in diesem Umfeld nicht isoliert betrachtet werden kann. Es ist kein einzelner Prozess, der optimiert werden muss, sondern ein komplexes Zusammenspiel aus Zugang, Kontextverständnis und organisatorischer Einbindung.

Vor diesem Hintergrund wird verständlich, warum viele Teams HCP Recruiting für Usability Tests primär als operativen Engpass wahrnehmen. Tatsächlich liegt die Ursache jedoch tiefer – nicht in der Durchführung, sondern in der konzeptionellen Einordnung von Recruiting.

3 Der eigentliche Fehler: Recruiting wird als Task verstanden

In vielen Projekten folgt HCP Recruiting für Usability Tests einem scheinbar klaren und etablierten Ablauf: Zunächst wird der Bedarf definiert, anschließend werden geeignete Teilnehmer gesucht, und im nächsten Schritt wird die Studie durchgeführt. Dieses Vorgehen ist in vielen Bereichen effizient und ausreichend – insbesondere dort, wo Zielgruppen leicht erreichbar und standardisiert beschreibbar sind. Im Kontext von Healthcare Professionals stößt dieses Modell jedoch schnell an seine Grenzen. Die Annahme, dass Recruiting ein klar abgegrenzter und zeitlich begrenzter Prozessschritt ist, greift hier zu kurz. Sie unterschätzt die strukturelle Komplexität, die mit dem Zugang zu medizinischen Nutzergruppen verbunden ist.

Der eigentliche Fehler liegt dabei nicht in einzelnen Recruiting Maßnahmen, sondern in der zugrunde liegenden Perspektive. HCP Recruiting für Usability Tests wird häufig als kurzfristige Aufgabe verstanden, die im Rahmen eines Projekts „gelöst“ werden kann. In der Realität ist es jedoch eng mit Rahmenbedingungen verknüpft, die weit über den eigentlichen Suchprozess hinausgehen.

Dazu gehören insbesondere gewachsene Netzwerke und Kontakte, die über längere Zeiträume aufgebaut werden müssen. Ebenso spielen Beziehungen zu Kliniken, Organisationen und einzelnen Fachpersonen eine zentrale Rolle, da sie oft den entscheidenden Zugang zu potenziellen Teilnehmern ermöglichen. Diese Zusammenhänge führen dazu, dass Recruiting im medizinischen Kontext nicht als isolierter Prozess verstanden werden kann. Es ist Teil eines übergeordneten Systems, das Zugang, Beziehung, organisatorische Rahmenbedingungen und fachliches Kontextverständnis miteinander verbindet.

Intensivpflegekraft

Internationale UX Research Ansätze unterstreichen diese Perspektive, indem sie die Qualität von Studien direkt an die Passung der Teilnehmer knüpfen. Werden im HCP Recruiting für Usability Tests unpassende oder nur teilweise geeignete Personen ausgewählt, entstehen nicht nur methodische Schwächen, sondern auch erhebliche Folgekosten – etwa durch fehlerhafte Entscheidungen oder zusätzliche Studienzyklen.

Gerade im Umfeld regulierter Produkte verstärken sich diese Effekte. Wenn kritische Nutzungssituationen nicht durch die richtigen Nutzergruppen abgebildet werden, bleiben potenzielle Risiken unentdeckt. Gleichzeitig kann die regulatorische Aussagekraft der Studie eingeschränkt sein, wenn die Auswahl der Teilnehmer nicht nachvollziehbar begründet werden kann.

Vor diesem Hintergrund wird deutlich, dass der eigentliche Engpass nicht im Recruiting selbst liegt, sondern in der fehlenden strukturellen Vorbereitung darauf. Organisationen, die HCP Recruiting für Usability Tests ausschließlich projektbasiert denken, geraten zwangsläufig in Situationen, in denen sie unter Zeitdruck auf suboptimale Lösungen angewiesen sind.

Einordnung: Vom operativen Schritt zur strategischen Fähigkeit

Die beschriebenen Herausforderungen weisen auf eine grundlegende Verschiebung hin. Recruiting entwickelt sich von einem operativen Projektbaustein zu einer eigenständigen Fähigkeit, die kontinuierlich aufgebaut und gepflegt werden muss.

Während ein operatives Verständnis darauf abzielt, kurzfristig Teilnehmer zu finden, richtet sich ein struktureller Ansatz auf den langfristigen Aufbau von Zugang. Dazu zählen stabile Netzwerke, kontinuierliche Kontaktpflege sowie ein differenziertes Verständnis relevanter Nutzergruppen.

Nicht mehr: „Wie finden wir Teilnehmer für diese Studie?“,
sondern: „Wie stellen wir sicher, dass wir dauerhaft Zugang zu den richtigen Healthcare Professionals haben?

HCP Recruiting für Usability Tests ist kein isolierter Prozessschritt, sondern eine strukturelle Voraussetzung für valide und belastbare Ergebnisse. Oder zugespitzt formuliert: Das Problem liegt selten im Recruiting selbst, sondern darin, dass es zu spät und zu isoliert gedacht wird.

4 Reframing: Vom Recruiting zum Zugang

Vor dem Hintergrund der bisherigen Betrachtungen wird deutlich, dass die Herausforderungen im HCP Recruiting für Usability Tests nicht in erster Linie durch operative Schwierigkeiten entstehen. Vielmehr liegt die Ursache auf einer konzeptionellen Ebene: in der Art und Weise, wie Recruiting in Organisationen verstanden und eingeordnet wird.

In vielen Fällen wird HCP Recruiting weiterhin als kurzfristige Aufgabe betrachtet, die im Rahmen einer konkreten Studie zu lösen ist. Diese Perspektive erscheint zunächst plausibel und entspricht klassischen Projektlogiken. Im medizinischen Kontext führt sie jedoch regelmäßig an strukturelle Grenzen. Denn die eigentliche Herausforderung besteht nicht darin, Teilnehmer zu identifizieren, sondern darin, Zugang zu den relevanten Healthcare Professionals zu erhalten.

Damit verschiebt sich der Fokus grundlegend:

Der zentrale Engpass liegt nicht im Recruiting selbst, sondern im Zugang zu den richtigen Nutzergruppen.

Dieses Reframing markiert einen entscheidenden Wendepunkt. Während ein klassisches Recruiting Verständnis auf die Durchführung einzelner Studien ausgerichtet ist, rückt ein erweitertes Verständnis den Aufbau stabiler Zugangsstrukturen in den Mittelpunkt. Es geht nicht mehr primär darum, kurzfristig Teilnehmer zu gewinnen, sondern darum, langfristig sicherzustellen, dass relevante Nutzergruppen überhaupt erreichbar sind.

4.1 Was sich durch diesen Perspektivwechsel verändert

Dieser Perspektivwechsel hat direkte Auswirkungen auf die Planung und Durchführung von Usability Tests. Er verändert nicht nur einzelne Prozesse, sondern die zugrunde liegende Logik des HCP Recruiting für Usability Tests.

Die Unterschiede lassen sich wie folgt zusammenfassen:

Klassischer AnsatzNeuer Ansatz
Fokus auf einzelne TeilnehmerFokus auf Zugang zu Nutzergruppen
projektbasierte Planungkontinuierlicher Aufbau von Netzwerken
einzelne Studie im Mittelpunktlangfristige Strategie
operative Aufgabestrukturelle Fähigkeit

Diese Gegenüberstellung zeigt, dass es nicht um eine Optimierung bestehender Prozesse geht, sondern um eine Verschiebung auf eine andere Ebene. Recruiting wird damit nicht ersetzt – sondern neu eingeordnet.

4.2 Warum dieser Perspektivwechsel notwendig ist

Die steigende Komplexität im HCP Recruiting für Usability Tests lässt sich mit klassischen Ansätzen nur noch eingeschränkt bewältigen. Begrenzte Verfügbarkeit, indirekte Zugänge und hohe Spezialisierung führen dazu, dass kurzfristige Lösungen oft unzuverlässig bleiben.

Ein strategischer Umgang mit Zugang ermöglicht es hingegen, diese Faktoren systematisch zu adressieren. Bestehende Kontakte können gezielt ausgebaut werden, Zielgruppen werden differenzierter verstanden und organisatorische Rahmenbedingungen lassen sich frühzeitig berücksichtigen. Dadurch entsteht eine stabilere Grundlage für zukünftige Usability Tests.

5 Was bedeutet das konkret? Erste Handlungsmöglichkeiten

Die Transformation von operativem HCP Recruiting hin zu einer strukturellen Fähigkeit ist kein einmaliger Schritt, sondern ein kontinuierlicher Prozess. Gleichzeitig zeigt die Praxis, dass bereits vergleichsweise kleine Anpassungen im Projektalltag einen spürbaren Einfluss auf die Qualität von Usability Tests haben können. Entscheidend ist dabei, Recruiting nicht isoliert zu betrachten, sondern die Rahmenbedingungen zu verbessern, unter denen es stattfindet.

5.1 Netzwerke frühzeitig und kontinuierlich aufbauen

Ein häufiges Muster besteht darin, dass HCP Recruiting erst dann beginnt, wenn eine Studie konkret geplant ist. In diesem Moment fehlen jedoch oft die notwendigen Zugänge, um geeignete Teilnehmer zu identifizieren. Ein nachhaltiger Ansatz setzt deutlich früher an. Netzwerke sollten nicht projektbezogen aufgebaut, sondern kontinuierlich entwickelt werden. Dabei geht es weniger um die kurzfristige Aktivierung einzelner Kontakte als um den Aufbau belastbarer Beziehungen.

In der Praxis bedeutet das beispielsweise, Kontakte aus früheren Studien aktiv weiterzuführen, Kooperationen mit klinischen Einrichtungen schrittweise auszubauen und Fachveranstaltungen gezielt zu nutzen, um Zugang zu relevanten Nutzergruppen zu entwickeln. Ein solches Netzwerk reduziert nicht nur den operativen Aufwand zukünftiger Studien, sondern erhöht auch die Wahrscheinlichkeit, tatsächlich repräsentative Healthcare Professionals einzubinden.

5.2 Zielgruppen differenziert und kontextbezogen definieren

Ein zweiter zentraler Hebel liegt in der Präzisierung der Zielgruppen. Allgemeine Kategorien wie „Ärztinnen und Ärzte“ oder „Pflegepersonal“ reichen im Kontext von HCP Recruiting für Usability Tests nicht aus, um reale Nutzungssituationen abzubilden.

Für belastbare Ergebnisse ist es notwendig, Zielgruppen entlang konkreter Nutzungskontexte zu beschreiben. Entscheidend sind dabei nicht nur demografische Merkmale, sondern insbesondere Arbeitsabläufe, Verantwortlichkeiten und Erfahrungsniveaus im Umgang mit vergleichbaren Systemen.

Eine fundierte Zielgruppendefinition berücksichtigt daher Aspekte wie typische Workflows, Nutzungssituationen sowie die Einbindung in klinische Prozesse. Diese Kriterien sollten frühzeitig im Screener abgebildet werden, da sie maßgeblich darüber entscheiden, ob die ausgewählten Teilnehmer tatsächlich repräsentativ sind.

5.3 Recruiting‑Kanäle gezielt kombinieren

Ein weiterer wichtiger Schritt besteht darin, HCP Recruiting nicht auf einzelne Zugangswege zu beschränken. Gerade im medizinischen Kontext zeigt sich, dass kein einzelner Kanal ausreicht, um alle relevanten Nutzergruppen zuverlässig zu erreichen.

Erst die Kombination verschiedener Ansätze führt zu stabilen Ergebnissen. Direkte Kontakte ermöglichen Zugang zu realen Nutzungskontexten, bestehende Teilnehmerpools bieten kurzfristige Verfügbarkeit, während externe Partner oder Community-basierte Ansätze zusätzliche Reichweite schaffen. Durch diese Kombination lässt sich sowohl die Erfolgsquote des Recruitings erhöhen als auch die Vielfalt und Qualität der Teilnehmer verbessern.

5.4 Recruiting als kontinuierlichen Prozess verstehen

Der vielleicht wichtigste Schritt besteht darin, HCP Recruiting aus der Logik einzelner Projekte zu lösen. Solange Recruiting ausschließlich als Vorbereitung einer konkreten Studie verstanden wird, bleibt es reaktiv und nur eingeschränkt planbar.

Ein kontinuierlicher Ansatz integriert Recruiting in den laufenden Entwicklungsprozess. Ziel ist es, Wissen über Nutzergruppen systematisch aufzubauen und bestehende Kontakte langfristig zu pflegen.

In der Praxis bedeutet dies beispielsweise den Aufbau eines eigenen Teilnehmerpools, die strukturierte Dokumentation von Teilnehmerprofilen sowie die regelmäßige Aktualisierung von Kontakten. Dadurch entsteht eine verlässliche Grundlage für zukünftige Usability Tests und eine deutlich geringere Abhängigkeit von kurzfristigen Lösungen.

Kleine Schritte mit großer Wirkung

Die beschriebenen Ansätze zeigen, dass ein strategischer Umgang mit HCP Recruiting für Usability Tests nicht zwingend umfangreiche organisatorische Veränderungen erfordert. Bereits gezielte Anpassungen im Umgang mit Netzwerken, Zielgruppen und Prozessen können erhebliche Verbesserungen bewirken.
Der entscheidende Faktor liegt dabei weniger im einzelnen Recruiting Schritt, sondern in der Kontinuität, mit der Zugang zu relevanten Nutzergruppen aufgebaut und gepflegt wird.

Die dargestellten Handlungsmöglichkeiten bilden eine erste Grundlage für die Weiterentwicklung von HCP Recruiting im Usability Engineering. Sie ersetzen keine umfassende Strategie, zeigen jedoch, wie sich strukturelle Verbesserungen schrittweise in bestehende Prozesse integrieren lassen.

Im nächsten Abschnitt werden die zentralen Erkenntnisse des Artikels zusammengeführt und in einen größeren Kontext eingeordnet.

6 Ausblick: Wohin entwickelt sich HCP Recruiting für Usability Tests?

Die Anforderungen an Usability Tests im Bereich der Medizintechnik entwickeln sich kontinuierlich weiter. Insbesondere die gestiegene Bedeutung von Human Factors Engineering im regulatorischen Kontext hat dazu geführt, dass die Erwartungen an die Qualität, Nachvollziehbarkeit und Validität von Studien deutlich zunehmen. Gleichzeitig bleibt der Zugang zu Healthcare Professionals strukturell anspruchsvoll und es ist nicht zu erwarten, dass sich dieser Engpass in absehbarer Zeit grundlegend verändert.

Vor diesem Hintergrund zeichnet sich bereits heute eine Entwicklung ab, in der HCP Recruiting für Usability Tests zunehmend enger mit dem gesamten Entwicklungsprozess verzahnt wird. Statt als vorbereitender Schritt einzelner Studien verstanden zu werden, entwickelt sich Recruiting zu einem integralen Bestandteil von Usability Engineering und Produktentwicklung.

Parallel dazu ist eine zunehmende Professionalisierung im Umgang mit Netzwerken und Teilnehmerstrukturen zu beobachten. Organisationen beginnen, gezielt Beziehungen zu Healthcare Professionals, Kliniken und Versorgungseinrichtungen aufzubauen und über längere Zeiträume zu pflegen. Dabei verschiebt sich der Fokus weg von der reinen Anzahl potenzieller Teilnehmer hin zur Qualität und Differenzierung der Nutzergruppen.

Gleichzeitig gewinnen digitale Werkzeuge an Bedeutung, die eine strukturierte Organisation, Segmentierung und langfristige Nutzung von Teilnehmerdaten ermöglichen. Perspektivisch ist zu erwarten, dass datenbasierte Ansätze und systematische Segmentierung von Nutzergruppen eine zentrale Rolle bei der Weiterentwicklung spielen werden.

In der Gesamtschau wird deutlich, dass sich HCP Recruiting für Usability Tests zunehmend von einer operativen Aufgabe zu einer eigenständigen Kompetenz entwickelt. Organisationen, die frühzeitig beginnen, entsprechende Strukturen aufzubauen und Zugang zu relevanten Nutzergruppen kontinuierlich zu entwickeln, schaffen sich damit eine stabile Grundlage für zukünftige Studien.

Der entscheidende Unterschied wird dabei nicht in einzelnen Methoden oder Tools liegen, sondern in der Fähigkeit, den Zugang zu Healthcare Professionals langfristig und nachhaltig aufzubauen.

HCP Recruiting für Usability Tests wird damit weniger zu einer Frage der kurzfristigen Umsetzung – und zunehmend zu einem strategischen Vorteil, der sich über Zeit entwickelt.

Überarbeitete Conclusion

HCP Recruiting ist weit mehr als ein organisatorischer Schritt im Rahmen einer Usability Studie. Es entwickelt sich zunehmend zu einem zentralen Erfolgsfaktor, sowohl für die Qualität der gewonnenen Erkenntnisse als auch für deren regulatorische Belastbarkeit.

Die eigentliche Herausforderung liegt dabei nicht in der operativen Umsetzung einzelner Recruiting Maßnahmen. Entscheidend ist vielmehr der Zugang zu den richtigen Nutzergruppen. Nur wenn es gelingt, reale Nutzungskontexte durch passende Healthcare Professionals abzubilden, können Usability Tests ihre volle Aussagekraft entfalten.

Organisationen, die Recruiting in diesem Sinne nicht als isolierte Aufgabe, sondern als strategische Fähigkeit verstehen, schaffen die Grundlage für konsistente und belastbare Studienergebnisse. Sie sind nicht nur in der Lage, effizienter auf neue Anforderungen zu reagieren, sondern können auch komplexere und spezialisierte Nutzergruppen systematisch einbeziehen. Weitere Informationen zum Ablauf eines systematischen Rekrutierungs- und Managementprozesses von Healthcare Professionals erhalten Sie hier:

HCP Recruiting

In weiteren Beiträgen wird darauf aufbauend vertieft, wie konkrete Methoden, Kanäle und Strukturen gestaltet werden können, mit dem Ziel, HCP Recruiting langfristig als belastbare und skalierbare Fähigkeit im Usability Engineering zu etablieren.

Häufig gestellte Fragen zu HCP Recruiting für Usability Tests

HCP Recruiting beschreibt die gezielte Auswahl und Ansprache von Healthcare Professionals, die als repräsentative Nutzergruppen an Usability Tests teilnehmen. Ziel ist es, reale Nutzungsszenarien valide abzubilden und belastbare Erkenntnisse zu generieren.

HCP Recruiting beschreibt die gezielte Auswahl und Ansprache von Healthcare Professionals, die als repräsentative Nutzergruppen an Usability Tests teilnehmen. Ziel ist es, reale Nutzungsszenarien valide abzubilden und belastbare Erkenntnisse zu generieren.

  • Auswahl nach Verfügbarkeit statt Relevanz
  • unklare Definition der Zielgruppen
  • fehlende Differenzierung nach klinischem Kontext
  • unzureichendes Screening der Teilnehmer

Die Anzahl hängt vom Studientyp ab. Während formative Tests mit kleineren Gruppen arbeiten, erfordert die summative Evaluation gemäß IEC 62366-1 repräsentative Teilnehmergruppen pro Nutzerprofil.

  • Aufbau eines strukturierten Teilnehmerpool
  • sklare Definition von Nutzerprofilen
  • systematisches Screening
  • langfristige Recruiting-Strategie statt projektbezogener Ad-hoc-Lösungen

Weiterführende Inhalte

Wie erstellt man hazard-related use scenarios und eine Nutzungsrisikoanalyse?

Hazard-related Use Scenarios

Wie identifiziert man hazard-related use scenarios und führt eine Nutzungsrisikoanalyse durch

Was Hersteller über die IEC 62366-1 Anforderungen wissen müssen

April 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Hazard-related use scenarios gemäß IEC 62366-1 übersetzen Nutzung und Use Errors in eine strukturierte, testbare Form und sind damit ein Kernelement der Nutzungsbedingten Risikoanalyse (Use-related Risk Analysis).
Ausgangspunkt ist eine systematische Task Analysis, um User Interface-Merkmale mit Sicherheitsrelevanz und potenzielle Bedienfehler (Use Errors) zu identifizieren. Darauf aufbauend werden foreseeable und known hazardous situations zusammengeführt, um Risiken sowohl aus plausiblen Interaktionspfaden als auch aus bekannten Problemfeldern abzudecken. Hazard-related use scenarios beschreiben Ereignisketten einschließlich potenzieller Use Errors, die in hazardous situations münden können. Methodisch entscheidend sind der ausreichende Detailgrad in der Darstellung und die saubere Ableitung aus den identifizierten Use Scenarios. Für die Summative Evaluation ist eine begründete, risikobasierte Auswahl der relevanten Szenarien erforderlich.

Die Basis: Identifikation von foreseeable und known hazardous situations

Nutzungsrisikoanalyse (Use-related Risk Analysis) stellt die Verbindung zwischen der Benutzerschnittstelle (User Interface) und dem Risikomanagement her.  Dabei sollte sie zwei Quellen systematisch integrieren:

  • Foreseeable hazardous situations: Situationen, die plausibel aus potenziellen Use Errors entstehen können.
  • Known hazardous situations: Situationen, die aus vorhandenen Daten (z. B. Literatur, Datenbanken, Post-Market-Informationen) bekannt sind.

Die Kombination beider Perspektiven ist wichtig: Die rein projektinterne Analyse kann typische Fehlmuster übersehen, während reine Recherche ohne Interaktionsmodell häufig zu unscharfen, schwer testbaren Aussagen führt.

Methodisch sinnvoll ist, beide Quellen frühzeitig gegeneinander zu spiegeln: Known hazardous situations können als „Reality Check“ dienen (treffen typische Patterns aus dem Feld auf ähnliche UI- oder Workflow-Strukturen?), während foreseeable hazardous situations helfen, bekannte Risiken in produktspezifische, überprüfbare Ketten zu übersetzen. Entscheidend ist dabei, hazardous situations nicht als abstrakte Schlagworte zu führen, sondern als konkrete Situation, in der ein Hazard wirksam wird, z. B. durch falsche Parameterkombination, falschen Patientenbezug, fehlende Monitoring-Reaktion oder verzögerte Alarmwahrnehmung.

Identifikation potenzieller use Errors: Interaktion als Risikotreiber systematisch beschreiben

Während die Identifikation von known hazardous situations eher einer Fleißaufgabe ähnelt, ist eine methodische Vorgehensweise bei der Erarbeitung der foreseeable hazardous situations entscheidend. Hierbei gilt es zunächst potenzielle Use Errors zu identifizieren, die zu hazardous situations führen können, und diese systematisch zu bewerten sowie durch geeignete Maßnahmen zu kontrollieren. Methodisch ist dabei entscheidend, dass Risiken nicht abstrakt formuliert werden, sondern über konkrete Interaktionssequenzen und Nutzungskontexte nachvollziehbar werden.

Ausgangspunkt ist daher eine systematische Beschreibung der Nutzung als Risikotreiber: 

Welche Nutzergruppen führen welche Aufgaben mit welchen Zielen aus, unter welchen Rahmenbedingungen, mit welchen Informationsgrundlagen und mit welchen zeitlichen oder organisatorischen Zwängen? 

Risk Analysis

Erst wenn diese Nutzungssituation konkret beschrieben ist, lassen sich relevante Fehlhandlungen belastbar ableiten. Dazu gehört nicht nur „was“ getan wird, sondern „wie“ die Interaktion abläuft: 

Welche Anzeigen werden gelesen, welche Bedienelemente werden betätigt, welche Entscheidungen werden getroffen, welche Rückmeldungen werden erwartet und welche Systemzustände sind dabei kritisch. Interaktionsschritte, die im Normalfall trivial erscheinen, können unter realistischen Bedingungen (z. B. Stress, Unterbrechung, Handschuhe, eingeschränkte Sicht, Lärm, Zeitdruck oder Parallelaufgaben) zu systematischen Fehlbedienungen führen.

Task Analysis als Basis der use scenarios

Ein strukturierter Einstieg erfolgt über eine Task Analysis auf Basis erwarteter Aufgaben (anticipated tasks). Dabei wird die Mensch-Produkt-Interaktion schrittweise analysiert, um danach sicherheitsrelevante UI-Merkmale und potenzielle Nutzungsfehler (Use Errors) zu identifizieren. Eine belastbare Task Analysis betrachtet nicht nur „was“ getan wird, sondern auch „unter welchen Bedingungen“ und „mit welchen kognitiven Anforderungen“.

Für die Ableitung sicherheitsrelevanter Aussagen ist es hilfreich, Aufgaben in eine konsistente Struktur zu überführen. Dadurch werden Stellen sichtbar, an denen Nutzer auf kritische Informationen angewiesen sind (z. B. Statusanzeigen, Grenzwerte, Warnhinweise), an denen Werte eingegeben oder bestätigt werden, oder an denen ähnliche Optionen verwechselt werden können. Typische Risikotreiber entstehen besonders dort, wo 

  • mehrere Informationen integriert werden müssen,
  • Handlungen irreversibel sind,
  • Zeitdruck oder Unterbrechungen auftreten, oder
  • die User Interfaces mehrere Zustände ohne eindeutige Zustandsklarheit erlauben.

Eine gute Task Analysis integriert deshalb explizit bestehende Nutzungsumgebungseinflüsse (Use Environment Conditions) und kognitive Anforderungen. Dies wird beispielsweise durch den Einsatz der PCA (Perception, Cognition, Action)-Methodik ermöglicht. 

Stellen Sie sich bei der Erstellung die folgenden Fragen:

  • Welche Arbeitsschritte werden durchgeführt und bedingen welche Handlungen,
  • welche Aufmerksamkeit ist erforderlich (z. B. Monitoring parallel zu einer Intervention), 
  • welche Gedächtnislast entsteht (z. B. Parameterwerte merken, bevor sie eingegeben werden), 
  • welche Interpretationsleistung ist nötig (z. B. Trendkurven vs. Einzelwerte), 
  • welche Wahrnehmungsbedingungen gelten (z. B. Blendung, eingeschränkte Sicht, Handschuhe), und 
  • welche Team- oder Übergabesituationen sind typisch (z. B. Schichtwechsel, Übergabe im OP)? 
  • Zusätzlich sollten Abweichungen systematisch als „kalkulierte“ Variationen betrachtet werden: Welche Schritte werden erfahrungsgemäß abgekürzt, welche Workarounds sind plausibel, welche Routinen entstehen bei erfahrenen Nutzern – und welche Risiken werden dadurch begünstigt?

hazard-related use scenarios formulieren

Die Ableitung von Hazard-related Use Scenarios dient dazu, Nutzungsrisiken in eine überprüfbare Form zu überführen.

Ein Use Scenario beschreibt die Interaktion eines Nutzers mit dem Medizinprodukt, um in einer spezifischen Nutzungsumgebung (Use Environment) ein Ergebnis zu erreichen.

Ein Hazard-related Use Scenario erweitert diese Darstellung um eine Ereignissequenz einschließlich potenzieller Use Errors, die in eine hazardous situation münden kann, kurz gesagt:

Eine Hazard-related Use Scenario gemäß IEC 62366-1 ist ein Use Scenario, das zu einer Hazardous Situation führen kann, insbesondere infolge eines Use Error oder eines Reasonably Foreseeable Misuse (gemäß ISO 14971).

 

Wesentliche Qualitätskriterien sind:

  • Perspektive: Formulierung aus Sicht des Nutzers und des Nutzungskontextes.

  • Detailgrad: Ausreichend detailliert, um Ursachenketten und Interaktionsanforderungen nachvollziehen zu können.

  • Methodische Reihenfolge: Zunächst korrekte Use Scenarios definieren, anschließend daraus hazard-related use scenarios ableiten. Dadurch wird klar, an welcher Stelle der Abweichungspfad entsteht und welche UI-Merkmale oder Kontextfaktoren beitragend sind.

Ein Hazard-related Use Scenario sollte so aufgebaut sein, dass es direkt in Testdesign und Risikodokumentation überführbar ist. Praktisch bedeutet das: 

klare Startbedingungen (Systemzustand, Nutzerrolle),
erwartete korrekte Interaktion,
zugrunde liegende Use Errors und in Relation stehende UI-Merkmale,
Resultierende Hazardous situation, Hazards sowie Harms
die Einschätzung des Schadenschweregrads (Severity Level) in Rücksprache mit dem Riskmanagement
bestehende und zusätzlich zu definierende Risikokontrollmaßnahmen (Risk Control Measures)

Dadurch entsteht ein Szenarioformat, das sowohl argumentierbar (für ISO 14971) als auch testbar (für IEC 62366-1) ist.

Auswahl der Hazard-related Use SCenarios für die Summative Evaluation

Nicht jedes hazard-related use scenario muss zwingend Gegenstand der summativen Evaluation sein. Entscheidend ist ein transparentes, risikobasiertes Auswahlverfahren mit dokumentierter Begründung. Die Auswahl muss zeigen, dass jene Szenarien adressiert wurden, die für die Sicherheit der Nutzung maßgeblich sind. IEC 62366-1 führt drei zulässige Auswahlwege an:

Es werden alle Hazard-related Use Scenarios für die summativen Tests ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) des zu erwartenden Schadens (Harm) ausgewählt.
Es wird eine Teilmenge von Hazard-related Use Scenarios auf Basis des Schweregrads (Severity Level) und weiterer, für das Medizinprodukt und den Hersteller spezifischen Umständen ausgewählt.

Die Bedeutung der Schadensschwere wird deutlich. Die Einstufung dieser erfolgt gemäß ISO 14971. Die Normenverfasser haben in der neuesten Überarbeitung viel Spielraum für weitreichende Begründungen ermöglicht. Ein belastbares Auswahlverfahren macht explizit, warum ein Szenario in die Summative Evaluation aufgenommen wird. Entscheidend ist, dass die Auswahl nachvollziehbar dokumentiert ist und klar zeigt, dass die sicherheitskritischen Nutzungsszenarien in der summativen Prüfung abgedeckt wurden und somit im Einklang des Usability Engineering Prozesses für Medizinprodukte steht.

Disclaimer

Die in diesem Fachartikel dargestellten Informationen zu Normen und Richtlinien wurden nach bestem und fundiertem Expertenwissen dargelegt. Sie spiegeln hierbei rein die Meinung des Autors wider. Es kann keine Gewähr für die Vollständigkeit, Aktualität und Richtigkeit der Angaben übernommen werden. Normen und Richtlinien unterliegen regelmäßigen Überarbeitungen und Änderungen, die hier nicht immer unmittelbar berücksichtigt werden können. Dieser Artikel stellt keine verbindliche Beratung dar und ersetzt keine Prüfung der jeweils gültigen Normen und Richtlinien durch qualifizierte Fachpersonen oder offizielle Stellen. Für die Anwendung der Normen und Richtlinien und deren Auslegung sind stets die aktuell gültigen Originaldokumente sowie die zuständigen Organisationen maßgeblich.

Benedikt Janny

Als Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Planung, Durchführung und Dokumentation von Nutzungsrisikoanalysen. Sie haben Fragen? Sprechen Sie uns gerne an.

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter

Wie führt man formative usability Evaluationen gemäß IEC 62366-1 durch?

Formative Usability Evaluation

Wie führt man formative Usability-Evaluationen gemäß IEC 62366-1 durch?

Was Hersteller wissen müssen

Februar 2026

Executive Summary

Kopie von auditive Visual Haptical Feedback 3

Formative usability Evaluationen sind ein methodischer Kernbestandteil des iterativen User Interface Designs gemäß IEC 62366-1, der normativen Referenz zur Umsetzung der europäischen Medical Device Regulation (MDR). Sie dienen sowohl der kontinuierlichen Verbesserung der Benutzerschnittstelle (Design focus) als auch der frühzeitigen Identifikation sicherheitsrelevanter Use Errors (Safety focus). Geeignete Methoden reichen von Expert Reviews und Cognitive Walkthroughs bis zu frühen simulated-use Usability Tests. Ein User Interface Evaluation Plan unterstützt die Konsistenz, indem er Ziele, Methoden und Kriterien für formative und summative Aktivitäten definiert.

Die Auswertung sollte Beobachtungen zu Use Errors, close calls und use difficulties systematisch mit Ursachenanalysen verknüpfen. Entscheidend ist die Rückkopplung der Ergebnisse in Designiterationen und – sofern sicherheitsrelevant – in die Nutzungsrisikoanalyse. Eine saubere Dokumentation schafft Nachvollziehbarkeit und Traceability über Entwicklungsschritte hinweg. Dieser Artikel erläutert, wie Sie hierbei zielgerichtet und effizient vorgehen sollten.

1Die Funktion formativer Evaluationen im Entwicklungsprozess

Formative usability Evaluationen dienen der iterativen Verbesserung der Benutzerschnittstelle und sind damit ein integraler Bestandteil der User Interface Design Methodology. Im Unterschied zu summativen Nachweisen steht bei formativen Maßnahmen nicht die abschließende Validierung, sondern ein strukturierter Lern- und Optimierungszyklus im Vordergrund. Ziel formativer Evaluationen ist es, Interaktionsprobleme möglichst frühzeitig zu identifizieren und User Interface Designoptimierungen abzuleiten, bevor sie sich in spätere Entwicklungsstände verfestigen und nur noch mit hohem Aufwand korrigierbar sind.

Formative Evaluationen haben zudem eine Risikofunktion. Sie unterstützen die frühzeitige Identifikation potenzieller Use Errors, die zu hazardous situations beitragen könnten, und ermöglichen dadurch eine gezielte Weiterentwicklung der Benutzerschnittstelle, bevor eine summative Bewertung ansteht. Damit tragen formative Evaluationen nicht nur zur Gebrauchstauglichkeit im Sinne effizienter und zufriedenstellender Bedienung bei, sondern auch zur Robustheit der Benutzung in sicherheitskritischen Situationen.

OR Formative Usability Test

2Der Doppelte Zielrahmen: Design focus und Safety focus

Formative Evaluationen lassen sich methodisch entlang zweier Zielrichtungen strukturieren, die sich in der Praxis ergänzen und häufig parallel adressiert werden. Die klare Trennung dieser Perspektiven unterstützt eine präzise Studienplanung, eine zielgerichtete Datenerhebung sowie eine nachvollziehbare Interpretation der Ergebnisse.
  • Design Focus
    Ziel ist die Gewinnung von Erkenntnissen zur Verbesserung der Benutzerschnittstelle während der Entwicklung. Im Vordergrund stehen dabei Aspekte wie Verständlichkeit, Konsistenz, Orientierung, Informationsdarstellung, Arbeitsflussunterstützung und die Reduktion unnötiger kognitiver Belastung. Der Design Focus fragt insbesondere, ob die Benutzerschnittstelle die erwarteten mentalen Modelle der Nutzer angemessen unterstützt, ob Interaktionslogiken intuitiv nachvollziehbar sind und ob Rückmeldungen, Statusanzeigen und Systemreaktionen so gestaltet sind, dass Nutzer Handlungsentscheidungen zufriedenstellend, effektiv und effizient treffen können. Ergebnisse aus dieser Perspektive führen typischerweise zu Designanpassungen, die Bedienbarkeit, Effizienz und Fehlertoleranz verbessern, ohne dass zwingend ein direkter Sicherheitsbezug im engeren Sinne vorliegen muss.
  • Safety Focus
    Ziel ist die Identifikation bislang unbekannter Use Errors, die zu hazardous situations führen könnten. Während der Design Focus häufig auf Optimierung „normaler“ Nutzung abzielt, betrachtet der Safety Focus gezielt jene Interaktionsstellen, an denen Fehlhandlungen plausibel sind und potenziell sicherheitskritische Konsequenzen haben können. Dabei werden nicht nur tatsächlich beobachtete Use Errors betrachtet, sondern ebenso close calls (Beinahe-Fehler), use difficulties oder Strategien, die auf eine erhöhte Fehlerwahrscheinlichkeit hinweisen. Methodisch relevant ist hier insbesondere die Frage, welche beitragenden Faktoren die Fehlbedienung begünstigen (z. B. unklare Rückmeldungen, Mehrdeutigkeiten, ungünstige Sequenzen, unzureichende Fehlerprävention oder -erkennung) und wie sich diese Faktoren durch UI-Designmaßnahmen oder begleitende risk control measures reduzieren lassen.

Diese Differenzierung ist in der Praxis hilfreich, da sie Auswahl, Tiefe und Zeitpunkt geeigneter Methoden steuert. Ein frühes Konzeptreview ist typischerweise stärker im Design Focus verankert: Es überprüft die grundlegende Handlungslogik, Konsistenz, Terminologie, Informationsarchitektur und potenzielle kognitive Belastungen, häufig noch bevor hochauflösende Prototypen verfügbar sind. Ein formativer usability test (z. B. simulated use in einem fortgeschritteneren Entwicklungsstand) kann dagegen stärker auf den Safety Focus ausgerichtet werden: Er adressiert risikorelevante Nutzungspfade, prüft die Robustheit der Benutzerschnittstelle in kritischen Situationen und macht sicherheitskritische Fehlhandlungen sowie close calls empirisch sichtbar.

In der praktischen Umsetzung bedeutet dies, dass formative Evaluationen nicht als „eine Art Test“ verstanden werden sollten, sondern als methodisch abgestufte Sequenz von Aktivitäten. Je nach Entwicklungsphase kann der Schwerpunkt zwischen Design Focus und Safety Focus variieren. Eine explizite Zielzuordnung erleichtert es zudem, Ergebnisse angemessen zu gewichten: Während designbezogene Findings häufig in inkrementelle Optimierungen münden, führen sicherheitsbezogene Findings regelmäßig zu priorisierten Maßnahmen, die unmittelbar in Risikoargumentation und nachfolgende Evaluationsplanung einfließen.

3Team- und Methodenset für formative evaluationen

Die Auswertung formativer Evaluationen erfolgt typischerweise multidisziplinär, da nutzungsbezogene Probleme selten ausschließlich auf „Usability“ im engeren Sinne zurückzuführen sind, sondern häufig aus einem Zusammenspiel von klinischem Anwendungskontext, technischen Randbedingungen, Informationsdarstellung, Arbeitsprozessen und Training entstehen. Entsprechend ist die Einbindung relevanter Stakeholder – beispielsweise aus Engineering, Clinical/Medical, Quality/Regulatory, Risk Management und Design – methodisch vorteilhaft, um Beobachtungen sowohl korrekt einzuordnen als auch in umsetzbare Design- und Risikomaßnahmen zu überführen. Ergänzend ist die Einbindung repräsentativer Nutzer sinnvoll und häufig notwendig, sofern Entwicklungsstand, Zugänglichkeit und Studiensetting dies erlauben. Repräsentative Nutzer ermöglichen insbesondere die Validierung oder Widerlegung von Annahmen über mentale Modelle, Routinen, Kontextfaktoren und typische Fehlerstrategien, die durch rein interne Reviews häufig nur eingeschränkt abbildbar sind.

Aus methodischer Perspektive ist zudem relevant, dass formative Evaluationen je nach Entwicklungsphase unterschiedlich „schwergewichtig“ angelegt werden können. In frühen Phasen stehen häufig schnelle, analytische Methoden im Vordergrund, die mit geringem Prototypreifegrad durchführbar sind. Mit zunehmender Reife der Benutzerschnittstelle verschiebt sich der Schwerpunkt hin zu empirischen Verfahren, um Interaktionsmuster unter realitätsnahen Bedingungen beobachtbar zu machen. In vielen Projekten ist daher ein kombiniertes Vorgehen zielführend: analytische Verfahren zur breiten Identifikation von Schwachstellen und empirische Verfahren zur Bestätigung, Priorisierung und Ursachenanalyse.

Als geeignete Methoden kommen unter anderem in Betracht:

  • Expert Reviews zur schnellen Identifikation offensichtlicher Interaktionsschwächen. Sie ermöglichen eine strukturierte Prüfung der Benutzerschnittstelle auf Inkonsistenzen, Mehrdeutigkeiten, fehlende Rückmeldungen, potenzielle Fehlbedienpfade sowie allgemein bekannte Interaktionsprinzipien oder Heuristiken. 
  • Cognitive Walkthroughs zur Analyse der Arbeitsabläufe und von mentalen Modellen, insbesondere bei komplexen Bediensequenzen oder sicherheitskritischen Entscheidungsstellen. Sie adressieren insbesondere die Frage, ob Nutzer die intendierten Handlungsschritte aus dem User Interface heraus plausibel ableiten können
  • Early-stage usability tests (simulated use) zur Beobachtung realer Interaktionsabläufe auf Prototypständen. Early-stage Tests ermöglichen die empirische Beobachtung von Interaktionsverhalten, einschließlich use difficulties, close calls und potenzieller Use Errors, unter realitätsnahen (simulierten) Bedingungen. Sie sind besonders wertvoll, um tatsächliche Bedienstrategien zu erfassen, die in analytischen Methoden häufig unterschätzt werden (z. B. Workarounds, Abkürzungen, fehleranfällige Routinen, Reaktionen auf Stress oder Ablenkung). Abhängig vom Entwicklungsstand können solche Tests mit Low- bis High-Fidelity-Prototypen durchgeführt werden, wobei sich mit zunehmender Prototypreife auch die Aussagekraft in Bezug auf Timing, Feedback und Interaktionsdynamik erhöht. Gerade für risikorelevante Nutzungspfade bieten simulated-use Tests die Möglichkeit, Hypothesen aus Task Analysis und hazard-related use scenarios empirisch zu prüfen und priorisierte Designänderungen abzuleiten.

4Das formative Vorgehensmodell: Planung, Durchführung, Iteration

Ein wirkungsvolles Vorgehensmodell für formative Evaluationen folgt typischerweise einem wiederholbaren Zyklus aus Planung, Durchführung, Analyse und Iteration. Entscheidend ist, dass formative Aktivitäten nicht als isolierte Einzelmaßnahmen verstanden werden, sondern als gesteuerte Abfolge, deren Ergebnisse nachvollziehbar in Designentscheidungen und – sofern relevant – in die risikobasierte Argumentation einfließen. Der methodische Anspruch besteht darin, die explorative Natur formativer Evaluationen mit einer hinreichenden Struktur zu verbinden, damit Erkenntnisse zuverlässig vergleichbar, priorisierbar und dokumentierbar sind.

Schritt 1: User Interface Evaluation Plan etablieren

Ein User Interface Evaluation Plan bildet die organisatorische und methodische Klammer formativer (und in der Regel auch summativer) Aktivitäten. Er sollte definieren, welche Ziele mit der jeweiligen Evaluation verfolgt werden, welche Methoden eingesetzt werden, welche Evaluationskriterien gelten und wie die Evaluation in die übergeordnete Entwicklungs- und Risikologik eingebettet ist. Besonders wichtig ist die explizite Verknüpfung zu risiko- und szenariobasierten Anforderungen, da sich formative Evaluationen häufig auf spezifische Interaktionspfade, UI-Merkmale oder Nutzungssituationen beziehen, die im Risikokontext relevant sind.

Ein konsistenter Plan verhindert, dass Ergebnisse als „punktuelle Beobachtungen“ stehen bleiben, und schafft stattdessen eine nachvollziehbare Struktur: Welche Fragestellung wurde mit welcher Methode beantwortet? Welche Version des Designs wurde untersucht? Welche Nutzergruppen und Nutzungskontexte wurden adressiert? Diese Klarheit ist auch für spätere Iterationen entscheidend, da nur so erkennbar bleibt, ob Verbesserungen tatsächlich wirksam waren oder ob sich Probleme lediglich verlagert haben.

Schritt 2: Durchführung mit geeigneter Realitätsnähe

Auch formative Tests profitieren von realistischen Aufgaben und plausiblen Kontextbedingungen, jedoch in einer bewusst explorativen Logik. Die Realitätsnähe dient hier nicht primär der regulatorischen Nachweisführung, sondern der Validierung von Annahmen über Nutzung, Entscheidungslogik und Umgebungsbedingungen. Geeignet ist ein Setting, das typische Arbeitsabläufe und relevante Kontextfaktoren hinreichend abbildet, ohne den Fokus auf Lern- und Optimierungsziele zu verlieren.

In der Durchführung ist insbesondere darauf zu achten, dass Aufgabenstellungen so formuliert sind, dass sie reale Handlungsentscheidungen auslösen und nicht nur „UI-Funktionen abprüfen“. Je nach Reifegrad des Prototyps kann die Realitätsnähe über unterschiedliche Mittel hergestellt werden, beispielsweise durch die Simulation relevanter Nutzungssituationen, geeignete Materialien (z. B. Instructions for Use (IFU)-Entwürfe), typische Zeit- und Aufmerksamkeitsbedingungen oder realistische Übergänge zwischen Arbeitsschritten. Gleichzeitig bleibt die formative Logik flexibel: Wenn sich während der Durchführung zeigt, dass zentrale Probleme in einer anderen Interaktionsstelle liegen als erwartet, ist eine Anpassung des Fokus methodisch zulässig, sofern sie transparent dokumentiert wird.

Schritt 3: Analyse der identifizierten Use Problems

Die Auswertung formativer Evaluationen sollte sich nicht auf eine reine Problemauflistung beschränken, sondern konsequent ursachenorientiert erfolgen. Zentral ist die Frage, welche Beobachtungen tatsächlich eine Relevanz für Designentscheidungen besitzen und welche Faktoren die beobachteten Schwierigkeiten erklären. Dazu gehört die strukturierte Betrachtung von:

  • Use Errors (Fehlhandlungen/Unterlassungen mit potenziell risikorelevanten Folgen),

  • close calls (Beinahe-Fehler, die häufig Hinweise auf erhöhte Fehlwahrscheinlichkeit geben),

  • use difficulties (Schwierigkeiten, Verzögerungen, Missverständnisse oder Workarounds).

Eine belastbare Analyse untersucht, welche UI-Merkmale, welche Informationsdarstellungen, welche Interaktionssequenzen oder welche Kontextbedingungen zu den beobachteten Problemen beitragen. Besonders wertvoll ist die Identifikation wiederkehrender Muster: Treten Schwierigkeiten bei mehreren Personen an derselben Stelle auf? Zeigen unterschiedliche Nutzer ähnliche Fehlstrategien? Gibt es typische Korrekturhandlungen (z. B. Rücksprünge, wiederholtes Probieren, Abbruch) als Indikator für unzureichende Systemtransparenz oder fehlende Fehlerprävention?

Die Ursache-Wirkungs-Argumentation sollte so formuliert sein, dass daraus konkrete Designmaßnahmen ableitbar sind. Damit werden formative Ergebnisse zu einem methodischen Entscheidungsinstrument und nicht lediglich zu einer Sammlung an Beobachtungen.

Schritt 4: Designänderungen und Rückkopplung in Risikoaktivitäten

Der zentrale Output formativer Evaluationen sind priorisierte Designänderungen und eine nachvollziehbare Begründung, weshalb diese Änderungen geeignet sind, die beobachteten Probleme zu reduzieren. In der Praxis ist es hilfreich, Designmaßnahmen nicht nur als „Fixes“ zu dokumentieren, sondern als Teil einer strukturierten Iteration: Welche Änderung adressiert welche Ursache? Welche Annahme wird damit verändert? Welche Interaktionsstelle wird stabilisiert?

Parallel dazu ist eine Rückkopplung in die Risikoaktivitäten erforderlich, sofern sich aus den Ergebnissen neue oder bestätigte Use Errors ableiten lassen, die sicherheitsrelevant sein könnten. Dies betrifft insbesondere Fälle, in denen close calls oder use difficulties als Vorläufer potenzieller hazardous situations interpretierbar sind. In solchen Situationen sollten die Erkenntnisse in die Nutzungsrisikoanalyse zurückgespielt werden, um die Risikologik konsistent zu halten und die Grundlage für eine risikobasierte Planung nachfolgender Evaluationen zu stärken.

Damit entsteht ein geschlossener Lernkreislauf: Formative Evaluationen verbessern nicht nur die Bedienbarkeit, sondern stabilisieren zugleich die sicherheitsbezogene Argumentation, indem sie risikorelevante Erkenntnisse frühzeitig sichtbar machen und gezielt in Design- und Risikomaßnahmen überführen.

5Dokumentationsanforderungen

Die Richtlinie sieht eine sorgfältige Auswahl der Teilnehmer, gegebenenfalls Schulungen und Datenerfassung mit dem Schwerpunkt auf die Critical Tasks vor. Die Richtlinie betont, dass Personen, die häufig an Usability-Tests desselben Geräts oder anderer Geräte desselben Herstellers teilnehmen, ausgeschlossen werden sollten. Interessant im Vergleich zu anderen Richtlinien ist, dass die NMPA-Richtlinie explizit eine Begründung erwartet, wenn keine Geräteschulung für die Testteilnehmer erforderlich ist. Die Testberichte sollten detaillierte Angaben zu den Zielen, Simulationsbedingungen, Ergebnissen in Bezug auf Use Errors und damit verbundene Root Causes sowie etwaigen Abweichungen enthalten. 

Formative Evaluationen sind in einer Weise zu dokumentieren, dass die Ergebnisse nachvollziehbar, reproduzierbar im Sinne der methodischen Logik und für nachgelagerte Aktivitäten anschlussfähig sind. In der Praxis erfolgt dies typischerweise über Test- oder Evaluationspläne (Evaluation Protocols) und Berichte (Evaluation Reports), die nicht nur einzelne Beobachtungen festhalten, sondern eine konsistente Argumentationskette von Zielsetzung über Methode bis zur abgeleiteten Maßnahme ermöglichen. Dabei ist weniger die reine Umfangstiefe entscheidend als die strukturierte Transparenz: Dritte sollen verstehen können, warum die Evaluation durchgeführt wurde, wie sie durchgeführt wurde, was beobachtet wurde und welche Schlussfolgerungen daraus methodisch begründet abgeleitet wurden.

Ein vollständiges Dokumentationsset umfasst in der Regel folgende Inhalte:

  • Ziele und Fragestellungen: klare Benennung, ob die Evaluation primär designorientiert, sicherheitsorientiert oder kombiniert ausgerichtet war, und welche UI-Aspekte oder Use Scenarios im Fokus standen.

  • Methodik und Studiendesign: Beschreibung der angewandten Methode(n) (z. B. Expert Review, Cognitive Walkthrough, Usability Test (simulated-use)), inklusive Begründung der Methodenauswahl im Verhältnis zum Entwicklungsstand des User Interface.

  • Stichprobe und Repräsentativität: Charakterisierung der einbezogenen Nutzer bzw. Experten, inklusive relevanter Merkmale in Bezug auf intended user profiles (z. B. Erfahrung, Qualifikation, potenzielle Limitationen), sowie – sofern zutreffend – eine Begründung der Abdeckung und Grenzen der Repräsentativität.

  • Testobjekt und Versionierung: eindeutige Angabe, welche Version der Benutzerschnittstelle bzw. welche Prototypstände bewertet wurden, einschließlich relevanter Begleitmaterialien (z. B. IFU-Entwürfe, Trainingsannahmen).

  • Aufgaben und Szenarien: Beschreibung der verwendeten Aufgabenstellungen, Use Scenarios und Rahmenbedingungen, idealerweise so, dass die Logik der Aufgabenableitung und die beabsichtigte Auslösung bestimmter Interaktionspfade erkennbar wird.

  • Datenerhebung und Auswertelogik: Darstellung, welche Daten erhoben wurden (z. B. Beobachtungen, Fehlerklassifikation, qualitative Notizen), wie Beobachtungen strukturiert wurden und nach welchen Kriterien Interpretation und Priorisierung erfolgten.

  • Ergebnisse in strukturierter Form: konsistente Dokumentation von use errors, close calls und use difficulties, inklusive Kontext, beobachteter Handlungssequenz sowie – soweit möglich – einer Root Cause Analysis bzw. beitragender Faktoren.

  • Abgeleitete Maßnahmen und Designentscheidungen: konkrete, nachvollziehbar begründete Maßnahmen, die aus den Ergebnissen abgeleitet wurden, einschließlich Priorisierung und Begründung, weshalb die Maßnahme geeignet ist, die beobachtete Ursache zu adressieren.

Wesentlich ist dabei die Anschlussfähigkeit: Die weitere Entwicklungsdokumentation sollte nachvollziehbar zeigen, wie formative Ergebnisse in Designentscheidungen und in die Nutzungsrisikoanalyse eingeflossen sind. Dies umfasst insbesondere die Verbindung zwischen beobachteten Problemen, ihrer Ursacheninterpretation und den implementierten oder geplanten Designänderungen.

Darüber hinaus hat die Dokumentation eine wichtige Steuerungsfunktion im Projektverlauf. Sie ermöglicht, über Iterationen hinweg zu prüfen, ob Maßnahmen wirksam waren, ob sich Probleme verlagert haben oder ob neue Risiken entstanden sind. Eine klare Versionierung und eine konsistente Ergebnisstruktur erleichtern zudem die spätere Vorbereitung summativer Evaluationsaktivitäten, da sie sichtbar machen, welche risikorelevanten Interaktionsstellen bereits adressiert wurden und welche Aspekte weiterhin kritisch bleiben.

Disclaimer

Die in diesem Fachartikel dargestellten Informationen zu Normen und Richtlinien wurden nach bestem und fundiertem Expertenwissen dargelegt. Sie spiegeln hierbei rein die Meinung des Autors wider. Es kann keine Gewähr für die Vollständigkeit, Aktualität und Richtigkeit der Angaben übernommen werden. Normen und Richtlinien unterliegen regelmäßigen Überarbeitungen und Änderungen, die hier nicht immer unmittelbar berücksichtigt werden können. Dieser Artikel stellt keine verbindliche Beratung dar und ersetzt keine Prüfung der jeweils gültigen Normen und Richtlinien durch qualifizierte Fachpersonen oder offizielle Stellen. Für die Anwendung der Normen und Richtlinien und deren Auslegung sind stets die aktuell gültigen Originaldokumente sowie die zuständigen Organisationen maßgeblich.

Benedikt Janny

Als Usability-Engineering-Spezialisten unterstützen wir von USE-Ing. Sie gerne bei der Planung, Durchführung und Dokumentation von Formativen Usability Evaluationen. Sie haben Fragen? Sprechen Sie uns gerne an.

Der USE-Ing. Kompass

Bleiben Sie auf dem richtigen Kurs mit unserem Newsletter