Usability & IEC 62366-1

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

Artikel zur Einführung

• Definition des Begriffs Gebrauchstauglichkeit (Usability)
• FAQ zur Usability
• Weitere Informationen zur Usability: Seminare, Beratung und mehr

Artikel zu Regularien und Normen

• Gesetzliche Anforderungen in Europa und Zusammenspiel mit IEC 62366-1
• Gesetzliche Anforderungen in den USA
• Anforderungen in Großbritannien (MHRA)
• IEC 62366-1, die Norm zur Gebrauchstauglichkeit von Medizinprodukten.
• IEC TR 62366-2: Die Gebrauchsanweisung für die IEC 62366-1
• Mehr zu den Unterschieden der IEC 62366-1:2006 und IEC 62366-1:2015
• Tipps zur Festlegung von Hauptbedienfunktionen

Artikel zu Best Practice Guides

• Normenfamilie ISO 9241
• FDA Guidance Document „Applying Human Factors and Usability Engineering to Medical Devices„
• AAMI HE 75 „Human Factor Engineering – Design of Medical Devices“

Usability- und Requirements-Engineering

• Aufbau einer IEC 62366-1 und FDA-konformen Gebrauchstauglichkeitsakte
• Systematisches Erheben von Anforderungen (allgemein),
• insbesondere von Stakeholder-Anforderungen wie Nutzungsanforderungen
• Abgrenzung zu den Lastenheften und Pflichtenheften
• Ableiten von System-Anforderungen bzw. -Spezifikationen
• Schreiben von GUI-Spezifikation (und Abgrenzung zur Usability Spezifikation)

Prüfung der Gebrauchstauglichkeit

• Cognitive Walkthrough
• Heuristische Evaluierung
• Formative Bewertung und summative Bewertung
• Usability Validierung von Medizinprodukten
• Rekrutierung von Probanden für Usability-Tests
• Wie wir das Usability Testing (auch in USA) für Sie übernehmen können

Definition 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-1

Die Definition des Begriffs Gebrauchstauglichkeit bei der IEC 62366-1 ist sehr ähnlich: Eigenschaft des User Interfaces, die den Gebrauch unterstützt und damit Effektivität, Effizienz sowie Zufriedenheit des Users in der festgelegten Nutzungsumgebung erzielt.

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 auf die Einhaltung der Forderungen der IEC 62366-1 achten. Auch die FDA rückt die Gebrauchstauglichkeit (Usability) ins Zentrum ihrer Prüfungen.

Regulatorischer Rahmen

a) Regulatorische Anforderungen in Europa

Forderungen der MDR

Die MDR misst der Usability große Relevanz bei. 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.

Forderungen der IVDR

Analog zu Medizinprodukten gilt für In-vitro–Diagnostika (IVD) die IVDR in der EU, welche ebenfalls Anforderungen an die Usability bzw. Ergonomie stellt. Insbesondre ist Anhang I Absatz 19.2 beachtenswert. Dort wird explizit gefordert, dass Produkte zur Eigenanwendung und patientennahe Tests (Point of care-; Bedside-Produkte) vom Anwender „in allen Bedienungsphasen sicher und fehlerfrei“ verwendet werden können.

Zusammenspiel mit der IEC 62366-1

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-1 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-1 und orientiert sich in etwa an dem der ISO 14971. Dafür sind aber die anzuwendenden Verfahren erwähnt, die in der IEC 62366-1 bestenfalls im Anhang zu finden sind. Bei Widersprüchen mit anderen Standards wie der 62366-1 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

Die britische „Medicine & Healthcare Products Regulatory Agency“ hat 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-1

Forderungen der IEC 62366-1

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

• die vorgesehene medizinische Indikation, die Patienten-Gruppen, vorgesehenes Körperteil oder Gewebetyp, User Profile, Nutzungsumgebung und das Funktionsprinzip des Produkts beschreiben (die IEC 62366-1 spricht von Use Specification),
• eine Risikoanalyse bezüglich der Gebrauchstauglichkeit durchführen,
• gefährdungsbezogene Use Scenarios ermitteln,
• die User Interface Specifications erstellen,
• formative und summative Usability Evaluierungen planen, durchführen und auswerten.

Zusammenspiel mit dem Risikomanagement

Der Fokus der IEC 62366-1 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 Iterationen) werden von der IEC 62366-1 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-1 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.

Die IEC 62366-1 hat nun auch die Begriffe formative und summative Evaluierung eingeführt. Die Norm fordert, dass die Usability des Produkts bereits während der Entwicklung anhand von Prototypen formativ evaluiert werden soll. Schließlich soll in einer summativen Evaluierung mit dem finalen UI-Design der objektive Nachweis erbracht werden, dass das UI von den vorgesehenen Anwendern in der vorgesehen Nutzungsumgebung sicher verwendet werden kann.

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 6.1: Bereitstellung von Ressourcen	4.3 Anpassen des Usability-Engineering-Aufwands
Kapitel 6.2: Personelle Ressourcen	4.1.1 *Gebrauchstauglichkeitsorientierter Entwicklungs-Prozess
Kapitel 7.1: Planung der Produktrealisierung	4.3 Anpassen des Usability-Engineering-Aufwands
Kapitel 7.3.2 Entwicklungsplanung	5.5 *Auswählen der gefährdungsbezogenen Use Scenarios für die summative Evaluation 5.7 *Erstellen eines Plans für die User Interface Evaluation
Kapitel 7.3.3 Entwicklungseingaben	5.1 *Erstellen der Use Specification 5.2 *Ermitteln von Merkmalen des User Interface in Bezug auf Sicherheit und mögliche Use Errors 5.3 *Ermitteln bekannter oder vorhersehbarer Gefährdungen und Gefährdungssituationen 5.4 *Ermitteln und Beschreiben gefährdungsbezogener Use Scenarios 5.6 *Erstellen der User Interface Specification
Kapitel 7.3.4 Entwicklungsergebnisse	5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation
Kapitel 7.3.5 Entwicklungsbewertung	5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation
Kapitel 7.3.6 Entwicklungsverifizierung	5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation 5.9 *Durchführen der summativen Evaluation der Usability des User Interface
Kapitel 7.3.7 Entwicklungsvalidierung	5.8 *Durchführen des Designs des User Interface, Implementierung und formative Evaluation 5.9 *Durchführen der summativen Evaluation der Usability des User Interface

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.

#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-1: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

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-1 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 Sie alle Benutzungsszenarien festgelegt und bewertet haben, ob diese sicherheitsbezogen sind.

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

• Seminar: Usability, Requirements & IEC 62366-1
• Forderungen der IEC 62366-1
• Zusammenspiel mit Gesetzen
• Usability Engineering und Risikomanagement
• IEC 62366-1-konforme Dokumentation