Die Aufgabenanalyse (Task Analysis) zerlegt die Interaktion zwischen Nutzer und Produkt systematisch in Aufgaben, Teilaufgaben und einzelne Handlungsschritte. Sie macht sichtbar, welche Wahrnehmungs-, Denk- und Handlungsleistungen ein Nutzer erbringen muss – und liefert damit die methodische Grundlage, um kritische Aufgaben zu identifizieren und Nutzungsszenarien realistisch abzuleiten.
Was die Aufgabenanalyse leistet
Die Aufgabenanalyse übersetzt eine allgemeine Nutzungsbeschreibung in eine prüfbare Struktur. Solange ein Vorgang als „Der Anwender bereitet die Infusion vor" beschrieben ist, lässt sich weder beurteilen, wo ein Anwendungsfehler (Use Error) entstehen kann, noch, welcher Schritt sicherheitsrelevant ist. Erst die Zerlegung in einzelne Handlungsschritte macht Fehlerpotenziale adressierbar.
Für jeden Schritt wird betrachtet, was der Nutzer wahrnehmen muss, was er wissen oder entscheiden muss und was er körperlich tun muss – die drei Stufen des Modells Perception–Cognition–Action. Diese Zuordnung ist mehr als eine Ordnungshilfe: Sie bestimmt, welche Gestaltungsmaßnahme überhaupt wirken kann. Ein übersehener Warnhinweis ist kein Problem, das sich durch eine zusätzliche Schulung lösen lässt, und ein Verständnisproblem verschwindet nicht durch einen größeren Knopf.
Die Ergebnisse der Aufgabenanalyse sind Eingangsgrößen für mehrere nachgelagerte Schritte: Sie speisen die Nutzungsszenarien, die Identifikation kritischer Aufgaben und die Nutzungsrisikoanalyse (URRA). Eine lückenhafte Aufgabenanalyse pflanzt sich deshalb durch den gesamten Usability-Engineering-Prozess fort – und fällt typischerweise erst in der summativen Validierung auf, wenn eine Korrektur teuer wird.
Hierarchische Aufgabenanalyse
Das in der Praxis gebräuchlichste Format ist die hierarchische Aufgabenanalyse (Hierarchical Task Analysis, HTA). Sie ordnet die Nutzung in einer Baumstruktur: Ein übergeordnetes Ziel wird in Teilziele zerlegt, diese wiederum in konkrete Handlungsschritte. Ergänzt wird die Struktur durch sogenannte Pläne, die festlegen, in welcher Reihenfolge oder unter welchen Bedingungen die Teilschritte ausgeführt werden – sequenziell, parallel, alternativ oder ereignisgesteuert.
Gerade diese Pläne sind für Medizinprodukte aufschlussreich. Sie zwingen dazu, Verzweigungen explizit zu machen: Was geschieht, wenn ein Selbsttest fehlschlägt? Was, wenn der Vorgang unterbrochen und später fortgesetzt wird? Was, wenn zwei Nutzer sich die Aufgabe teilen? Solche Verzweigungen sind erfahrungsgemäß fehleranfälliger als der reguläre Ablauf und werden in weniger strukturierten Analysen regelmäßig übersehen.
Für die Frage, wie tief eine Zerlegung gehen soll, hat sich in der HTA eine pragmatische Abbruchregel etabliert: Weiter zerlegt wird nur dort, wo die Wahrscheinlichkeit eines Fehlers und die Schwere seiner Folgen die Detaillierung rechtfertigen. Ein Schritt, dessen Fehlschlagen weder wahrscheinlich noch folgenreich ist, muss nicht in Einzelbewegungen aufgelöst werden. Diese Regel schützt vor der häufigsten Fehlform der Aufgabenanalyse – einer Dokumentation, die durch schiere Länge unbrauchbar wird.
Erhebungsmethoden in der Praxis
Eine belastbare Aufgabenanalyse entsteht nicht am Schreibtisch. Sie erfordert Zugang zur realen Nutzung und in der Regel eine Kombination mehrerer Erhebungsformen:
- Beobachtung und Hospitation im tatsächlichen Nutzungsumfeld – die einzige Methode, die Abweichungen zwischen dokumentiertem und gelebtem Ablauf zuverlässig aufdeckt.
- Interviews mit repräsentativen Nutzern aller vorgesehenen Benutzerprofile, einschließlich weniger erfahrener Anwender und solcher, die das Produkt nur gelegentlich einsetzen.
- Dokumentenanalyse von Gebrauchsanweisung, klinischen Standardvorgehensweisen und Schulungsunterlagen – als Soll-Abgleich, nicht als Ersatz für Beobachtung.
- Walkthrough mit Fachexperten, etwa als Cognitive Walkthrough, um Handlungsschritte analytisch auf Erkennbarkeit und Verständlichkeit zu prüfen.
- Videoanalyse aufgezeichneter Nutzungssequenzen, um Timing, Unterbrechungen und Parallelhandlungen nachvollziehbar auszuwerten.
Die Kombination ist entscheidend, weil die Methoden unterschiedliche blinde Flecken haben. Interviews liefern das, was Nutzer über ihr Handeln berichten – nicht notwendigerweise das, was sie tun. Beobachtung liefert das Verhalten, aber nicht dessen Begründung. Erst zusammen ergeben sie ein Bild, das einer Nutzungsrisikoanalyse standhält.
Von der Aufgabe zur kritischen Aufgabe
Nicht jede Aufgabe ist gleich relevant. Als kritisch gilt eine Aufgabe, bei der ein Anwendungsfehler zu ernsthaftem Schaden führen kann, wenn keine Gegenmaßnahme greift. Die Aufgabenanalyse liefert die vollständige Liste der Kandidaten; die Bewertung, welche davon kritisch sind, erfolgt in der Nutzungsrisikoanalyse.
Praktisch bedeutet das: Für jeden Handlungsschritt wird gefragt, welche plausiblen Fehlhandlungen möglich sind – Auslassen, Vertauschen, zu früh oder zu spät, falsche Menge, falsches Objekt – und ob eine solche Fehlhandlung in eine Gefährdungssituation münden kann. Aus dieser Verknüpfung entstehen die gefährdungsbezogenen Nutzungsszenarien, die später in der summativen Evaluation gezielt getestet werden.
Damit ist die Aufgabenanalyse der Punkt, an dem sich entscheidet, ob die spätere Validierung das Richtige prüft. Ein kritischer Schritt, der hier nicht auftaucht, wird auch nicht getestet – und das Restrisiko bleibt unerkannt.
Typische Schwächen in der Praxis
- Der Soll-Prozess statt des Ist-Prozesses. Analysiert wird der Ablauf, wie er in der Gebrauchsanweisung steht – nicht der, den Anwender im Alltag tatsächlich wählen, etwa mit Abkürzungen unter Zeitdruck.
- Nur der reguläre Pfad. Notfall, Unterbrechung, Fehlbedienung, Wiederaufnahme und Notfallnutzung fehlen, obwohl gerade dort die kritischen Fehler entstehen.
- Einmalig erstellt, nie aktualisiert. Die Analyse wird früh angelegt und nicht mit Designänderungen nachgeführt, sodass sie am Ende ein Produkt beschreibt, das so nicht mehr existiert.
- Ohne Anschluss an die Risikoanalyse. Die Aufgabenanalyse existiert als eigenständiges Dokument, ohne nachvollziehbare Verknüpfung zu den identifizierten Use Errors und Risiken.
- Zu grob oder zu fein. Entweder bleibt die Zerlegung auf einer Abstraktionsebene, auf der keine Fehler sichtbar werden, oder sie verliert sich in Einzelbewegungen ohne Risikorelevanz.
Regulatorischer Bezug
Die Aufgabenanalyse ist in IEC 62366-1 nicht als eigener, benannter Prozessschritt gefordert. Die Norm verlangt jedoch, Nutzungsszenarien und darunter die sicherheitsbezogenen zu identifizieren – und die Aufgabenanalyse ist der etablierte methodische Weg, um dieser Anforderung nachvollziehbar zu genügen. In IEC 62366-2 wird sie als zentrale Methode zur Ableitung von Nutzungsszenarien beschrieben.
Die FDA Human Factors Guidance ist an dieser Stelle deutlicher: Sie erwartet eine Aufgabenanalyse als Grundlage für die Identifikation kritischer Aufgaben, die anschließend in der Human Factors Validation gezielt geprüft werden müssen. Über die Nutzungsrisikoanalyse ist die Aufgabenanalyse zudem mit dem Risikomanagement nach ISO 14971 verzahnt.
Häufige Fragen (FAQ)
Worin unterscheidet sich die Aufgabenanalyse von der Workflow-Analyse?
Die Aufgabenanalyse betrachtet die Interaktion zwischen einem Nutzer und dem Produkt und zerlegt sie in Handlungsschritte. Die Workflow-Analyse blickt eine Ebene höher auf den gesamten Arbeitsablauf, in den die Produktnutzung eingebettet ist – einschließlich anderer Geräte, weiterer Personen und paralleler Prozessschritte. In der Praxis ergänzen sich beide: Die Workflow-Analyse liefert den Kontext, die Aufgabenanalyse die Detailtiefe.
Wie tief muss eine Aufgabenanalyse gehen?
So tief, wie es die Risikorelevanz erfordert. Als Abbruchregel hat sich bewährt, einen Schritt nur dann weiter zu zerlegen, wenn die Wahrscheinlichkeit eines Fehlers und die Schwere seiner möglichen Folgen die zusätzliche Detaillierung rechtfertigen. Eine gleichmäßig tiefe Zerlegung aller Aufgaben erzeugt Umfang ohne Erkenntnisgewinn.
Ist die Aufgabenanalyse nach IEC 62366-1 vorgeschrieben?
Nicht als namentlich benannter Pflichtschritt. Die Norm fordert jedoch die Identifikation von Nutzungsszenarien und sicherheitsbezogenen Nutzungsszenarien, und die Aufgabenanalyse ist der etablierte Weg, dies nachvollziehbar zu leisten. Die FDA Human Factors Guidance erwartet sie ausdrücklich als Grundlage für die Bestimmung kritischer Aufgaben.
Wer sollte an einer Aufgabenanalyse beteiligt sein?
Neben Human-Factors-Fachleuten sollten Anwender aus allen vorgesehenen Benutzerprofilen einbezogen werden, ergänzt um klinische Fachexpertise und Vertreter der Entwicklung. Eine Analyse, die ausschließlich intern erstellt wird, bildet erfahrungsgemäß den gedachten und nicht den tatsächlichen Ablauf ab.
Die Aufgabenanalyse ist der Schritt, an dem sich entscheidet, ob der spätere Usability-Nachweis das Richtige prüft. Sie zerlegt die Nutzung so weit, dass Fehlerpotenziale sichtbar und kritische Aufgaben identifizierbar werden – und liefert damit die Grundlage für Nutzungsszenarien, Nutzungsrisikoanalyse und summative Validierung.
Entscheidend ist der Zugang zur realen Nutzung: Eine Aufgabenanalyse, die den dokumentierten statt den gelebten Ablauf beschreibt, erzeugt Dokumentation ohne Erkenntnis.
Sie brauchen eine Aufgabenanalyse, die bis in die Nutzungsrisikoanalyse trägt? Wir unterstützen Sie im gesamten Usability-Engineering-Prozess nach IEC 62366-1 – von der Analyse bis zur sicheren Validierung.
Mehr zu unserem Usability Engineering