Der Kunde ist König – Wovon?

Im Folgenden möchte ich kurz darstellen, warum User Driven Design den Endanwender über Gebühr in Verantwortung nimmt und das User Centered Design stattdessen die Kernkomptenz des Anwenders produktiv nutzt.

Der Kunde ist König. Damit möchte man immer wieder betonen, dass man das, was man macht, für die macht, die dafür bezahlen sollen. Aber was meint man damit eigentlich? Da gibt es die einen, die sagen, dass man König ist, wenn man ein Bier dieses Namens trinkt. Dann ist man König: In jedem Arm eine schöne Frau.

Nun, das hat mit Usability nicht viel zu tun, eher mit Marketing – sollte erwähnt sein und jetzt vergessen werden.

User Driven Design versus User Centered Design

Wenden wir uns den Usability-Aspekten dieses Satzes zu. Zwei Möglichkeiten:

  • User Driven Design: Der König herrscht über die Software.
  • User Centered Design: Wir tun alles, um dem König zu dienen.

Wie wir sehen liegt der Unterschied in diesen Wörtern „Driven“ oder „Centered“. Dahinter verbirgt sich aber ein sehr großer qualitativer Unterschied.

Beim User Driven Design hat der Kunde, will sagen der Endanwender, nicht nur sehr großen Einfluss auf die Anforderungen sondern auch auf deren designerische Umsetzung. Im Extremfall entscheidet er sogar über die Form der Umsetzung. Er übernimmt damit auch die Verantwortung für die Implementierung.

Beim User Centered Design stehen im Gegensatz dazu die Belange des Nutzers im Vorder-grund. Nicht seine Designentscheidungen sondern seine fachlichen Anforderungen und kognitiven Rahmenbedingungen. Das ist nicht selbstverständlich: Es gibt genug Projekte, in denen rein wirtschaftliche Aspekte priorisiert werden. Siehe hierzu aber auch meinen Artikel ROI durch Usability. Das User Centered Design bindet den Anwender in die Anforderungserhebung ein. Analytiker beurteilen dann die Anforderungen hinsichtlich Konsistenz und Mach-barkeit. Das Design nimmt die Anforderungen auf und entwickelt ein Konzept, wie man diese Anforderungen erfüllen kann. Das wird anschließend mit dem Kunden abgesprochen und nach erforderlichenfalls mehreren Iterationen abgenommen.

Auf den Punkt gebracht liegt der Unterschied darin, dass im Fall des User Driven Design der Kunde nicht nur bestimmt, was entwickelt werden soll, sondern auch wie es aussehen soll. Das betrachte ich als ein schwer zu kalkulierendes Risiko, da der Kunde sich aus dem Bereich seiner Kernkompetenz heraus bewegt und auf einmal Designverantwortung übernimmt. Nichts gegen Überflieger. Solche universal gebildeten Personen gibt es. Dennoch ist mir in den Projekten der letzten zehn Jahre noch nicht ein Fachexperte begegnet, der sich seine Brötchen auch als Analytiker und / oder Designer hätte verdienen können. Das überrascht mich auch nicht: Polizeipräsident + Geschäftsprozessanalytiker + User Interaction Designer ist einfach zu viel verlangt.

Der Nutzer als Lückenbüßer

Häufig ist der Nutzer gar nicht schuld an der Situation. Ganz im Gegensatz ist es oft der Auftragsnehmer, der dem Kunden bzw. den von ihm abgestellten Anwendern die Verantwortung aufbürdet. Wenn es nämlich hinterher Probleme gibt, weil die Software nicht den gewünschten Erfolg bringt, kann der Auftragnehmer die Schuld von sich weisen. Weiterhin wird der Kunde oft zur Entscheidung gedrungen, wenn die Designer keine Ahnung haben, wie sie ein Problem lösen sollen. Unter dem Deckmäntelchen des User Centered Design wird die Planlosigkeit der Designer kaschiert: „Die Anwender sollen sagen, wie sie es gerne hätten. Schließlich kennen die ja ihre Arbeit am besten.“ So wird aus dem User Centered Design schleichend ein User Driven Design. Das ist ein perfides Vorgehen. Wenn man sich unter mehreren Mög-lichkeiten auf keine einigen kann, sollte man stattdessen Usability Tests durchführen, um die beste Variante zu identifizieren.

Ein weiterer Grund, aus dem heraus ich das User Driven Design sehr kritisch betrachte, ist die Tatsache, dass sich Anwender bei der Beschreibung neuer Geschäftsprozesse und Systeme sehr eng an dem Bestehenden orientieren. So kann aber keine Innovation erreicht werden. In einem Projekt war die Situation derart unglücklich, dass die von Endanwendern geschriebenen Use Cases mehr oder minder einfach die aktuell eingesetzte Software beschrieb. Man kann sich vorstellen, dass diese Use Cases wenig zielführend waren. Es war nicht umsonst aber vergebens und für alle Beteiligten sehr frustrierend. Als man die Use Cases Analytikern übergab, besserte sich die Lage schlagartig. Das heißt nicht, dass die Anwender ausgebootet wurden. Nein, sie konnten sich nunmehr auf ihre Aufgabe als beratende Fachexperten konzentrieren. Nun hatte jeder seine Rolle, die er beherrscht, was dem Projekt sehr zugute kam.

Fazit

Die Expertise von Endanwendern ist in der Software-Konzeption unverzichtbar. Das User Centered Design bindet sie entscheidend in die Anforderungserhebung und den Abnahmeprozess ein. Die Übertragung von Designverantwortung auf Endanwender wie es beim User Driven Design der Fall ist, ist aus den beschriebenen Gründen aber durchaus skeptisch zu betrachten. Darüber hinaus tut man den Anwendern damit auch keinen Gefallen.

Um noch mal auf den König zurückzukommen:
Mit User Centered Design ist man König: In jedem Arm einen zufriedenen User.