Einleitung
Was zeichnet ein gutes Produkt aus? Ich persönlich dachte vor meiner Zeit im SW-Engineering immer, dass sich die Anforderungen an ein System im Wesentlichen auf die Funktionalität desselben konzentrieren würden. Tatsächlich ist es aber die Kombination aus Funktionalität und Gebrauchstauglichkeit, welche die Qualität eines Produktes aus der Sicht eines Anwenders bestimmen. In diesem Artikel soll es deshalb um die viel zu selten betrachtete Komponente Gebrauchstauglichkeit (engl. Usability) eines Systems gehen und darum, wie diese in der Welt der Medizinprodukte sicherzustellen ist.
Der Usability-Begriff
Die Norm DIN EN ISO 9241 Teil 11 definiert den Begriff Usability wie folgt:
Die Gebrauchstauglichkeit ist das Ausmaß, in dem ein System, ein Produkt oder eine Dienstleistung durch bestimmte Benutzer genutzt werden können, um in einem bestimmten Nutzungskontext bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.
Dem Usability-Begriff sind also folgende Komponenten zuzuordnen:
- Benutzer: Der Anwender unseres Produktes
- Werkzeug: Unser zu entwickelndes Produkt
- Kontext: Die Umgebung, in der das Produkt eingesetzt wird
- Aufgabe: Das Ziel, das mit der Benutzung unseres Produktes verfolgt wird
Die Sicherstellung von guter Usability erfolgt durch die Bewertung unseres Produktes nach folgenden Kriterien:
- Effektivität: Erreichen die Nutzer mit der Benutzung unseres Produktes ihr Ziel?
- Effizienz: Erreichen die Nutzer mit der Benutzung unseres Produktes ihr Ziel, ohne dabei unnötige Ressourcen zu verschwenden (Zeit, Energie, Motivation)?
- Zufriedenstellung: Entspricht unser Produkt den Erwartungen der Nutzer?
Usability sollte demnach immer dort eine Rolle spielen, wo Nutzer mit einem Produkt interagieren. Das heißt also: Usability bezieht sich auf Benutzerschnittstellen. Diese können digitaler Natur sein, wie z.B. GUIs und NUIs (Natural User Interfaces, i.d.R. Touchscreens). Aber auch einfachere Benutzerschnittstellen, wie z.B. die Anordnung von Tastern und LEDs auf einem Gerät, sollten hinsichtlich guter Usability entwickelt werden.
Kennenlernen von Nutzungskontext und Aufgabe: Das Contextual Inquiry
Als außenstehender Entwicklungsingenieur ist es nicht immer einfach, das Umfeld, in dem mit einem Produkt gearbeitet wird, sofort zu durchdringen. Abhilfe schafft hier eine Methode mit dem Namen „Contextual Inquiry“, welche das Ziel verfolgt, Nutzer bei der Erledigung einer Aufgabe in ihrem gewohnten Umfeld zu beobachten und zu befragen. Diese Methode folgt einer dynamischen Vorgehensweise und soll eine Anzahl von Ergebnissen erzielen, welche in der Tabelle unten dargestellt sind. Für das bessere Verständnis habe ich als Beispiel die Neuentwicklung eines Ultraschallgerätes ausgewählt, für dessen kontextuelle Analyse ein Orthopäde bzw. eine Orthopädin bei der Arbeit beobachtet werden soll. Das Beispiel ist in seinem Umfang selbstverständlich stark reduziert. Ein echtes Contextual Inquiry würde in diesem Fall vermutlich viele weitere Ergebnisse liefern.
| Ergebnis | Analyseobjekt | Kernattribute | Beispiel |
|---|---|---|---|
| Kennenlernen der Aufgaben und Ziele | Vorgehen und Handlungsstrategien | Tätigkeiten | Bänderrupturen diagnostizieren, Flüssigkeitseinlagerungen erkennen |
| Häufigkeiten | Durchschnittlich 7 Benutzungen am Tag | ||
| Dauer | 3-7 min | ||
| Intensität | Gründliche Untersuchung bedingt intensive Nutzung | ||
| Spezialfälle | Keine erkannt | ||
| Kommunikation und Rollenteilung | Verantwortlichkeiten | Feststellen eines Patientenbefunds, Unterweisung der Assistenz, Ablauf der Untersuchung | |
| Kommunikationsinhalte | Anweisungen an Assistenz, Mitteilung des Befunds | ||
| Kommunikationsmittel | Sprachlich, schriftlich | ||
| Kommunikationszweck | Praxisorganisation, Festlegung weiterer Schritte | ||
| Hintergrundinformationen | Domänenwissen | Begrifflichkeiten: Erstellung eines Glossars | |
| Kennenlernen des Kontextes | Physisch | Räumlichkeiten | Untersuchungsraum |
| Beleuchtung | Normale bis helle Zimmerbeleuchtung | ||
| Temperatur | Zimmertemperatur (ca. 21°C) | ||
| Einflüsse durch Schmutz oder andere Substanzen | Ultraschallgel, ggf. Blut | ||
| Sozial, kulturell | Verhaltensregeln | Professionelles Auftreten, Benutzung verständlicher Sprache | |
| Andere Personen | Sprechstundenassistenz, Patient | ||
| Werte | Wohlergehen des Patienten | ||
| Organisation | Rollenteilung | Orthopäde bzw. Orthopädin: leitende Person, primärer Benutzer bzw. primäre Benutzerin
Sprechstundenassistenz ist: sekundärer Benutzer bzw. sekundäre Benutzerin |
|
| Unterbrechungen | Durch Notfall |
Diese Tabelle soll als Anhaltspunkt für das Contextual Inquiry dienen und bietet demnach keine Garantie auf Vollständigkeit. Beim Contextual Inquiry existieren lediglich Richtlinien, von denen je nach Situation abgewichen werden kann bzw. muss.
Entwickeln von Essential Use Cases
Nachdem wir im Zuge des Contextual Inquiry nun unsere Aufgabe und deren Kontext kennengelernt haben, wollen wir daraus Anwendungsfälle für das zu entwickelnde Werkzeug ableiten. Davor ist allerdings zu erwähnen, dass ich in diesem Artikel aus Gründen der Übersichtlichkeit einen wesentlichen Schritt überspringe: die Identifikation von Nutzergruppen und das Ablegen dieser in sogenannten Personas, welche fiktive Personen mit echten Eigenschaften aus ihrer respektiven Nutzergruppe darstellen. Einen vertiefenden Einblick dazu bietet der Artikel „Personas“ auf der Seite für Usability Richtlinien des U.S. General Services Admission for Technology Transformation Services.
Nun aber zurück zu den Use Cases: Eine effektive Methode, Use Cases für die Entwicklung von innovativen Produkten aufzuschreiben, ist die Formulierung von sogenannten „Essential Use Cases“. Im Vergleich zu den Conventional Use Cases sind diese kompakter und beschreiben die Systemverantwortlichkeiten aus der Sicht eines Benutzers. Es wird deutlich, dass die Essential Use Cases dem Bereich der menschenzentrierten Softwareentwicklung entstammen.
Den Unterschied zwischen Essential Use Case und Conventional Use Case soll der folgende Vergleich deutlich machen. Das gewählte Beispiel ist der Vorgang „Patientendaten einsehen“ bei einem Patientenverwaltungssystem.
| Use Case ID: UC101 | |||
|---|---|---|---|
| Use Case Name: „Patientendaten einsehen“ | |||
| Involved Personas: Kathrin Musterfrau | |||
| Conventional Use Case | Essential Use Case | ||
| User Action | System Response | User Intention | System Responsibility |
| Open application | Request login credentials | To have secure access | Verify identity |
| Enter Username and Password | To view patient data | Offer search possibilities, Show search results |
|
| Press Enter Key | Verify credentials, Show menu |
To logout | Offer logout possibilities |
| Select „Search Patient Database“ | Request patient name and DOB | ||
| Enter patient surname and DOB | |||
| Press Enter Key | Parse database, Show results |
||
| Press Logout Button | Logout, Show logout message |
||
Zusammenfassend kann man also sagen, dass Essential Use Cases einerseits kompakter sind und andererseits den Freiheitsgrad bei der Ableitung der Requirements erhöhen, was die Innovation im Entwicklungsprozess beflügelt. Die Essential Use Cases können z.B. in Templates erfasst und in einem sogenannten Use Case Diagramm festgehalten werden. Was Use Case Diagramme sind und wie man sie modelliert, kann in unserem Artikel über Anwendungsfalldiagramme nachgelesen werden.
Nutzungsanforderungen (Usability Requirements)
Im nächsten Schritt des Prozesses werden wir uns den Anforderungen an unsere Nutzerschnittstelle widmen, welche die Grundlage für einen Prototypen bilden. Die Nutzungsanforderungen leiten sich aus den Essential Use Cases ab, die wir zuvor, z.B. mithilfe von Templates, erfasst und niedergeschrieben haben. Beim Erstellen von Requirements gilt es laut dem Leitfaden für Usability des Deutschen Akkreditierungsdienst (DAkks) die Einhaltung der drei Gütekriterien zu beachten:
- Objektivität: Eine Nutzungsanforderung muss so formuliert sein, dass Sie frei von Einflüssen der Stakeholder ist und einem tatsächlichen Erfordernis entspricht, das aus der Analyse des Nutzungskontextes hervorgegangen ist.
- Widerspruchsfreiheit: Eine Nutzungsanforderung sollte anderen Nutzungsanforderungen nicht widersprechen. Sollte das trotzdem vorkommen, so ist dies auf die Existenz einer weiteren Benutzergruppe oder eines weiteren Nutzungskontextes zurückzuführen, für welche eigenständige Ist-Analysen (Kontext- und Nutzeranalysen) durchzuführen sind.
- Validität: Eine Nutzungsanforderung muss auf Daten beruhen, die durch Personen, die in repräsentativen Positionen tätig sind, bestätigt wurden und ggf. korrigiert worden
Für die Formulierung von Nutzungsanforderungen wird an dieser Stelle folgende Syntax vorgeschlagen: „Ein Nutzer muss am System <Tätigkeit> können.“
Für <Tätigkeit> kann ein Prädikat zusammen mit einem Objekt eingesetzt werden.
Einige Beispiele, welche auf den Use Case Patientenverwaltung zurückgreifen, soll die Formulierung veranschaulichen:
- „Ein Nutzer muss am System seine Identität bestätigen können“
- „Ein Nutzer muss am System Patientendaten anzeigen können“
- „Ein Nutzer muss sich vom System ausloggen können“
Prototyping
Im Prozessschritt Prototyping geht es um das Umsetzen der Nutzungsanforderungen im Zuge eines visuellen Gestaltungsprozesses, an dessen Ende ein testbarer Prototyp steht. Die Ausgestaltung kann toolbasiert erfolgen, wobei hier, je nach Oberflächentyp, verschiedene Tools zur Verfügung stehen. Abhängig von der erforderten Reife des Prototypen können aber auch schon eine einfache Skizze, welche mithilfe der sogenannten Wizard-of-Oz-Technik zum Leben erweckt wird, oder ein sogenannter Wireframe einen testbaren Prototypen bereitstellen. Die Vorteile dieser Arten von Prototyp liegen auf der Hand: Sie sind einerseits sehr günstig, andererseits sind sie meist innerhalb kürzester Zeit verfügbar und können damit als Diskussionsgrundlage für Akutsituationen genutzt werden. Für Benutzerschnittstellen, die sich nicht auf Bildschirmen, sondern beispielsweise auf Bedienpanels an einem Gerät befinden, muss in der Regel leider mehr Aufwand betrieben werden: Testbare Prototypen sind oft nur Hardware Mockups, welche unter Einbezug von Fertigungsverfahren entwickelt werden müssen (z.B. mithilfe von 3D-Druck). Nichtsdestotrotz habe ich aber auch schon von Firmen gehört, welche sich hinsichtlich der Hardware Mock-Ups z.B. mit Lego-Bausteinen oder Prototypen aus Pappe beholfen haben. Wie immer in der Entwicklungsarbeit, ist auch hier Kreativität gefragt.
Ein Wireframe für eine Sonografie GUI (sehr vereinfacht)
Usability Evaluation
Das Ziel einer Usability Evaluation ist das Testen eines Prototypens hinsichtlich der Usabilitymetriken Effektivität, Effizienz und Zufriedenheit. Hierzu bieten sich eine Palette an Verfahren an. Ich möchte an dieser Stelle speziell auf eine besondere nutzerorientierte Beobachtungsmethode eingehen, welche sich, wie der Name schon sagt, auf die Beobachtung von Nutzerinteraktionen mit dem Werkzeugprototypen stützt. Die genannte Methode wird als Usability Walkthrough bezeichnet.
Die Beobachtung findet dabei im echten Nutzungskontext statt, also beispielsweise in einer Praxis oder Klinik, in welcher der Teilnehmer, also in der Regel ein Arzt, arbeitet. Einem Teilnehmer, welcher zu einer unserer identifizierten Nutzergruppen gehören sollte, werden während der Beobachtung Aufgaben gestellt, die dieser ohne zusätzliche Hilfestellung durch den Evaluator zu lösen hat. Die Aufgaben sind dabei möglichst realitätsnah zu stellen. Eine passende Fragestellung wäre beispielsweise im Falle des Ultraschallgeräts: „Erstellen Sie mit dem Ultraschallgerät bitte ein Bild des rechten Außenbandes des Patienten“. Wichtig ist vor Allem, dass der Teilnehmer im Zuge der Aufgabenlösung laut denkt, sodass der Evaluator seine Gedankenschritte nachvollziehen und gegebenenfalls notieren kann. In manchen Fällen ist es sinnvoll, den Test in irgendeiner Form aufzuzeichnen, z.B. mit einem Video. Dabei sollten datenschutzrechtliche Aspekte aber im Vorhinein in jedem Falle abgeklärt werden. Um einen repräsentativen Eindruck der Usability eines Produktes zu bekommen, sollten so viele dieser Tests mit unterschiedlichen Teilnehmern wie möglich durchgeführt werden. Auffälligkeiten, sogenannte Usability Issues, sollten in die Entwicklung zurückgeleitet werden, um gegebenenfalls Anforderungen anzupassen oder neue zu verfassen.
Weitere, bei Medizinprodukten in Frage kommend, nutzerorientierte Methoden zur Evaluation von Usability:
- Hallway Test
- Pluralistic Walkthrough
- Formaler Usabilitytest
- Fragebogen
Fazit
Usability ist für die Produktentwicklung in der Medizintechnik ein sehr wichtiges Thema, da sich schlechte Usability in der vom Nutzer wahrgenommenen Qualität des Produktes bemerkbar macht. Usability Engineering sollte als zyklischer Prozess gesehen werden, der im Verlauf einer Neuentwicklung oder des Redesigns eines Produktes mehrfach durchlaufen wird. Usability Engineering muss möglichst mit dem Kick-off eines Projektes beginnen und sollte nicht hinten angestellt werden. Wichtig ist dafür der Aspekt des Prototypings, der dem noch nicht komplett ausgereiften Produkt eine Evaluation hinsichtlich seiner Usability ermöglicht.
