Das User Centered Design zielt darauf ab, künftige Anwender von Anfang an in die Entwicklung einzubeziehen. So einleuchtend dieser Ansatz klingt, so häufig führt er zu fatalen Fehlentwicklungen. Sie erreichen das Gegenteil dessen, was Sie wollten, nämlich unsichere und gebrauchsuntaugliche Produkte, die gegen regulatorische Vorgaben verstoßen.
Doch mit drei Schritten wird es gelingen, das wirkliche Ziel des User Centered Designs zu erreichen: Gebrauchstaugliche Produkte, mit denen
- Nutzer ihre Patienten sicher und wirksam diagnostizieren, behandeln und überwachen können,
- Hersteller im Markt erfolgreich und
- Behörden und Benannte Stellen einverstanden sind.
Besser wäre es, den Begriff „Human Centered Design“ anstelle von „User Centered Design“ zu verwendet. Damit wäre klarer, dass das Design auch die Interessensgruppen betrachtet, die keine Benutzer sind. In der Praxis werden jedoch beide Begriffe oft synonym verwendet.
1. User Centered Design: Weshalb Sie vorsichtig sein müssen
a) Nutzungsexperten sind keine Usability-Experten
Wenn Sie mit Nutzern über die Produktgestaltung sprechen, diskutieren Sie nicht die Nutzungsanforderungen, sondern eine Systemspezifikation (Systemanforderungen).
Das ist auch wenig überraschend, denn Nutzer sind Experten für den Nutzungskontext. Sie kennen die damit verbundenen Aufgaben, Probleme, Ziele, Voraussetzungen, Rollen usw. genau.
Nutzer sind aber keine Usability-, Requirements- oder Produktexperten. Sie sind keine Interaktionsdesigner. Sie verfügen in ihrer Rolle als Nutzer nicht über die Kompetenz, gebrauchstaugliche Nutzungsschnittstellen (UI) zu entwerfen.
b) Schmerzliche Folgen eines suboptimalen User Centered Designs
Wenn Sie das User Centered Design nicht richtig anwenden, kann es aus Sicht des Nutzers zu drei Problemen führen:
- Die vorhandene Funktionalität ist schlecht abrufbar.
- Notwendige Funktionalität fehlt.
- Stattdessen ist nicht notwendige Funktionalität vorhanden.
Für Sie kann das bedeuten:
- Die Nutzer erreichen ihre Nutzungsziele nicht oder nicht effizient. Dadurch ist die Nutzung des Produkts unsicher, gefährdet die Patienten und führt zu regulatorischen Risiken.
- Die Nutzer sind aus anderen Gründen mit der Nutzung unzufrieden und ziehen Wettbewerbsprodukte vor.
- Sie haben unnötig Geld für ein suboptimales User Centered Design ausgegeben.
c) Notwendige Erkenntnisse für die Hersteller
Das bedeutet aber nicht, dass Sie als Medizinproduktehersteller keine Nutzer einbeziehen sollten. Im Gegenteil: Nur dann können Sie im Rahmen einer Kontextanalyse die Nutzungsanforderungen erheben.
Nutzer verfügen über Problemwissen. Entwickler verfügen über Lösungswissen. Die Usability- und Requirements-Engineers sprechen die Sprache beider Gruppen. Sie verfügen über die Fähigkeit, Produkte zu spezifizieren, mit denen die Nutzer ihre Nutzungsziele erreichen können.
2. In 3 Schritten zum erfolgreichen und IEC-62366-1 konformen Produkt
User Centered Design setzt vor der eigentlichen Entwicklung des Produkts an. Richtig eingesetzt, unterstützt es Sie bei der Entwicklung von Produkten, die ihre Anwender begeistern. Damit sichern Sie auch den ökonomischen Erfolg ihres Produkts. Wird User Centered Design richtig angewendet, hilft es gleichzeitig, die Anforderungen der IEC 62366-1 zu erfüllen.
Schritt 1: Nutzungskontextanalyse
Vor der eigentlichen Produktentwicklung starten Sie mit der Nutzungskontextanalyse. In dieser Phase lernen Sie viel über die zukünftigen Anwender und deren Kontext:
- Genaue Kenntnis der tatsächlichen Anwender und deren Nutzungsumgebung
- Genaue Kenntnis der durch das Produkt zu lösenden Probleme
Daraus können Sie präzise Nutzungsanforderungen ableiten. Diese können Sie dann in die relevanten Systemanforderungen übersetzen.
Zum Nutzungskontext der Anwender gehören immer die Aufgaben, die Arbeitsmittel und die Umgebung, in der der Anwender das Produkt einsetzt.
Nutzungsanforderungen sind nicht gleich Systemanforderungen an das Produkt, sie beschreiben die Probleme des Nutzers. Nutzer können keine Anforderungen beschreiben, sie beschreiben ihre Ziele!
Lesen Sie hier mehr über Nutzungsanforderungen.
2. Schritt: Design und Implementierung
Wenn Sie die Nutzungsanforderungen spezifiziert haben, überführen Sie diese in Systemanforderungen und entwickeln Sie erste Prototypen. Diese testen Sie iterativ in formativen Usability-Evaluationen, ggf. mit Anwendern (s. 3. Schritt). Die Ergebnisse der formativen Usability-Evaluation fließen wieder in die Produktentwicklung ein und Sie testen den nächsten Prototypen.
Starten können Sie mit Low-Fidelity-Prototypen. Dafür eigenen sich folgende Methoden:
- Papier-Prototyping
- Klickbare Wireframes
- Mockups aus dem 3D-Drucker
Wenn Sie mit der Produktentwicklung weiter fortgeschritten sind, können Sie mit den folgenden Methoden sogenannte High-Fidelity-Prototypen entwickeln.
- Visuell aufwendige Prototypen mit komplexeren Interaktionsmöglichkeiten
- Codierte und funktionale Prototypen
Lesen Sie hier mehr zum Thema Mockups beim Prototyping.
3. Schritt: Evaluation
Die Prototypen evaluieren Sie iterativ solange, bis Sie ein finales Produkt entwickelt haben. Abhängig vom Entwicklungsstand bieten sich Methoden an wie:
- Usability-Tests
- Cognitive Walkthroughs
- Heuristische Evaluationen
- A/B-Testing
Wenn das Produkt final ist, führen Sie eine letzte summative Usability-Evaluation in Form eines Usability-Tests durch.
Sie finden hier eine Übersicht über weitere Methoden des Usability-Testings beschrieben.
3. Fazit, Zusammenfassung
Der Glaube, dass man nur die Nutzer bei der Entwicklung eng genug einbinden müsse, um zu gebrauchstauglichen Produkten zu kommen, ist ein Irrglaube. Im schlimmsten Fall, beziehen Sie nur viele Menschen mit ein, die
- einfach nur ihre Meinung kundtun,
- Ihnen Zeit stehlen,
- Ihnen Lösungen vorschlagen, die gebrauchsuntauglich sind und
- im schlimmsten Fall Patienten gefährden.
Es gibt auch so etwas wie eine Schwarmdummheit.
Nutzer sind Experten für den Nutzungskontext. Aber in ihrer Rolle als Nutzer sind sie weder Requirements-Engineers noch Interaktionsdesigner noch Usability-Experten. Sie verfügen nicht über deren Kompetenzen und beherrschen nicht den Prozess einer normenkonformen, „gebrauchstauglichkeitsorientierten Entwicklung“, wie das die IEC 62366-1 nennt. Genau diese Fähigkeiten und Kompetenzen müssen Sie als Hersteller aber bestimmen und nachweisen, und zwar bei der Entwicklung jedes Produkts erneut!
Beziehen Sie daher die Nutzer bei der Entwicklung ihrer Produkte mit ein, befragen Sie sie im Rahmen von Kontextinterviews. Lassen Sie sie aber keine Spezifikationen mitbestimmen und beschränken Sie deren Rolle so, wie es die drei Schritte oben beschreiben.
Haben Sie Fragen zum Vorgehen beim User Centered Design? Das Team vom Johner Institut unterstützt Sie gerne bei jedem Schritt. Kontaktieren Sie uns gleich.
Sehr geehrter Herr Bader,
Danke für diesen Artikel – das Mißverständniss zwischen Nutzungs-, und Systemanforderungen kennen wir gut. Nutzer beschreiben eine zu lösende Aufgabe in einem Nutzungskontext. Um ein digitales Medizinprodukt zu etablieren mit Erfolgschancen muss diese Nutzungsanforderung erfüllt werden. Aufgabe des Designs ist es, diese zu übersetzen in ausführbare und technisch umsetzbare Lösungen. Design ist hier eine klassische T-Shape Funktion. Dazu benötigt es fundiertes Wissen aus Behavior-Design, User Interface Design und IT. Diese Übersetzungsaufgabe umfasst z.B. Pain/Gain Analysen, User Journeys, Personae Entwicklung (die fundierte Variante), Wissen um Evaluationsmethoden und (häufig unterschätzt) die Fähigkeit eine enorme Stamina an den Tag zu legen um Nutzungsanforderungen als zentralen Punkt der Softwareentwicklung zu verstehen.
Zwei kritische Anmerkungen, die sich auf Ihre Rollendefinitionen beziehen:
1) Der Usability-Engineer ist ein:e User Experience Designer:in, der/die Design studiert haben sollte um diese komplexe Aufgabenstellung zu handhaben und nicht ein Ingenieur der im IT-Studium ein Modul zu UX-Design durchlaufen hat. Das komplette System des UX-Design und der IEC-62366-1 basiert auf Designmethoden die in den letzten Jahrzehnten im Grafik-, und Produktdesign entwickelt wurden. Angefangen von Gregory (1966) Papanek&Fuller (1972), Niedderer (2007) oder Hassenzahl. Das von Ihnen beschriebene Gefahrenpotential basiert genau darauf, dass grundlegendes (Methoden)-Wissen und Verständnis fehlt.
2) Evaluation und ein daraus resultierender Iterationsprozess sind extrem wichtig. Die reine Qualitative Erhebung, summative Evaluation, ist aus unserer Perspektive nur bedingt zielführend. Sicherlich werden die Anforderungen der Norm erfüllt – nur beschreibt die Norm nun mal Faktoren einer Qualitätssicherung, nicht die eines potentiellen Erfolges. Der Unterschied zwischen Real-Life Usage und dem Usability Lab ist da. Diesen Gap zu überwinden, kann damit beginnen, dass zu Beginn Shadowings (Beobachtungen) durchgeführt werden. Diese Beobachtungen gilt es zu erfassen und zu synthtisieren in Produktideen zu übertragen. Genau dies lernen Designer:innen.
Besten Gruß
Liebe Frau Hanke,
vielen Dank für Ihre ergänzende Nachricht! Ich kann Ihnen nur voll und ganz zustimmen.
Beste Grüße,
Immanuel Bader
Ich halte den Artikel für einen „must read“ Beitrag. Zu oft wird HCD falsch gemacht und so schön erklärt findet sich die richtige Anwendung selten.
Vielen Dank Herr Wuttke!