Usability & IEC 62366

Hier finden Sie Informationen zur Gebrauchstauglichkeit (Usability) von Medizinprodukten und zu regulatorischen Anforderungen wie die der FDA und der IEC 62366.

Artikel zur Einführung

Artikel zu Regularien und Normen (z.B. IEC 62366)

Artikel zu „Best Practice Guides“

Artikel zum Usability und Requirements-Engineering

Artikel zur Prüfung der Gebrauchstauglichkeit

Prof. Dr. Christian Johner
Wünschen Sie Unterstützung dabei, wirklich gebrauchstaugliche Medizinprodukte zu entwickeln und IEC-62366- bzw. FDA-konform zu dokumentieren? Professor Johner und sein Team helfen gerne! Nehmen Sie Kontakt auf!

Definition des Begriffs „Gebrauchstauglichkeit“ („Usability“)

Die FDA sagt, dass der Begriff Usability häufig mit Design verwechselt würde, weshalb man besser den Begriff „Human Factors Engineering“ nutzen sollten. In der Tat, Usability hat erst einmal nichts mit schicken Farben und Schlagschatten oder trendigen Design-Elementen zu tun.

Definition der Gebrauchstauglichkeit gemäß ISO 9241

Die ISO 9241 definiert Gebrauchstauglichkeit/Usability als das Ausmaß, in dem ein interaktives System durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.

Wichtig bei dieser Definition ist, dass die Gebrauchstauglichkeit eines Medizinprodukts keine absolute Eigenschaft ist, sondern von den Charakteristiken der Nutzer und der Nutzungsumgebung abhängt.

Definition der Gebrauchstauglichkeit gemäß IEC 62366

Leider unterscheidet sich die Definition des Begriffs Gebrauchstauglichkeit bei der IEC 62366 etwas von der der ISO 9241. Laut IEC 62366 versteht man unter Gebrauchstauglichkeit die Eigenschaft der Benutzer- Produkt-Schnittstelle, die die Effektivität, Effizienz, Lernförderlichkeit und Zufriedenstellung des Benutzers umfasst.

Probleme durch mangelnde Gebrauchstauglichkeit

Die MTD schreibt in einem Artikel: „Nach Prof. Dr. Uvo Hölscher/FH Münster gehen Experten von 17.000 vermeidbaren Anwendungsfehlern mit Todesfolge pro Jahr in deutschen Krankenhäusern aus. Zwei Drittel aller unerwünschten Ereignisse im Rahmen der Medizintechnik beruhen auf Bedien- und nur ein Drittel auf Produktfehlern. […] An die Krankenhäuser appellierte Hölscher, die Ergonomie bei Einkaufsentscheidungen stärker zu berücksichtigen. Einfacheres, sicheres und schnelleres Bedienen würde langfristig zu Einsparungen führen.”

Damit werden die Hersteller nun von zwei Seiten gedrängt, die Gebrauchstauglichkeit ihrer Produkte zu verbessern. Von den Kunden (den Krankenhäusern) ebenso wie von den benannten Stellen, die bei den Audits zunehmend auf die Einhaltung der Forderungen der IEC 62366 achten. Auch die FDA rückt die Gebrauchstauglichkeit (Usability) immer mehr ins Zentrum ihrer Prüfungen.

Gebrauchstauglichkeit: Regulatorischer Rahmen

a) Regulatorische Anforderungen in Europa

Forderungen der MDD nach Gebrauchstauglichkeit

Die Medizinprodukterichtlinie MDD und damit das Medizinproduktegesetz MPG fordern spätestens seit der Änderung durch die Richtlinie 2007/47/EC die Gebrauchstauglichkeit der Medizinprodukte. Insbesondere fordert die Richtlinie in Anhang I mit den grundlegenden Anforderungen, dass Hersteller die Risiken durch mangelnde Gebrauchstauglichkeit minimieren.

Konkret heißt es dort

1. Die Produkte müssen so ausgelegt und hergestellt sein, dass ihre Anwendung unter den vorgesehenen Bedingungen und zu den vorgesehenen Zwecken weder den klinischen Zustand und die Sicherheit der Patienten noch die Sicherheit und die Gesundheit der Anwender oder gegebenenfalls Dritter gefährdet, wobei etwaige Risiken im Zusammenhang mit der vorgesehenen Anwendung gemessen am Nutzen für den Patienten vertretbar und mit einem hohen Maß an Gesundheitsschutz und Sicherheit vereinbar sein müssen.

Dazu gehört

  • eine weitestgehende Verringerung der durch Anwendungsfehler bedingten Risiken aufgrund der ergonomischen Merkmale des Produkts und der Umgebungsbedingungen, in denen das Produkt eingesetzt werden soll (Produktauslegung im Hinblick auf die Sicherheit des Patienten), sowie
  • die Berücksichtigung der technischen Kenntnisse, der Erfahrung, Aus- und Weiterbildung sowie gegebenenfalls der medizinischen und physischen Voraussetzungen der vorgesehenen Anwender (Produktauslegung für Laien, Fachleute, Behinderte oder sonstige Anwender).“

Mir gefällt dies deshalb so gut, weil man klar macht, dass Gebrauchstauglichkeit keine absolute Eigenschaft eines Produkts ist, sondern eine, die nur im Zusammenspiel mit den tatsächlichen Nutzern und dem tatsächlichen Nutzungskontext beurteilt werden kann.

Nehmen Sie das Thema nicht auf die leichte Schulter. Die benannten Stellen rüsten auf (-> bilden sich weiter) und machen es zunehmend zum Gegenstand bei Audits. Wo und wie Sie aufrüsten können, wissen Sie ja.

Forderungen der MDR

Die MDR misst der Usability große Relevanz zu. Sie finden Anforderungen daran u.a. in folgenden Kapiteln:

  • Anhang I (I) 5.In eliminating or reducing risks related to use error, the manufacturer shall:
    • (a) reduce as far as possible the risks related to the ergonomic features of the device and the environment in which the device is intended to be used (design for patient safety), and
    • (b) give consideration to the technical knowledge, experience, education, training and use environment, where applicable, and the medical and physical conditions of intended users (design for lay, professional, disabled or other users).
  • Anhang I (II) 14.6.:
    Any measurement, monitoring or display scale shall be designed and manufactured in line with ergonomic principles, taking account of the intended purpose, users and the environmental conditions in which the devices are intended to be used. 
  • Anhang I (II) 22.2:
    Devices for use by lay persons shall be designed and manufactured in such a way as to:

    • ensure that the device can be used safely and accurately by the intended user at all stages of the procedure, if necessary after appropriate training and/or information,
    • reduce, as far as possible and appropriate, the risk from unintended cuts and pricks such as needle stick injuries, and
    • reduce as far as possible the risk of error by the intended user in the handling of the device and, if applicable, in the interpretation of the results.
  • Anhang I (II) 22.3:
    Devices for use by lay persons shall, where appropriate, include a procedure by which the lay person:

    • can verify that, at the time of use, the device will perform as intended by the manufacturer, and
    • if applicable, is warned if the device has failed to provide a valid result.
  • Anhang I (III): „Requirements regarding the information supplied with the device“
  • Anhang II 6. („Product verification and validation“):
    The documentation shall contain the results and critical analyses of all verifications and validation tests and/or studies […]
    (a) results of tests, such as engineering, laboratory, simulated use and animal tests, and evaluation of published literature applicable to the device, taking into account its intended purpose, or to similar devices, regarding the pre-clinical safety of the device and its conformity with the specifications;

Auch im Rahmen des Post-Market Clinical Follow-ups und der Post-Market Surveillance spielt die Usability eine Rolle: Rückmeldungen der Anwender und Informationen über Probleme (auch Nutzungsprobleme) müssen systematisch gesammelt und bewertet werden.

Zusammenspiel mit der IEC 62366

Die Hersteller von Medizinprodukten können im Rahmen einer Konformitätsbewertung (Auditoren, benannte Stellen) vermuten lassen, dass sie diese Forderungen erfüllen, wenn sie ihre Medizinprodukte konform der IEC 62366 entwickeln. Diese Norm trägt den Titel „Medizinprodukte – Anwendung der Gebrauchstauglichkeit auf Medizinprodukte“ auf Englisch „Medical devices – Application of usability engineering to medical devices“.

b) Regulatorische Anforderungen in den USA

21 CFR part 820

Hersteller müssen die Anforderungen des 21 CFR part 820 erfüllen. Dazu zählen auch die Design Controls des 21 CFR part 820.30. Die wiederum verlangen ein Risikomanagement, das auch Risiken durch mangelnde Gebrauchstauglichkeit betrachten muss.

Guidance Document der FDA

Konkreter wir die FDA im  „Guidance Document“ dem Titel „Applying Human Factors and Usability Engineering to Optimize Medical Device Design“.  Dieses Dokument ist aber keine Norm. Entsprechend hat es nicht die gleiche sprachliche Reduktion und Präzision. Teilweise gleicht es mehr einem Lehrbuchcharakter als eine Liste konkreter Forderungen — obwohl es dieser viele beinhaltet.

Zwar fordert das Guidance Dokument keinen so detaillierten Prozess wie die IEC 62366 und orientiert sich in etwa an dem der ISO 14971. Dafür sind aber die anzuwendenden Verfahren erwähnt, die in der IEC 62366 bestenfalls im Anhang zu finden sind. Bei Widersprüchen mit anderen Standards wie der 62366 aber auch dem AAMI HE 75 nimmt das Guidance Dokument in Anspruch Vorrang zu haben!

Weitere regulatorische Anforderungen in den USA

Nicht nur die US-Gesundheitsbehörde (FDA), sondern weitere Behörden stellen Anforderungen an die Gebrauchstauglichkeit:

  • Der 36 CFR Part 1195 beschreibt „Standards for Accessible Medical Diagnostic Equipment“. Es geht also um medizinische Produkte! Lesen Sie dazu hier mehr.
  • Insbesondere Anbieter von Mobile Apps und Webseiten sollten den „Americans with Disabilities Act“ (kurz ADA) beachten. Es geht um die Barrierefreiheit, die auch auf digitale Produkte des „öffentlichen Raums“ ausgedehnt wird. Zum Thema Barrierefreiheit bei Medizinprodukten finden Sie hier einen Artikel.
  • Ebenfalls im Kontext der Barrierefreiheit sind zu beachten die Section 508 Guidelines. Diese Vorschriften betreffen zunächst die digitalen Angebote der staatlichen Institutionen. Doch leitet man auch hieraus Anforderungen an kommerzielle / öffentliche Angebote ab.

c) Regulatorische Anforderungen der britischen MHRA

Noch ist Großbritannien ein Teil der EU. Entsprechen gelten die dortigen EU-Richtlinien (MDD) bzw. EU-Verordnungen (MDR), die bereits oben besprochen wurden.

Unabhängig davon hat die britische „Medicine & Healthcare Products Regulatory Agency“ einen Leitfaden („Human Factors and Usability Engineering –
Guidance for Medical Devices Including Drug-device Combination Products“) herausgegeben
. Dieser Leitfaden ist in mehrerer Hinsicht beachtenswert:

  1. Der Leitfaden referenziert Dokumente der FDA
  2. Er benennt genau die Stellen in der Medizinprodukterichtlinie, an denen laut MHRA entsprechende grundelegende (und damit gesetzliche) Anforderungen gestellt werden.
  3. Er stellt einen beispielhaften Usability Engineering Prozess vor.
  4. Der Leitfaden ordnet den Phasen dieses Prozesses Methoden zu wie „cognitive walkthrough“, „Personas“ usw.

Der Leitfaden stellt somit keine neuen Anforderungen, hilft aber die gesetzlichen Anforderungen umzusetzen. Genau das haben sich die IEC 62366-1 und IEC 62366-2 auch vorgenommen.

Die Norm IEC 62366

Forderungen der IEC 62366

Die Norm beschreibt v.a. einen „gebrauchstauglichkeitsorientierten Entwicklungsprozess“, auf Englisch „Usability Engineering Process“. Im Rahmen dieses Prozesses müssen die Hersteller

  • den Nutzungskontext, die Nutzer, die Patienten und das physikalische Prinzip des Produkts beschreiben (die IEC 62366 spricht etwas irreführend von der Spezifikation der Anwendung),
  • die Gebrauchstauglichkeit ihrer „Medical Devices“ spezifizieren,
  • die Gebrauchstauglichkeit verifizieren und
  • validieren. Erfahren Sie hier mehr zur (Usability) Validierung von Medizinprodukten.

An all diese Aktivitäten stellt IEC 62366 Anforderungen. Beispielsweise müssen bei der Validierung repräsentative Benutzer in einer repräsentativen Gebrauchsumgebung dabei beobachtet werden, wie diese typische und sicherheitskritische Aufgaben am System erfüllen.

Zusammenspiel mit dem Risikomanagement

Der Fokus der IEC 62366 liegt eindeutig auf der Minimierung des Risikos durch mangelnde Gebrauchstauglichkeit. Weitere Ziele des Usability Engineerings wie höherer Markterfolg der (Medizin-)Produkte und die effiziente Entwicklung (ohne unnötige Iteratiionen) werden von der IEC 62366 nicht adressiert.

Usability Engineering und Requirements Engineering

Medizinprodukte sind definitionsgemäß genau dann gebrauchstauglich, wenn spezifizierte Nutzer im spezifizierten Nutzungskontext die spezifizierten Aufgaben effektiv, effizient und zufriedenstellend erreichen können. Eine zwingende Voraussetzung dafür ist, dass die Nutzungsanforderungen (dieser Nutzer) erfüllt sind. Genau dies ist die Aufgabe des Requirements Engineerings, auch wenn die IEC 62366 auf diesen Aspekt kaum eingeht.

Usability Prüfungen

In einer Schulung fragte ein Kunde, welches denn der richtige Begriff für das Prüfen von Benutzerschnittstellen sei. Er sei verwirrt. Das kann man gut nachvollziehen. Ohne das Thema umfassend darstellen zu wollen, hier eine kleine Taxonomie an Begriffen:

Die Prüfung ist sicher der allgemeinste Begriff. Man unterscheidet dann auf der nächsten Ebene die Verifizierung (Prüfung, ob spezifizierte Produkteigenschaften erfüllt sind) und Validierung (Prüfung, ob spezifizierte Nutzer im spezifizierten Nutzungskontext die spezifizierten Nutzungsziele effektiv, effizient und zur Zufriedenstellung erreichen).

Eine Verifizierung kann man automatisiert (Computer) und durch Personen, also durch ein Review durchführen. Dabei wird beispielsweise geprüft, ob spezifizierte Schriftgrößen, Kontrastverhältnisse oder Heuristiken eingehalten sind. Es gibt verschiedene Review-Verfahren unterschiedlichen Formalisierungsgrads wie den Walkthrough oder Inspektionen. Inspektionen gemein ist, dass Sie von Usability-Experten durchgeführt werden.

Weiterführende Informationen

Lesen Sie hier mehr zu den Usability-Prüfverfahren:

Zusammenspiel von Usability Engineering und Qualitätsmanagement

Das Qualitätsmanagement und Usability Engineering spielen eng zusammen: Während die ISO 13485 allgemeine Konzepte und Anforderungen formuliert, stellt die IEC 62366-1 konkrete Anforderungen im Kontext Usability (Gebrauchstauglichkeit). Dieser Beitrag zeigt das Mapping beider Normen.

Qualitätsmanagement
ISO 13485
Usability
IEC 62366-1
 Kapitel 5: Verantwortung der Leitung  6.1 Effective Usability Engineering programs
 Kapitel 6.1: Bereitstellung von Ressourcen 5.2 Reasons to invest in Usability Engineering
6.4 Ensure the necessary resources are available
6.9 Tailoring the Usability Engineering effort
 Kapitel 6.2: Personelle Ressourcen 6.3 Apply an appropriate level of Usability Engineering expertise
Kapitel 7.1: Planung der Produktrealisierung 6.9 Tailoring the Usability Engineering effort
Kapitel 7.3.1 Design und Entwicklungsplanung 12 Select the hazard related use scenarios for summative evaluation
14 Establish user interface evaluation plan
 Kapitel 7.3.2 Design und Entwicklungsvorgaben 8 Prepare the use specification
13 Establish user interface specification
Kapitel 7.3.3 Design und Entwicklungsergebnisse 15 Design and implement the user interface
Kapitel 7.3.4 Design und Entwicklungsbewertung 16 Perform formative evaluation
Kapitel 7.3.5 Design und Entwicklungsverifizierung 6.8 Usability Engineering file
15.7 Verify the User Interface
Kapitel 7.3.6 Design und Entwicklungsvalidierung 17 Perform summative evaluation
Kapitel 8 Messung, Analyse und Verbesserung 18 Post production review and analysis

Idee: IEC 62366 Normengremium

Diese Gegenüberstellung der Anforderungen aus dem Qualitätsmanagement und Usability Engineering kann Ihnen helfen, Ihre Verfahrensanweisungen ggf. zu konsolidieren, um zu vermeiden, dass Sie mehrere parallele aber eigentlich zusammengehörende Prozesse wie den Entwicklungsprozess und den Usability Engineering Prozess unabhängig voneinander pflegen und befolgen müssen.

Usability FAQs

Das Ziel dieses Usability FAQs besteht darin, Antworten auf häufige Fragen zu geben,

  • zu denen es keine eigenständige Blog-Beiträge gibt,
  • die kurz und knapp beantwortet werden können oder
  • bei denen die Antwort nicht nur auf streng kanonisches Wissen zurückgreift.

Usability FAQ

#1 Beeinflusst die technische Realisierung nicht die UI-Spezifikation?

Hintergrund

Wir plädieren dafür, die UI-Spezifikation möglichst zu Beginn von Usability Experten erstellen zu lassen und diese Spezifikation nicht möglichst lange im Unklaren zu lassen und letztlich implizit von Entwicklern erstellen zu lassen.

Frage an diesen Usability FAQ

Die erste Frage in unserem Usability FAQ stellt diesen Ansatz in Frage. Schließlich könnte man zu diesem frühen Zeitpunkt gar nicht wissen, ob man das Spezifizierte später überhaupt umsetzen kann. Dies sei ein „Wasserfall-Denken“, das nur bei kleinen Projekten funktionieren würde.

Antwort

In der Tat kommt es vor, dass in der UI-Spezifikation etwas festgelegt wird, was man derzeit technisch nicht realisieren kann, sei es weil die Technologie nicht so weit ist oder Ressourcen oder Zeit fehlen.

Das wird und muss dazu führen, dass man nochmals „zurückgehen“ muss und die UI an diese Limitierungen anpasst. Das ist absolut zutreffend. Aber kein Gegenargument!:

  1. Gerade für das Produktmanagement ist es essentiell wichtig zu wissen, wie das perfekte Produkt „aussehen“ sollte. Man spricht von der Release-unabhängigen Version. Das ist das Fernziel, dem sich alle künftigen Releases Stück für Stück nähern müssen.
    Fazit: Wir benötigen dieses Fernziel, das wir nur über ein systematisches Usability und Requirements Engineering ableiten können.
    Firmen wie SAP haben teilweise Durchbrüche erreicht, als Produktmanager die Datenbanken nach Anforderungen durchforstet haben, die man angeblich nicht umsetzen kann. Dann hat man es getan und Quantensprünge geschafft.
  2. Die Erfahrung zeigt, dass weit mehr als 90% aller Anforderungen in einer UI-Spezifikation technisch umsetzbar sind. Welchen Sinn würde es ergeben, wegen weniger als 10% an Anforderungen, die man nochmals ändern muss, die komplette Systematik über den Haufen zu werfen?
    Wenn wir bei 5% der Operationen trotz Händedesinfektion Infektionen haben, sollen wir dann auf das Desinfizieren der Hände verzichten?
    Fazit: Wir unterschätzen die technische Machbarkeit und überschätzen unsere Fähigkeit gebrauchstaugliche Oberflächen durch nicht systematisches Vorgehen spezifizieren zu können.
  3. Wenn es sich herausstellen sollte, dass sich eine Anforderung technisch nicht realisieren lässt, welche Änderungen soll man dann an der UI machen? Die Antwort wird wieder nur das Usability und Requirements Engineering geben können. Denn nur hier sind die Erfordernisse identifiziert worden. Nur hier können wir beurteilen, ob die Änderung nur die Zufriedenstellung oder auch die Effizienz oder sogar die Effektivität beeinflussen wird.
    Fazit: Wir benötigen das Usability und Requirements Engineering um auf Limitierungen bei der technischen Machbarkeit reagieren zu können.

Uns sollte auch klar sein, dass auch das beste Usability und Requirements Engineering nicht immer zur perfekten UI-Spezifikationen führt. Aber wir sparen ein Vielfaches der eingesetzten Zeit, wenn wir mit einer 90% korrekten Spezifikation die Entwicklung starten statt mit 50%. Und mit einem frühen UI Prototyp können wir diesen Prozentsatz noch weiter erhöhen.

Ganz unabhängig davon sollte den Kritikern folgendes klar sein:

Produkte ohne eine entwicklungsbegleitende Bewertung der Gebrauchstauglichkeit zu entwickeln, ist nicht nur wenig klug, sondern schlichtweg im Widerspruch zu den Anforderungen der IEC 62366:2015 und FDA.

#2 Wie granular sollte eine UI Spezifikation sein?

Hintergrund

Wir plädieren dafür, die UI-Spezifikation nicht nur möglichst früh im Prozess, sondern möglichst präzise („pixelgenau?“) zu spezifizieren. Das führt zu der Befürchtung, damit einen unnötig hohen Aufwand zu betreiben, sowohl für das initiale Erstellen als auch für das kontinuierliche Anpassen dieser Spezifikation.

Frage

Die IEC 62366 erläutert nicht genau, was genau unter der „Usability Spezifikation“ zu verstehen ist. Daher die Frage:

Wie präzise sollte eine UI-Spezifikation sein? Was spricht für und gegen eine genaue Spezifikation?

Antwort

Teil 1: Regulatorische Brille

Die IEC 62366 lässt Ihnen in der Tat hohe Freiheitsgrade, wie konkret Sie die Anforderungen an die Usability bzw. das UI Ihrer Produkte formulieren. Die IEC 62366-1:2015 fordert aber, dass

  1. Sie alle Benutzungsszenarien festgelegt und bewertet haben, ob diese sicherheitsbezogen sind,
  2. Sie alle Hauptbedienfunktionen identifiziert haben und
  3. Sie eine entwicklungsbegleitende Bewertung der Gebrauchstauglichkeit vornehmen.

Wenn Sie diesen Forderungen nachkommen, wissen Sie bereits

  • welche UI-Elemente (insbesondere Nutzungsobjekte und Werkzeuge) existieren (und ob diese sicherheitsrelevant sind — sonst können Sie die Hauptbedienfunktionen nicht identifizieren),
  • in welcher Reihenfolge diese Elemente Ihren Nutzern angeboten werden (sonst kennen Sie die Nutzungsszenarien nicht)
  • ob Ihr Entwurf der Benutzer-Produkt-Schnittstelle (UI) gebrauchstauglich ist.

Wenn Sie über alle diese Informationen verfügen, haben Sie das UI bereits sehr präzise spezifiziert.

Teil 2: Aus Brille der Entwicklung

Spezifizieren Sie die Benutzer-Produkt-Schnittstelle so präzise, dass die verbliebenen Freiheitsgrade es unwahrscheinlich machen, dass ein UI entwickelt wird, das die Erwartungen (Marktanforderungen) und Ansprüche nach Gebrauchstauglichkeit nicht erfüllt.

Solch eine Spezifikation muss keineswegs pixelgenau sein. Mockups bzw. Wireframes, die die ungefähre Position von UI-Elementen festlegen, zusammen mit einem Style-Guide sollten Ihnen die notwendige Genauigkeit Ihrer Spezifikation gewährleisten und helfen, kostenintensive und zeitaufwendige Nachbesserungen zu vermeiden.

#3 Geht das auch bei großen Projekten?

Die dritte Frage im Usability-FAQ soll Ihnen als Argumentationshilfe dienen, wenn Vorgesetzte, Kollegen oder Kunden glaube, dass ein systematisches Identifizieren von Anforderungen und konsequentes Ableiten einer Benutzer-Schnittstelle, wie wir es in den Artikeln hier beschreiben, in der Praxis gar nicht funktionieren würde.

Das geht nicht bei großen und komplexen Projekten!?!

Die Verfahren funktionieren unabhängig von der Größe. Das wurde in unzähligen Projekten bewiesen. Vielmehr ist das Gegenteil korrekt:

Während man bei kleinen und weniger komplexen Projekten Fehler leichter beheben kann – und Fehler mit einer geringeren Wahrscheinlichkeit macht – kommt man bei großen Projekten ohne ein systematisches Vorgehen überhaupt nicht mehr aus. Wir Menschen sind mit Umfang und Komplexität der Aufgaben schlichtweg überfordert. Unser Gehirn kann das nicht leisten.

Es kommt noch schlimmer: Viele der großen Projekte sind gar nicht komplex, sondern nur groß. Wir sind nur überfordert und machen etwas Komplexes daraus. Wirklich gute Lösungen zeichnen sich durch eine Einfachheit aus, von der jeder nachher sagt: „Ist ja klar, was soll da so schwierig sein.“ Diese Einfachheit zu erreichen, ist das Ziel und die Fähigkeit guter Methoden bzw. Verfahren.

Fazit: Große Produkte sind nicht notwendigerweise komplex. Ob große Projekte tatsächlich komplex sind, bekommen Sie nur durch systematisches Usability und Requirements Engineering heraus.

Wir haben beispielsweise einst einen Hersteller einer Bestrahlungsplanungssoftware unterstützt, dessen UI vor UI-Elementen wie Parametern, Controls usw. überquoll. Die Algorithmik dahinter entstammte mehrere Doktor- und Habilitationsarbeiten von Mathmatikern, Physikern und Ärzten. Mathematisch war die Sache höchst komplex. Es stellte sich aber heraus, dass die (fast) einzige Nutzungsanforderungen lautete: „Der Nutzer muss am System den zu planenden Patienten auswählen können“. Können Sie sich vorstellen, wie wenig komplex das finale UI war?

Fazit: Die Komplexität „unter der Haube“ hat nichts mit der Komplexität „über der Haube“ zu tun. Den Unterschied bekommen Sie nur durch systematisches Usability und Requirements Engineering heraus.

Kleine und große Projekte/Produkte unterscheiden sich oft primär in der Anzahl der unterstützten Benutzer und der unterstützten Kernaufgabe. Erst die klare Identifizierung der Nutzergruppen und Kernaufgaben hilft Ihnen, gebrauchstaugliche Produkte zu entwickeln.

Viele Firmen haben das aber nicht verstanden und Produkte entwickelt, die alle Kernaufgabe für alle Nutzergruppen (gleichzeitig) unterstützen sollen. Das traurige Paradebeispiel ist SAP. Als Ergebnis hat man gebrauchsuntaugliche und komplexe Produkte.

Fazit: Ein systematisches Usability und Requirements Engineering hilft, die Komplexität zu reduzieren.

Das funktioniert nicht bei vielen Mitwirkenden!?!

Häufig hört man Argumente wie „Bei uns arbeiten viele Personen an dem Produkt mit. Da können nicht einige wenige zu einem frühen Zeitpunkt im Projekt eine Benutzer-Schnittstelle spezifizieren, ohne zu wissen, ob das technisch überhaupt machbar ist.“ Dieser Satz offenbart bereits das Missverständnis:

Die Tatsache, dass so viele Leute mitarbeiten, ist nicht Ursache des Problems sondern die Folge. Gerade weil wir so viele Entwickler haben, möchte man die produktiv halten. Deshalb fangen die an zu entwickeln.

Weil Entwickler aber in ihrer Rolle als Entwickler Entwickler sind und keine Usability bzw. Requirements Engineers, entwickeln sie Produkte, deren Gebrauchstauglichkeit suboptimal ist. Das führt wiederum dazu, dass man häufig nachbessern muss. Und dafür braucht man viele Entwickler.

Die meisten Firmen haben zu viel Entwickler, nicht zu wenige. Das sage ich als Entwickler!

Weitere Informationen


Mittwoch 3. Mai 2017 von Prof. Dr. Christian Johner

Der FDA Usability Guidance ist seit dem 3. Februar 2016 „amtlich“: Nach viereinhalb Jahren hat das FDA Guidance Dokument „Applying Human Factors and Usability Engineering to Medical Devices“ das Entwurfsstadium verlassen und beschreibt die Sicht der Behörde zum Usability Engineeering.

Sie können das Guidance Document hier herunterladen.

Den ganzen Beitrag lesen »


Dienstag 2. Mai 2017 von Prof. Dr. Christian Johner

Der AAMI HE 75 trägt den Titel „Human Factor Engineering – Design of Medical Devices”.

Erfahren Sie in diesem Artikel, was dessen Inhalte sind und wann Sie dieses mit 445 Seiten sehr umfangreiche Werk überhaupt lesen sollten. Damit können Sie (z.B. als Usability Engineer) entscheiden, ob sich der Kauf des AAMI HE 75 für $390 lohnt.

Den ganzen Beitrag lesen »


Dienstag 21. März 2017 von Prof. Dr. Christian Johner

Unter der Barrierefreiheit – auf englisch Accessibility – versteht man die Gestaltung von Angeboten, die auch von Menschen mit körperlichen Einschränkungen genutzt werden können. Der Begriff Angebote umfasst Bauwerke ebenso wie digitale und nicht-digitale Produkte. Das schließt auch Medizinprodukte (Geräte, App, stand-alone Software) mit ein.

Welche Anforderungen an die Accessibility Hersteller von Medizinprodukten beachten sollten, um der wachsenden Anzahl an Klagen zu entgehen, erfahren Sie in diesem Beitrag.

Finden Sie heraus, wie ein Mensch mit Sehbehinderung eine Webseite „erfährt“.

Den ganzen Beitrag lesen »


Donnerstag 23. Februar 2017 von Prof. Dr. Christian Johner

Lastenheft und Pflichtenheft, Systemspezifikation und Systemanforderungen:
Die Vorstellungen darüber, was diese Dokumente enthalten müssen, gehen weit auseinander – manchmal auch innerhalb einer Firma.

Lastenheft und PflichtenheftRegelmäßig beobachte ich, dass alle mehrere Dokumente etwa die gleichen Anforderungen beschreiben. Nur in der Granularität und dem Detailgrad unterscheiden sie sich. Schon aus regulatorischer Sicht sollten Sie die Begriffe Lastenheft und Pflichtenheft gegeneinander abgrenzen.

Den ganzen Beitrag lesen »


Dienstag 20. September 2016 von Prof. Dr. Christian Johner

Anormaler Gebrauch: Eine von vielen möglichen Fehlhandlungen

Irrtum, Benutzungsfehler, anormaler Gebrauch, Aufmerksamkeitsfehler, vernünftigerweise vorhersehbarer Erinnerungsfehler, vorhersehbarer Missbrauch. Die Liste möglicher (Fehl-) Handlungen ist lang, die die Normen betrachtet haben möchten.

Doch Vorsicht: Die Normen zur Gebrauchstauglichkeit (IEC 62366:2007 und IEC 62366-1:2015) und die Norm zum Risikomanagement (ISO 14971) verwenden unterschiedliche Begriffe.

Dieser Artikel bringt Licht ins Dunkel.

Den ganzen Beitrag lesen »


Montag 1. August 2016 von Prof. Dr. Christian Johner

Formative Bewertung und summative Bewertung sind die eingedeutschten und nicht korrekt übersetzten Versionen der englischen Begriffe „formative evaluation“ bzw. „summative evaluation“. Die für das Usability Engineering relevanten Regularien fordern beide Bewertungen.

Lesen Sie in einem weiteren Artikel mehr zur summativen Bewertung.

Den ganzen Beitrag lesen »


Montag 18. Juli 2016 von Prof. Dr. Christian Johner

Die IEC 62366-1:2015 ist seit Februar 2015 veröffentlicht. Die deutsche Ausgabe wird bald folgen. Dieser Artikel

  • berichtet über die aktuellen Entwicklungen (Veröffentlichungstermin der DIN EN IEC 62366-1, Anhang ZZ),
  • nennt die wichtigsten Unterschiede zwischen der IEC 62366-1:2015 und IEC 62366:2007 und
  • beschreibt, wie vollständig die grundlegenden Anforderungen durch die Norm als erfüllt vermutet werden dürfen.

Den ganzen Beitrag lesen »


Montag 27. Juni 2016 von Prof. Dr. Christian Johner

Unter einem Usability Lab versteht man eine Einrichtung, in der man Gebrauchsumgebungen für Usability Tests (Usability Validierung) simuliert und diese Prüfungen durchführt. In diesem Beitrag erfahren Sie,

  1. auf was Sie bei der Wahl eines Usability Labs achten sollten,
  2. was die Kosten für ein Usability Lab bzw. von Usability Tests sind und
  3. welche Rolle das Usability Lab spielen kann.

Den ganzen Beitrag lesen »


Mittwoch 16. März 2016 von Prof. Dr. Christian Johner

In diesem Artikel lesen Sie, welche Anforderungen die FDA an das Human Factors Engineering HFE stellt, an welche Produkte die FDA diese Anforderungen stellt und wie Sie diese Anforderungen umsetzen.

Den ganzen Beitrag lesen »


Freitag 5. Februar 2016 von Prof. Dr. Christian Johner

Die Uses Cases, auf Deutsch Anwendungsfälle, finden im Gegensatz zu User Stories in der agilen Entwicklung nicht mehr so viel Verwendung. Kann man mit der Modellierung von Use Cases zumindest die Forderungen der IEC 62366-1:2015 nach Benutzungsszenarien erfüllen? Sind die Begriffe Use Case und Benutzungsszenario synonym zu verstehen? Dieser Beitrag gibt Ihnen Antworten und Tipps.

Den ganzen Beitrag lesen »