Hurra, wir machen Usability und User Experience (UX)! – Aber bitte ohne Nutzer!

11. Mai 2015

Nur mit einem nutzerzentriertem Vorgehen entstehen gebrauchstaugliche Produkte die zudem eine gute User Experience (UX) aufweisen. Diese Tatsache ist in der UX Community unumstritten. Bei der Kommunikation mit (potenziellen) Auftraggebern wird darum dieser Ansatz auch thematisiert. In der praktischen Projektdurchführung stellt sich dann aber meistens schnell heraus, dass die anfängliche Begeisterung für ein nutzerzentriertes Vorgehen nicht wirklich ernst gemeint war. Die Bedenken der Auftraggeber hinsichtlich der Einbeziehung von repräsentativen Vertretern aus der Nutzergruppe sind vielfältig.

„Die interne Perspektive ist ausreichend“

Häufig steht der Auftraggeber auf dem Standpunkt, dass die Sichtweise des Projektteams umfassend genug ist und es darum genügt, mehrere in ihren jeweiligen Bereichen kompetente Personen zusammenzubringen. In Design-Workshops werden dann deren Perspektiven diskutiert und und basierend darauf ein User Interface entworfen. Schwerer als die Tatsache, dass Gruppen grundsätzlich suboptimale Entscheidungen treffen, wiegt hier folgendes: Niemand, der kein potenzieller Nutzer eines (zukünftigen) Produkts ist, kann die Perspektive eines solchen Nutzers einnehmen. Denn das aus Nutzersicht erforderliche Wissen über die Aufgabe (die das Produkt unterstützen soll) und das physische und soziale Umfeld fehlt. Der Versuch in die Rolle des Nutzers zu schlüpfen kann daher niemals ein Ersatz für die Einbeziehung echter Repräsentanten aus der Nutzergruppe sein.

Die Aufgabe des Usability-Engineers ist hier, Bewusstsein dafür schaffen, dass Aussagen über Erforderniss und Verhaltensweisen von Nutzern aus dem Projektteam immer nur Annahmen sind, deren Stichhaltigkeit noch zu prüfen ist. Solche Annahmen sollten entsprechend dokumentiert werden – vor allem dann, wenn auf deren Basis grundlegende Designentscheidungen getroffen werden. Neben der Annahme und der korrespondierenden Designentscheidung bietet es sich hier an, namentlich zu dokumentieren, wer aus dem Projektteam die Annahme für richtig hält und damit implizit für die Korrektheit bürgt. Diese Taktik der Verantwortungsübernahme für kritische Annahmen erhöht die Hemmschwelle, Vermutungen des Projektteams als korrekt zu akzeptieren und die Verantwortung hierfür diffus zu verteilen. Auf diesem Wege stiegt die Bereitschaft zur Einbeziehung echter Nutzer als valide Kontrollinstanz, weil so die Verantwortung auf diese übergeht.

„Projektergebnisse sind geheim“

Auch dann, wenn die Einbeziehung von Nutzern prinzipiell als nützlich verstanden wurde, werden diese trotzdem vom Auftraggeber oft nicht sofort mit in das Projekt einbezogen. Meistens werden aus Überlegungen zur Projekt-Geheimhaltung „Außenstehende“ nicht in die Projektarbeit involviert. So sollen zum Beispiel keine Prototypen im Zuge von Usability Tests nach außen dringen, um zu verhindern, dass Informationen darüber zum Wettbewerb gelangen.

Hier bietet es sich an, zunächst interne Usability Tests mit Mitarbeitern durchzuführen, die nicht im Projektteam sind. Dabei werden zwar keine echten Nutzer des zu entwickelnden Produkts einbezogen, die Sicht des Projektteams durch die Einbeziehung Außenstehender wird aber soweit erweitert, dass Designprobleme schon früh auffallen. Solche Usability-Tests verdeutlichen zudem auch die Notwendigkeit und Ergiebigkeit einer Design-Validierung und decken Schwächen bei Erkenntnissen auf, die ausschliesslich von Organisationsangehörigen eingebracht wurden.
Ist der Auftraggeber hinreichend sensibilisiert, kann der Blick über die Organisation des Auftraggebers hinaus erweitert werden und z.B. ausgewählte Pilotkunden mit in ein Projekt einzubezogen werden, die formell auf Geheimhaltung verpflichtet werden. Kunden wirken gern an solchen vertraulichen Evaluationen mit, weil sie sich persönlich Vorteile für ihre eigene Organisation aus dem betreffenden Projekt erhoffen: zum Beispiel, dass Feedback zu Anforderungen in zukünftigen User Interfaces berücksichtigt wird. Der Usability-Engineer sollte dem Auftraggeber darum vermitteln, dass die Einbeziehung von Kunden in derartige Evaluationen auch ein wertvolles Instrument zum Marketing und zur Kundenbindung darstellen kann, wenn es angemessen kommuniziert wird.

„Wir haben Zeit-Mangel“

Wenn der Auftraggeber den Eindruck gewinnt, dass die entsprechenden Maßnahmen mit hohem (Zeit-)Aufwand verbunden sind und daher die Effizienz der Projektdurchführung gefährden, kann das dazu führen, dass eine Einbeziehung von Nutzern nur punktuell oder gar nicht erfolgt.

Aufgabe des Usability-Engineers ist hier durch praktisches Tun nachzuweisen, dass Nutzerzentrierung nicht zu einer signifikanten Verlangsamung eines Projekts führt. Vor allem in den Anfangsphasen eines Projekts werden oft Aktivitäten wie Besuche beim Anwender durchgeführt, die scheinbar die Projekteffizienz mindern, weil sie Zeit kosten und andere Aktivitäten im Projektablauf zeitlich nach hinten verlagern. Nutzerzentriertes Vorgehen ist aber – verglichen mit nicht nutzerzentrierter Produktentwicklung – deutlich zielgerichteter und vermeidet nicht erforderliche Arbeitsergebnisse. Diese Erfahrung kann ein Auftraggeber jedoch nur in einem nutzerzentrierten Projekten machen.
Der Usability-Engineer sollte daher bei allen nutzerzentrierten Maßnahmen vor allem auf (Zeit-)Effizienz achten. So können z.B. bei Anwenderbesuchen auch Mitglieder des Projektteams auf Seiten des Auftraggebers beteiligt sein, und so späteren Aufwand für Dokumentation und Kommunikation reduzieren. Bei Usability-Tests in frühen Phasen mit schnell erstellbaren Papierprototypen sollten Mitglieder des Projektteams auf Auftraggeberseite involviert werden (zum Beispiel als Beobachter), um die Informationenaus den Tests unmittelbar zu kommunizieren und deren Mehrwert unmittelbar erlebbar zu machen.

„Es geht nicht nur um den Nutzer“

Oft gibt es Befürchtungen des Auftraggebers, dass die Ausrichtung eines Projekts auf die Erfordernisse der Nutzer dazu führen, relevante Geschäftsziele zu vernachlässigen.

Der Usability-Engineer muss hier klar machen, dass die Erfordernisse der Nutzer eine wesentliche Grundlage für die Gestaltung von Designlösungen sind, dass ihm jedoch auch bewusst ist, dass der Auftraggeber Geschäftsziele verfolgt, die zu erreichen sind. Zu Beginn eines Projekts sollte darum mit dem Auftraggeber besprochen werden, welche Geschäftsziele für diesen relevant sind und wie diese mit den Zielen der Nutzer in Beziehung stehen. Denn die Geschäftsziele werden sicher nicht mit einem User Interface erreicht, dass die Nutzer nicht zufriedenstellt. Gelingt es dem Usability-Engineer, dem Auftraggeber zu zeigen, wie die Beschäftigung mit Nutzern und deren Erfordernissen den Geschäftszielen zugute kommt – und dass die Vernachlässigung der Nutzerperspektive die Geschäftsziele gefährden kann – so sollte die Berücksichtigung der Nutzer im Projekt kein Problem mehr darstellen.

Diesen Beitrag bookmarken bei:
Bookmark bei: Yigg Bookmark bei: Webnews Bookmark bei: Technorati Bookmark bei: Mr. Wong Bookmark bei: Linkarena Bookmark bei: Del.icio.us Bookmark bei: Google Bookmark bei: Favoriten Bookmark bei: Facebook

Autor des Beitrags