Usability Engineering nach DIN EN ISO 9241-11

Seit der Einführung von Smartphones mit Touch Bedienung hat sich die Art und Weise wie Menschen mit Maschinen interagieren auffallend verändert. Der Trend geht hinzu immer größer werdenden Touchscreens und das Wegfallen von Hardware Tasten. Auch in der Medizintechnik deutet sich allmählich ein solcher Trend an. Die Bedienung soll dabei effizient, effektiv und zufriedenstellend für den Benutzer sein. In diesem Artikel möchte ich Ihnen zeigen, wie die DIN EN ISO 9241-11 den Begriff „Usability“ definiert und warum die Disziplin des Usability Engineering so wichtig für heutige Produkte ist.

Gebrauchstauglichkeit

Die DIN EN ISO 9241-11 mit dem Titel „Anforderungen an die Gebrauchstauglichkeit – Leitsätze“ definiert den Begriff der Gebrauchstauglichkeit (Usability) so:

Usability ist das Ausmaß, in dem ein Produkt durch bestimmte Benutzer in einem bestimmten Nutzungskontext genutzt werden kann, um bestimmte Ziele effektiv, effizient und zufriedenstellend zu erreichen.

Um den genauen Inhalt dieser Definition verstehen zu können, bedarf es einiger weiterer Erklärungen. Entwickeln wir eine Smartphone-App, stellt diese unser Produkt dar, für die die Gebrauchstauglichkeit spezifiziert und evaluiert wird. Benutzer sind diejenigen Personen, die das Produkt auf Ihrem Smartphone installieren und nutzen wollen, und zwar effektiv, effizient und zufriedenstellend. Effektivität bedeutet, wie vollständig das Ergebnis im Verhältnis zum gewünschten Ziel erreicht wird. Effizienz hingegen setzt das Ergebnis ins Verhältnis zum eingesetzten Aufwand. Zufriedenstellung ist in der Norm definiert als: „Freiheit von Beeinträchtigung und positive Einstellung gegenüber der Nutzung des Produkts.“ Der Nutzungskontext setzt sich aus den Punkten Benutzern, Arbeitsaufgaben, Arbeitsmitteln und sozialen und physischen Umgebungen zusammen. All diese Begriffe lassen sich zusammenhängend in einer Grafik darstellen:

Gebrauchstauglichkeit nach DIN EN ISO 9241-11

Gebrauchstauglichkeit nach DIN EN ISO 9241-11

Für was benötigt man den Nutzungskontext?

Wie oben bereits beschrieben, besteht der Nutzungskontext aus Benutzern, Arbeitsaufgaben, Arbeitsmitteln und der sozialen und physischen Umgebung. Erhoben wird er, um die Nutzungsanforderungen einfacher herausfinden zu können. Anhand des Nutzungskontextes werden im späteren auch die Gestaltungslösungen erarbeitet. Der Nutzungskontext könnte für einen automatisierten externen Defibrillator (AED) wie folgt aussehen:

  1. Benutzer eines automatisierten externen Defibrillators:
    Niemand wäre gern in der Situation, einen Defibrillator anwenden zu müssen. Da Herzkammerflimmern plötzlich auftritt, kann aber jeder in die Lage kommen. Hier kann zwischen zwei Benutzergruppen unterschieden werden:
    – Ein Laie, der womöglich noch nie Kontakt mit einem Defibrillator hatte
    – Eine medizinisch ausgebildete Person (Arzt, Krankenschwester, usw.)
  2. Arbeitsaufgabe:
    Den Herzschlag eines Patienten/Geschädigten in den geregelten Zustand zurückführen.
  3. Arbeitsmittel:
    Hierzu zählt nicht der Defibrillator selbst, sondern nur Mittel die zusätzlich benötigt werden und die Produktgestaltung mit beeinflussen.
    – Elektroden
    – Erste-Hilfe-Set
    – Handy
  4. Physisches Umfeld:
    Der Ort, wo der Defibrillator eingesetzt wird. AEDs befindet sich meistens in öffentlichen Einrichtungen.

Wie erhebt man die Daten für den Nutzungskontext?

In der Analysephase des Usability Engineering gibt es verschiedene Methoden, um die Daten für den Nutzungskontext zu erheben. Die bekanntesten sind:

  • Interview
    – mündliche Befragung von Benutzern
    – Einzelinterview oder Gruppeninterview (Fokusgruppe) möglich
    – Ablauf muss gut geplant sein
  • Fragebogen
    – schriftliche Befragung der Benutzer
    – kein „Eingriff“ in Ablauf möglich
    – Benutzer brauchen gut strukturierten Leitfaden
    – auf Fragestellung achten
  • Beobachtung
    – direkt vor Ort oder per Videoaufzeichnung
    – findet im Arbeitsumfeld statt
    – stilles Begleiten und Notieren von Beobachtungen
  • Tagebuchstudie
    – Benutzer dokumentieren selbst
    – Aufgaben können vorgegeben werden
    – online oder Papier
  • Kontextuelle Analyse
    – Beobachten und Befragen von Personen vor Ort
    – Vorbereitung notwendig

Alle Methoden haben gemeinsam, dass die Erhebung der Daten vor Ort stattfindet, sei es durch Sie oder den Benutzer selbst. Detaillierte Informationen über den Ort, die Zielgruppe und die Aufgaben können Sie nur dort erhalten, wo das Produkt auch wirklich eingesetzt werden soll! Wie Sie die Daten erheben wollen, liegt in Ihrem Ermessen. Wenn Sie mehr über die genannten Methoden erfahren möchten, können Sie uns gern kontaktieren.

Wie dokumentiert man die gewonnenen Daten?

Die Analyse ist abgeschlossen und die Daten müssen nun dokumentiert werden. Auch hier gibt es verschiedene Möglichkeiten. Empfehlenswert finde ich, Personae zu erstellen. Personae sind imaginäre prototypische Benutzer des Systems. Hier filtert man aus den gewonnenen Daten zwei Hauptbenutzer und optional mehrere Nebenbenutzer heraus. Auf die Interessen der Hauptbenutzer sollte besonders großer Wert gelegt werden, wenn man die Zielgruppe nicht verfehlen möchte. Schreiben Sie sich Alter, möglicher Name, Interessen, Vorkenntnisse des Nutzers auf und visualisieren Sie diese. Sind Sie mit allen Personae zufrieden, können Sie diese im Büro während des Entwicklungsprozesses aufhängen. So vergessen Sie nie, an wen das Gerät gerichtet ist. Hier ist ein Beispiel, wie Personae aussehen könnten:

Personae in der Medizintechnik am Beispiel der Defibrillation

Personae für die Medizintechnik

Nachdem alle Personae aufgestellt sind, können Szenarien erstellt werden. Diese bilden eine Erweiterung zu Personae. Mithilfe von Szenarien können die Abläufe beschrieben werden, die eine Person an einem Arbeitstag ausübt. Szenarien können unterschiedlich stark ausgearbeitet werden. Auf der einen Seite reichen kurze Listen völlig aus, auf der anderen können detaillierte Ausarbeitungen sinnvoll sein.

Kontaktieren Sie uns!

Autor

  • Daniel Saffer

    Daniel Saffer war als Firmwareentwickler für die MEDtech Ingenieur GmbH tätig. Zu seinen Aufgabengebieten gehörte die Entwicklung der Embedded Software eines Nervenstimulationsgeräts, sowie eines Systems zur drahtlosen Steuerung eines C-Bogens. Eine weitere Aufgabe war die Erstellung von Risikobetrachtungen und Assessments aus Cybersecurity-Sicht für verschiedene Medizinprodukte.

Auch interessant:

Live from the Lab – Power for IoT

Kennst du dich mit Batterien und Akkus aus? Der Livestream „Keysight: Live from the Lab“ gibt eine gute Einführung in die Thematik. In dieser Livestream-Reihe, die von Keysight gehostet wird, werden bei jeder Veranstaltung unterschiedliche elektronische Vorgänge oder Begebenheiten beleuchtet. Bei den einzelnen Vorträgen wird versucht elektrotechnisches Wissen einfach und…
Getagged mit: , , , , , , , , , ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert