Requirements Elicitation – der unterschätzte erste Schritt

Als UX Agentur werden wir oft ins Boot geholt, wenn die Entwicklung eines neuen Produktes oder der Relaunch einer Seite schon fast abgeschlossen ist. Unser Auftrag ist es dann zu testen, ob die neue Seite, die neue Funktion auch gut beim Kunden ankommt und alles gut bedienbar ist. Stimmen von Probanden wie „Das würde ich nie benutzen!“ oder „Das brauch ich nicht“, will an dieser Stelle der Entwicklung dann natürlich niemand mehr hören. Im schlimmsten Fall hat man am Kunden vorbeientwickelt und stellt dies nun kurz vor dem Relaunch oder der Veröffentlichung des neuen Produktes fest. In den Beispielen wurde der erste Schritt jeder guten Entwicklung vernachlässigt: die Anforderungen (Requirements) der Nutzer zu ermitteln.

Die hohe Kunst der Generierung von Nutzeranforderungen kann man dabei in zwei Bereiche untergliedern: erstens das Erheben der Nutzerbedürfnisse und –wünsche an das Produkt und zweitens das Ableiten der korrekten Spezifikationen für das Produkt. Dieser erste Bereich – auch als Requirements Elicitation bezeichnet – umfasst verschiedene Methoden zur Datensammlung, die auch aus späteren Schritten des UCD-Prozesses bekannt sein dürften.

Nachfolgend möchte ich Ihnen fünf Methoden vorstellen, die sich aus meiner Sicht besonders gut zur Requirements Elicitation eignen. Vollständig ist die Liste nicht (der Babok-Guide nennt z. B. neun Methoden der Elicitation), aber sie umfasst die Methoden, die sich für mich und meine Kollegen in der Vergangenheit bewährt haben.

Beobachtung

Beobachtungen sind ein schöner erster Schritt, um einen ganzheitlichen Eindruck von der „Welt“ der Nutzer zu erhalten. Die klassische Beobachtung orientiert sich dabei am Dokumentarfilm, es wird beobachtet und wenn möglich das Geschehen nicht gestört.

Stellen wir uns als Beispiel vor, wir würden für ein Unternehmen ein neues Intranet erstellen wollen. Im ersten Schritt würden wir Mitarbeiter aussuchen, die später das System benutzen sollen und würden diese über mehrere Stunden oder Tage bei der Arbeit wie ein Schatten begleiten. Dabei wird alles notiert: welche Aufgaben der Mitarbeiter absolviert, welche Systeme er benutzt, wo er Probleme erlebt etc. Etwas knifflig ist dabei der Spagat möglichst viel aus der Beobachtung mitzunehmen und den Mitarbeiter nicht zu stark bei seiner Arbeit zu stören. Es gilt daher nur unterbrechen und Zwischenfragen stellen, wenn es für das Verständnis wichtig ist (z. B. „Ich kann es leider nicht erkennen, welches Programm benutzen sie gerade?“).

Interviews (Kontextuell)

Im Interview kann man entscheiden, ob man so explorativ vorgeht wie bei der Beobachtung und offene, allgemeine Fragen stellt, oder schon bestimmte Ideen abfragt und schaut, wie sie bei dem Nutzer ankommen. Kontextuelle Interviews beziehen, wie der Namen schon sagt, den Kontext des Nutzers ein und würden in unserem Intranet-Beispiel an den Arbeitsplätzen der Mitarbeiter stattfinden. Der Vorteil liegt darin, dass der Interviewer einen umfassenderen Einblick erhält und sich ggf. Sachen vor Ort zeigen lassen kann („Sie sagen, dass es in diesem Prozess einen Schritt gibt, den sie überflüssig finden. Können Sie mir zeigen welchen Sie meinen?“).

Befragung

Für das Sammeln von Nutzerfeedback im größeren Stil empfiehlt es sich eine Befragung zu schalten. Die Einladung erfolgt bspw. mittels einer Onsite-Berfragung auf der Webseite oder in unserem Intranet-Beispiel über die Einladung der Mitarbeiter per E-Mail. Ein Vorteil der Befragung ist, dass man kostengünstig eine relativ große Anzahl an Nutzern erreicht. Ein Nachteil ist, dass man auch nur die Aspekte erfasst, an die man bei der Gestaltung des Fragebogens gedacht hat. Eine Lösung dafür sind beispielsweise Nutzertagebücher.

Fokusgruppen

Für eine Fokusgruppe werden mehrere Nutzer zur Diskussion eingeladen. Die Methode eignet sich, um Ideen für die Entwicklung zu erhalten oder um erste Entwürfe bewerten zu lassen. Bei unserem Intranetprojekt könnte eine Fokusgruppe bspw. so aussehen, dass 5-8 Mitarbeiter mehrere Vorschläge für Funktionen des neuen Intranets erläutert bekommen und gemeinsam diskutieren, welche einen Mehrwert bieten und wie diese auszusehen hätten.

Workshops (mit Prototyping)

Diese Methode steht an letzter Stelle, da hierbei schon Insights über die Nutzer vorhanden sein müssen. Zum einen kann dies dadurch erreicht werden, dass eine der bereits beschriebenen Methoden durchgeführt wurde und die Ergebnisse nun vorliegen. Zum anderen können die Teilnehmer des Workshops auch so ausgewählt sein, dass sie Wissen über die Nutzer aus ihrem Joballtag mitbringen. Dies können bspw. Mitarbeiter aus dem Kundenservice sein, oder Teilnehmer, die selbst Nutzer des Systems sind. Im Workshop mit den ausgewählten Teilnehmern werden die Nutzeranforderungen gesammelt, gemeinsam priorisiert und es können auch schon erste Designvorschläge entwickelt werden. Ein für diesen Prozess gut geeignetes Workshopformat ist Studio Design, das Lorena Meyer kürzlich im Blog vorgestellt hat.

Mit diesen Methoden – am besten einer Kombination aus mehreren – können Sie sicherstellen, dass Sie den Nutzer und seine Bedürfnisse kennen. Wichtig ist dabei, dass Sie nicht vergessen, dass dies noch keine Garantie für eine erfolgreiche Umsetzung in Nutzeranforderungen ist. Denn wie ein Zitat von Henry Ford zu seinem Requirements Elicitation Prozess bei der Automobilentwicklung zeigt, ist es dann noch wichtig die richtigen Schlüsse zu ziehen:

„If I‘d have asked my customers what they wanted, they would have told me ‚A faster horse‘.“

Es gilt den Kunden zu verstehen und seine Wünsche aufzunehmen, aber auch über dem Horizont des Kunden nach Lösungen zu suchen. Hier setzt der zweite Baustein im Erstellen der Nutzungsanforderungen an: die Analyse der Ergebnisse und das Umsetzen in die richtigen Spezifikationen. Hierfür sind das Know-How und der Erfahrungsschatz der Requirements Engineers/UX Professionals notwendig. Fehlt dieses Wissen, scheitert man schon in einer sehr frühen Phase eines Projektes. Wie dies dann aussehen kann, illustriert wunderbar der Swing Tree Comic:


Comic

Quelle: http://web.archive.org/web/20061018024303/http://weblog.cemper.com/a/200309/09-typical-project-life.php


Wie sind Ihre Erfahrungen mit dem Erheben der Nutzeranforderungen? Wichtiger Teil des Entwicklungsprozesses oder eher das Ausnahmevorgehen?

Portraitfoto: Marie Jana Tews

Marie Jana Tews

Senior User Experience Consultant

Alumni-eresult GmbH

Bisher veröffentlichte Beiträge: 12

Schreibe einen Kommentar

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