Ans Eingemachte – Ideen im UCD-Prozess entwickeln

User-Centered Design bedeutet, NutzerInnen in den Mittelpunkt unserer Arbeit zu stellen. Wir beschreiben unser Vorgehen in einer Artikelserie über ein fiktives Projekt beim fiktiven Logistikunternehmen ML. Jede der vier Phasen unseres Projekts steht im Mittelpunkt eines eigenen Blog-Artikels. Der erste Teil beschäftigt sich damit, den Nutzer-Kontext zu verstehen (Link zum Artikel). Der zweite Teil erklärt, wie Anforderungen formuliert werden sollten (zur Leküre).

In diesem Blog schreibe ich über die dritte Phase: Ideen entwickeln. Im vierten Teil geht es darum, Lösungen zu evaluieren (Link unten).

---

Ideen entwickeln im Partizipativen Parallelen Design Workshop

Am liebsten würde Annett Haders jetzt alles gleichzeitig anpacken, schließlich hat sich die Entscheidung für einen Neubau schon ewig gezogen und alle KollegInnen warten sehnlichst auf die neue Lösung. Wir können sie aber davon überzeugen, dass wir mehr und vor allem früher PS auf die Straße bringen, wenn wir uns für die nächste Phase etwas fokussieren. Gemeinsam mit drei Key-Usern und den TeamleiterInnen legen wir fest, dass wir uns zunächst auf die Mittelfristplanung konzentrieren wollen. Gerade der Abschluss der Planung ist durch die bisherige Excellösung noch nicht gut unterstützt, sodass dort eine neue Lösung voraussichtlich sehr schnell großen Nutzen stiften könnte. Wir versprechen Annett Haders, auch die anderen Themen weiterzutreiben und teilen uns daher in zwei Streams auf: Während ein Kollege von uns im Stream KUFRI die Themen in der Kurzfristplanung und insbesondere das Verhältnis Disposition und Planung weiter unter die Lupe nimmt, startet der Rest von uns mit dem Stream MIFRI in die nächste Phase.

Annett Haders ist ganz begeistert, als sie unser Erklärvideo zum Partizipativen Parallelen Design Workshop sieht und freut sich schon darauf. Bei diesem Workshop laden wir unterschiedliche Stakeholder zum gemeinsamen Malen ein und fördern so die partizipative Entstehung von Lösungsideen. Als wir dann in die konkrete Planung gehen, ist Annett Haders jedoch etwas skeptisch: „Ob die Kollegen auch wirklich malen werden?“ Wir versichern ihr, dass wir bisher bei allen unseren Kunden tolle Erfahrungen gemacht haben und es uns gelungen ist, selbst harte Nüsse aus der Verweigerungshaltung zu holen. Außerdem haben wir schon einen guten Eindruck von den NutzerInnen und können es uns durch die Zusammensetzung der WorkshopteilnehmerInnen auch etwas leichter machen. Ihren zweiten Einwand „Wahrscheinlich kommt eh nur Excel dabei raus!“ entkräften wir schnell, indem wir Ihr unsere neue Teamkollegin vorstellen, die wir zusätzlich zu den PPD Workshops mit an den Tisch setzen. Anders als wir steckt sie noch nicht bis über beide Ohren in der Fachlichkeit und kann so frei und kreativ Impulse einstreuen.

Für den ersten PPD wählen wir nur die Epic „Kennzahlenberechnung und Ausgabe“ aus dem Use Case „Planungsabschluss Mittelfristplanung“. Wir haben zwar noch die „Dokumentenerzeugung“ mit vorbereitet, gehen aber davon aus, dass uns nach einem Vormittag gemeinsamem Scribbeln so der Kopf schwirrt, dass wir dazu nicht mehr kommen werden. Aber wer weiß, vielleicht überraschen uns unsere sechs TeilnehmerInnen?

Von der Anforderungsanalyse zur Ideenfindung

Der Tag des ersten PPDs ist gekommen – wir sind jetzt auch ein bisschen aufgeregt, schließlich kann man nie genau voraussehen, was für Fallstricke sich noch ergeben. Haben wir die Aufgabe gut und konkret genug beschrieben? Haben wir vielleicht Querverbindungen übersehen? Da hilft es, dass eine unserer alten Häsinnen uns nochmal in Erinnerung ruft: Der PPD ist erst der Übergang von der Anforderungsanalyse zur Ideenfindung – im „schlimmsten Fall“ verstehen wir die Anforderungen besser und können so nochmal blinde Flecken identifizieren. Die TeilnehmerInnen trudeln nach und nach ein und die Anspannung löst sich sofort. Mit vier von ihnen haben wir bereits Interviews geführt und begrüßen uns entsprechend schon fast herzlich. Das kleine Warm-up, das wir vorbereitet haben tut sein Übriges. Unterwegs wird es noch einmal knifflig, weil unsere Moderatorin wiederholt einen Teamleiter mit der Kritikklatsche zur Ordnung rufen muss. Aber da hilft das spielerische Setting, sodass nach mehreren Runden sich tatsächlich zwei Lösungsansätze herauskristallisieren. Wie erwartet ist nach dem ersten Epic die Luft raus, sodass wir uns entschließen lieber gemeinsam ein frühes Mittagessen einzunehmen, als das zweite Epic noch übers Knie zu brechen.

Beim Mittagessen werden wir gefragt, was letztendlich mit den Entwürfen passiert. Wir erklären, dass für uns die Arbeit eigentlich jetzt erst richtig beginnt. Wir werden in den nächsten Tagen die verschiedenen Ideen konsolidieren und zu ersten Wireframes zusammenfügen. Dieser Schritt ist wichtig, da auch wir selbst – in drei Minuten – kein perfektes Screendesign nach allen Regeln guter Usability zaubern können. Auch kann es sein, dass sich aus der Kombination einiger Ideen nochmal etwas ganz Neues ergibt oder dass sich Ideen eventuell nicht gemeinsam umsetzten lassen. Wir versprechen, so schnell wie möglich einen ersten Papierprototypen zu erstellen, den wir wieder mit den TeilnehmerInnen und anderen KollegInnen verproben werden. Mit diesem Cliffhanger gehen wir auseinander.

Beim Kaffee nach dem Essen fragt uns Annett Haders in kleiner Runde, ob sie das richtig verstanden hätte: dass wir jetzt gleich in die nächste Phase des UCDs springen würden, und ob die Ideenphase immer so kurz sei. Unsere Antwort ist ein klares Jein. Im Prinzip hat sie recht, dass wir uns mit dem Prototypen jetzt sehr schnell in die nächste Phase begeben. Wir erklären dabei jedoch, dass der UCD Cycle jetzt Fahrt aufnimmt und wir von nun an immer schneller zwischen Ideenentwicklung und Lösungsevaluierung hin und herspringen werden. Genaugenommen werden wir sogar alle vier Phasen immer wieder durchlaufen, da wir aus den Tests ein neues Verständnis für die Nutzer entwickeln werden und sich neue Anforderungen herauskristallisieren. Das heißt, die Ideenphase ist nicht abgeschlossen, sondern wir uns immer wieder begegnen.

Das passiert dann auch in den nächsten Wochen. Mit zwei weiteren PPDs erschließen wir uns die weiteren Epics des Usecases „Planungsabschluss der Mittelfristplanung“. Auch hier entstehen jeweils kleine Papierprototypen. Zusammen mit den Erkenntnissen aus den Nutzertests gewinnen wir Stück für Stück immer konkretere Facetten der neuen Lösung.

Eine klare und logische Informationsorganisation 

Bald haben wir das Bedürfnis besser zu verstehen, wie die einzelnen Epics zusammenwirken und wie dieser Teil der zukünftigen Anwendung strukturiert sein könnte. Dazu wollen wir eine Informationsarchitektur erstellen, um eine klare und logische Organisation von Informationen zu schaffen. Mittlerweile fühlen wir uns selbst wie kleine LogistikexpertInnen und so ist die Versuchung groß einfach ein Modell dazu gemeinsam ans Whiteboard zu pinseln. Wir wollen aber die zukünftigen NutzerInnen auch hier in die Konzeption mit einbinden. Deshalb laden wir drei von ihnen zu einem Card-Sorting-Workshop ein. Hierbei achten wir, wie auch schon bei den PPDs, darauf, dass unsere beiden Personas „Fahrer-Max“ und „Logistik-Anne“ auch durch unsere TeilnehmerInnen vertreten sind.

Für den Workshop bereiten wir die identifizierten Funktionen der Anwendung auf Kärtchen vor. Hierbei abstrahieren wir nochmal aus den vertesteten Papierprototypen, weil wir im Workshop weniger auf die Lösung selbst, als vielmehr auf ihre Struktur abzielen. Zusätzlich ergänzen wir das Set an Karten um gröbere Blöcke jenseits der bereits bearbeiteten Use Cases, sodass am Schluss ein Gesamtbild der ganzen Anwendung in unterschiedlicher Granularität entstehen kann.

Wir bitten die NutzerInnen im Workshop ihr Kartenset so zu sortieren, wie es ihnen logisch erscheint. Auch wenn die Ergebnisse sich nicht komplett decken, kommen die TeilnehmerInnen am Ende doch auf eine sehr einheitliche Gesamtstruktur. Es stellt sich heraus, dass wir mit unserem Modell an einigen Stellen echt danebengelegen hätten. Wir hätten intuitiv alle Konsistenzprüfungen zusammengefasst und in einem separaten Block alle Funktionen zur Dokumentengenerierung. Unsere drei NutzerInnen haben jedoch unabhängig voneinander noch eine eigene Kategorie „Zoll“ gebildet, die sowohl Prüfungen als auch Dokumentenfunktionen enthält. Darauf angesprochen erläutern sie, dass die Zollprüfung und Zollvoranmeldung zu einem anderen Zeitpunkt in einem separaten Prozess erfolgt. Das können wir nun bei der Gestaltung der Informationsarchitektur berücksichtigen.

Bau eines Klickprototypen

Auf der inhaltlichen Seite haben wir nun schon soviel Klarheit, sodass wir gerne einen Klickprototypen bauen würden. Zum einen wollen wir damit wieder in die Evaluation gehen und weitere Erkenntnisse über die NutzerInnen generieren bevor wir in die Entwicklung starten. Zum anderen muss Annett Haders das Management der ML noch endgültig überzeugen, dass der gewählte nutzerzentrierte Ansatz zwar scheinbar aufwendiger ist, sich aber auszahlt. Genau dafür wäre es großartig, wenn Annett Haders im nächsten Lenkungskreis bereits etwas „Anfassbares“ vorzeigen könnte.

Wir könnten natürlich die Wireframes direkt zu einem Klickprototypen zusammenfassen. Als Vorbereitung auf die Entwicklung und zur Begeisterung des ML-Managements entscheiden wir uns aber dafür, gleich auch das Visual Design mit anzugehen. Wir möchten die Wireframes nun zu visuell ansprechenden Mockups ausarbeiten und dabei zu einem Klickprototypen integrieren. Bei der ML gibt es bisher keine einheitlichen Design-Vorgaben für Applikationen, lediglich ein Corporate Design für die Website wurde einmal erstellt. Wir lehnen uns daran an und nutzen die Gelegenheit einen Style Guide zu etablieren indem wir wiederkehrende Elemente und Interaktionen in einer zentralen Bibliothek beschreiben. So können wir späteren Wildwuchs und Doppelarbeit verhindern, da nun auch unsere EntwicklerInnen direkten Zugriff auf eine zentrale „Wahrheit“ haben.

Auch mit dem Klickprototypen durchlaufen wir mehrmals den UCD Cycle und entwickeln ihn in jeder Iteration weiter. Im Lenkungskreis wird der Prototyp zum echten Hingucker. Zusammen mit den Personas, die wir auch nochmal vorstellen, kann Annett Haders schlüssig darstellen, warum es gut war, sich so stark mit den Nutzern zu beschäftigen. So lassen wir an zwei Stellen im Prototyp bereits personaspezifische Funktionen durchscheinen: Für den „Fahrer-Max“ haben wir eine Sidebar mit einer Checkliste implementiert, die ihm hilft, an alles zu denken. Für die „Logistik-Anne“ hat sich eine Vorschlagsfunktion in der Planung als der Hit in den Nutzertests herausgestellt. Zusammen mit echten O-Tönen aus den Interviews und Impressionen aus den Workshops ist das Management überzeugt und gibt das Budget für die Entwicklung frei. Ein Grund zum Feiern, doch vorher wollen wir noch einen finalen Nutzertest mit unserem Klickprototypen machen.

---

In unserer Blog-Serie über User-Centred Design beschreiben wir unser Vorgehen an einem fiktiven Projekt. Wir beschreiben jede der vier Phasen unseres Vorgehens in einem eigenen Blog-Artikel:

1. Nutzer-Kontext verstehen (Link zum Artikel)
2. Anforderungen formulieren (Link zum Artikel)
3. Ideen entwickeln (Artikel oben)
4. Lösungen evaluieren (Link zum Artikel)

---