Julian Traut

Voraussichtliche Lesedauer: 9 Minuten

TalkAbout

Zuerst zuhören – User-Centered Design

Jedes Projekt ist anders und hat eigene Voraussetzungen und Herausforderungen. Deshalb ist es wichtig, Vorgehen und Methoden in jedem Projekt von Neuem an die Aufgabe und an die Menschen im Projekt anzupassen. Trotzdem wollen wir euch das Zusammenspiel der verschiedenen Methoden an einem konkreten Projektbeispiel illustrieren. Dabei sagen wir nicht: „Macht es so!“. Wir hoffen,…

TalkAbout

Jedes Projekt ist anders und hat eigene Voraussetzungen und Herausforderungen. Deshalb ist es wichtig, Vorgehen und Methoden in jedem Projekt von Neuem an die Aufgabe und an die Menschen im Projekt anzupassen. Trotzdem wollen wir euch das Zusammenspiel der verschiedenen Methoden an einem konkreten Projektbeispiel illustrieren. Dabei sagen wir nicht: „Macht es so!“. Wir hoffen, dass die konkrete Beschreibung am Praxis-Beispiel hilft, besser zu verstehen, wie wir den User-Centered-Design-Ansatz leben.

Wir beschreiben unser Tun in vier Blogartikeln entlang der vier Phasen des Projekts:

  1. den Nutzer-Kontext verstehen
  2. Anforderungen formulieren
  3. Ideen entwickeln
  4. Lösungen evaluieren

Das Projekt ist fiktiv; was wir beschreiben, ist so nie passiert. Aber es könnte so stattgefunden haben: Es handelt sich um einen Zusammenschnitt von Projekterfahrungen von vielen verschiedenen Menschen. Die Inhalte sind also nicht ausgedacht.

Unser fiktiver Kunde

Unser Kunde, die Meyer Logistik (ML), ist ein großes deutsches Logistikunternehmen. ML transportiert Waren mit einer eigenen Flotte quer durch Deutschland. Die Planung der Fahrzeugtouren ist an sich schon eine komplexe Aufgabe. In den letzten Jahren hat sich zudem die Auftragslage bei ML grundlegend geändert. Statt großer langfristiger Verträge mit regelmäßig wiederkehrenden Touren wurde das Geschäft immer kurzfristiger und individueller. Mit dem alten Planungssystem ist das kaum mehr zu bewältigen. Die fünfzehnköpfige Planungsabteilung schafft es mehr schlecht als Recht mit dem System und mehreren selbstgestrickten Excel-Lösungen den Betrieb aufrecht zu erhalten.

Deshalb hat man sich nun für den Neubau eines Planungssystems entschieden. Es ist bereits klar, dass der Neubau individuell erfolgen soll. Der Kunde wünscht sich von uns ein nutzerzentriertes Vorgehen.

Erste Schritte: den Nutzerkontext verstehen

Wir starten mit einer kurzen Einarbeitungsphase. Durch die Projektleiterin Annett Haders bekommen wir eine Einführung in die Thematik und die Besonderheiten bei der ML. Sie erklärt uns auch, dass es bei der ML drei Planungsteams gibt: Kurz-, Mittel- und Langfristplanung. Die Tourenplanung bekommt vom Vertrieb die tatsächlich eingegangenen Aufträge und gibt die fertige Planung dann an die Disposition weiter. Dabei ist die Langfristplanung auch Grundlage für die Unternehmensplanung und wird deshalb auch dem Flottenmanagement übergeben.

Aus diesen Informationen können wir bereits eine erste Version eines BigPictures der Ist-Situation erstellen. Wir stellen Annett Haders die erste Version vor, um sicher zu sein, dass wir alles richtig verstanden haben.

Mit diesem Grundverständnis ausgestattet wollen wir nun die Nutzer und Nutzerinnen des Systems besser kennenlernen. Wir wollen dabei unser Wissen sowohl durch Beobachtungen als auch durch kontextuelle Interviews gewinnen. Gemeinsam mit Annett Haders legen wir geeignete InterviewpartnerInnen fest. Wir wollen mit jeweils drei Menschen aus der Kurz- und Mittelfristplanung sprechen, da dies die Abteilungen mit dem größten Schmerz sind, und mit einer Person aus der Langfristplanung. Dazu kommt je eine Person aus den drei Nachbarabteilungen: dem Vertrieb, der Disposition und dem Flottenmanagement. Hier wollen wir im ersten Schritt einen Überblick gewinnen und verabreden daher ein Gespräch mit TeamleiterInnen, während wir in den Planungsabteilungen direkt mit den Nutzern sprechen.

Mit den NutzerInnen abtauchen

In dieser frühen Phase sind unsere Interviewleitfäden noch sehr generisch: NutzerInnen erklären uns ihre Aufgaben, wir fragen sie nach dem typischen Ablauf und auch den Problemen, die sie bei ihrer Arbeit erleben. Ganz besonders wertvoll ist es dabei für uns, die Excellösung der Mittelfristplanung in Aktion zu sehen. Sie wurde von einem der erfahrenen Planer selbst entwickelt und immer weiter verfeinert. Mittlerweile hat sie sich als Arbeitsmittel in der gesamten Mittel- und Langfristplanung durchgesetzt. Stolz erläutert uns der Kollege die vielen Features und Übersichten, die er nach und nach integriert hat. 

Zwischen den Interviews kommen wir immer wieder zusammen, um unsere Erkenntnisse zu konsolidieren und erste Schlüsse daraus zu ziehen. Nach zehn Gesprächen haben wir viel über die Nutzer und ihre Bedürfnisse gelernt und verstehen auch die Abläufe und Aufgaben wesentlich besser. Um die Ergebnisse für uns festzuhalten und auch den anderen Projektbeteiligten zu transportieren, nutzen wir verschiedene Formate.

Kristallisationspunkt Personas

Zum einen haben wir unter den Planern zwei Personas identifiziert. Unabhängig vom Planungsabschnitt gibt es zwei typische Werdegänge bei der ML. Ein großer Teil der PlanerInnen kommt aus der Praxis, ist früher selbst LKW gefahren und meist schon sehr lange im Unternehmen. Durch ihre Erfahrung haben sie viel Wissen „im kleinen Zeh“. Sie haben es oft „im Gefühl“, ob eine Planung funktioniert, bevor sie es im Detail nachvollzogen haben. Wir taufen die Persona „den Fahrer-Max“. In den letzten Jahren kamen einige KollegInnen dazu, die einen akademischen Hintergrund haben. Ihre mangelnde Praxiserfahrung machen sie durch analytischere Herangehensweisen und manchmal durch einen größeren Überblick wett. Für diesen Typ von PlanerIn heißt unsere Persona „die Logistik-Anne“.

Annett Haders glaubt, dass der ML ohne diese Mischung aus Max‘s und Annes „der Laden schon längst um die Ohren geflogen wäre“. In den Interviews haben wir gemerkt, dass die beiden Typen von Planern sich in ihren Bedürfnissen unterscheiden. Dieser Unterschied ist  viel deutlicher als der zwischen den Abteilungen. Um diese unterschiedlichen Bedürfnisse festzuhalten, kreieren wir zu den beiden Personas zwei Empathy Maps. Zusammen mit den Personas haben wir so die „Nutzerseite“ unserer Erkenntnisse abgedeckt.

Die großen Zusammenhänge sehen

Um auch die Abläufe und Aufgaben besser zu strukturieren, greifen wir nochmal auf unser Big Picture zurück. Mit den Erkenntnissen, die wir jetzt haben, erscheint uns unser erster Wurf ziemlich naiv. Er hat uns aber gute Dienste erwiesen und auch Annett Haders war angetan: „So etwas könnte ich auch gebrauchen, um endlich mal mit den anderen Abteilungen reden zu können“. Also verfeinern wir das Bild von einem groben Überblick zu einem detaillierten Bild der Planung bei der ML. Das ermöglicht es uns auch, die Knackpunkte und Schmerzen, die wir bereits aus den Interviews herausgehört haben, zu verorten.

Beispielsweise haben wir gelernt, dass die Übergabe zur Disposition bereits zwei Wochen vor der eigentlichen Fahrt erfolgen muss. Bis drei Tage vorher gehen jedoch noch Änderungswünsche der Kunden ein. Immer wieder gehen diese Änderungswünsche verloren, weil sie es zwar noch in die Planung schaffen, aber in der Disposition nicht mehr ankommen. Das ist ärgerlich und soll mit dem neuen System unbedingt gelöst werden. Wir verorten das als roten Blitz an der Schnittstelle zwischen Planung und Disposition und machen uns eine kurze inhaltliche Notiz dazu. Später werden wir klären, ob es sich um ein Prozess- oder ein Systemproblem handelt und was eine geeignete Lösung dafür sein könnte.

Personas auf die Reise schicken

Während uns das BigPicture einen guten Überblick über den Ablauf und das Zusammenspiel der verschiedenen Planungsschritte gibt, haben wir noch viel über den Tagesablauf und die einzelnen Arbeitsschritte der PlanerInnen gelernt. Diese Erkenntnisse halten wir in Customer Journeys fest. Annett Haders erklären wir, dass es sich eigentlich um Employee Journeys handelt und einigen uns auch gleich auf diesen Begriff, da wir ja nicht die Kunden von ML im Blick haben.

Aus unseren Interviews haben wir den Eindruck gewonnen, dass sich die Abläufe in der Mittel- und Langfristplanung kaum unterscheiden. Außerdem entscheiden wir uns dazu, erstmal nur den Normalfall zu modellieren, sodass wir mit zwei Journeys auskommen: einer Kurzfrist-Journey  und einer für die Mittel-und-Langfrist-Planung.

Spannend wird es nochmal, als wir gemeinsam mit Annett Haders unsere zwei Personas Max und Anne auf die Customer Journey schicken. Dabei „entdecken“ wir, dass Max in der Kurzfristplanung zwar sehr schnell einschätzen kann, wo er anpacken muss, wenn sich etwas ändert. Es fällt ihm aber schwer, die Änderungen, die er dann an der Planung macht, auch nachzuhalten. Bei Anne scheint es umgekehrt zu sein. Dadurch, dass wir die verschiedenen Bedürfnisse je Persona mit den Employee Journeys verknüpfen, können wir wieder darauf zurückkommen, wenn wir im nächsten Schritt konkrete Anforderungen ableiten.

Von der Idee zur Anforderung

User-Centered Design bedeutet, NutzerInnen in den Mittelpunkt unserer Arbeit zu stellen. In den vier Phasen verschiebt sich jedoch der Fokus: Während wir uns bisher stark auf die NutzerInnen selbst konzentriert haben, werden wir im nächsten Schritt, dem „Anforderungen definieren“, stärker auf Prozesse und Systeme schauen. Das beschreiben wir in diesem Blogbeitrag. Auch in dieser Phase werden wir neue Erkenntnisse und Informationen in unsere bisher erstellten Artefakte einarbeiten.

Deswegen ist es wichtig, unser Verständnis so zu dokumentieren, dass wir auch später problemlos uns und anderen in Erinnerung rufen können, für wen wir die Anwendung bauen werden.


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: In dieser ersten Phase wollen wir den Nutzer-Kontext verstehen. In der zweiten Phase geht es darum, Anforderungen zu formulieren. Hier geht es zur Lektüre von Teil 2.

Über den Autor

Julian Traut