User Centered Design: Weshalb Sie damit vorsichtig sein müssen

Sonntag 8. April 2018

Jeder wird zustimmen, dass es gut ist, die künftigen Anwender von Anfang an, in die Entwicklung mit einzubeziehen. „User Centered Design“ nennt man das oft. Dabei kann dieser User Centered Design Ansatz sogar zu fatalen Fehlentwicklungen führen.

Ein gutes Produkt ist eines, mit dem die spezifizierten Nutzer in dem spezifizierten Nutzungskontext ihre spezifizierten Nutzungsziele erreichen können – effektiv und effizient. Das setzt voraus, dass das Produkt die Nutzungsanforderungen erfüllt.

Probleme mit User Centered Design – nicht nur bei Medizinprodukten

Wenn Sie aber mit Nutzern im Sinne eine User Centered Designs über die Produktgestaltung sprechen, diskutieren Sie gerade nicht Nutzungsanforderungen sondern eine Systemspezifikation (Systemanforderungen). Ob dieses System oder Produkt die nicht explizit bekannten Nutzungsanforderungen erfüllt, bekommen Sie durch ein User Centered Design nicht heraus.

Das ist auch wenig überraschend, denn Nutzer sind Experten für den Nutzungskontext, d.h. für die Aufgaben, den darin vorkommenden Problemen, Zielen, Voraussetzungen Rollen usw. Nutzer sind aber keine Usabilty oder Requirements Experten. Sie verfügen nicht über die Kompetenz, gebrauchstaugliche Nutzungsschnittstellen (UI) zu entwerfen.

Beachten Sie, dass die ISO 13485 ebenso wie die FDA verlangen, dass Sie sowohl Stakeholder-Anforderungen (wie z.B. Nutzungsanforderungen) als auch System-Anforderungen dokumentieren müssen.

Lösung: Usage Centered Design statt User Centered Design

Das bedeutet aber nicht, dass Sie keine Nutzer einbeziehen sollten. Im Gegenteil: Nur durch die Nutzer können Sie im Rahmen einer Kontextanalyse die Nutzungsanforderungen erheben. Sie sollten also statt eines User Centered Designs eher eine Uses Centered Analysis anstreben. Sie können es aus „Usage Centered Design“ nennen.

Rollenverteilung beim User Centered Design

Die Rollenverteilung sollte also so aussehen:

  1. Requirements-Engineers: Führen mit Usern Kontextanalysen durch und identifizieren Nutzungsanforderungen und beschreiben Kernaufgaben
  2. Usability Engineers wie z.B. Interaktionsdesigner: Sie entwerfen aus Kernaufgaben und passend zu Nutzungsanforderungen Nutzungsszenarien und entwerfen die UI bzw. UI Prototypen.
  3. User: Sind Kontext bzw. Usage Experten und stehen den Requirements Engineers bei Kontextanalyse zur Verfügung. Sie sind auch die Personen, die die Produkte bzw. Prototypen validieren.

User Centered Design hört sich als Marketing-Schlagwort gut an. Es zeugt aber auch von einem nicht mehr ganz zeitgemäßen vorgehen.

Mehr erfahren im Seminar „Usability, Requirements & IEC 62366

Im Seminar „Usability, Requirements & IEC 62366“ mit Thomas Geis lernen Sie, wie Sie schnell, ohne unnötige Iterationen und normenkonform

  1. Eine Kontextanalyse durchführen
  2. Nutzungsanforderungen identifizieren
  3. Kernaufgaben beschreiben
  4. Nutzungsszenarien entwerfen
  5. Nutzungsschnittstellen (UIs) entwerfen, die Ihr Produkt wirklich gebrauchstauglich und damit sicher und im Markt erfolgreich machen.

Sie können Sie zu diesem Seminar hier anmelden.

War dieser Artikel hilfreich? Bitte bewerten Sie:
1 Stern2 Sterne3 Sterne4 Sterne5 Sterne

Autor des Beitrags " User Centered Design: Weshalb Sie damit vorsichtig sein müssen

Johner Institut GmbH

Logo Johner Institut klein

Bewertung 0 von 5 bei 0 Bewertungen


Kategorien: Software & IEC 62304, Usability & IEC 62366
Tags:

Ein Kommentar über “User Centered Design: Weshalb Sie damit vorsichtig sein müssen”

  1. Hagen Rehbein schrieb:

    http://www.youtube.com/watch?v=BKorP55Aqvg

    das Video ist vielleicht auch ein echt hübsches Beispiel dazu …

Kommentar schreiben