Collaborative UX Design

WORKSHOP: MVP-PLANUNG

Überblick

Priorisierungsmatrix

Roadmap

Metrikenboard

Planung von A/B-Tests

Zusammenfassung MVP-Planung

Literatur

Literaturverzeichnis

Index

EINLEITUNG

Die Konzeption und Entwicklung von Software erfolgt zunehmend in cross-funktionalen Teams. Die einzelnen Mitglieder eines über einen längeren Zeitraum zusammenarbeitenden Teams bringen Expertise in verschiedenen Bereichen – Produktmanagement, User Experience (UX) Design, Implementierung, Testing und Betrieb – ein. Interdisziplinäre Teams konzipieren und gestalten ein Produkt in gemeinsamen, aufeinander aufbauenden Workshops. In diesem Buch stellen wir zentrale Inhalte und zielgerichtete Abfolgen solcher kollaborativen Workshops zur Produktkonzeption vor.

INTERDISZIPLINÄRE TEAMS

Thomas schreitet zum Rednerpult. Er weiß, dass er gleich vor mehr als 200 Vertriebsmitarbeitern und -mitarbeiterinnen sprechen wird – fast das gesamte Verkaufsteam ist anwesend. Sein Herz pocht. Er atmet noch einmal tief durch, bevor er mit seiner Präsentation beginnt.

»Hallo, ich bin Thomas. Ich bin Senior User Experience Manager. Gerne möchte ich euch einen Überblick über das zukünftige Release unserer Software geben«, stellt sich Thomas vor.

Seine Präsentation dauert dreißig Minuten. Dreißig Minuten, die für Thomas nicht zu enden scheinen. Seine Nervosität hat sich als berechtigt erwiesen. Der verhaltene Applaus nach seiner letzten Folie verebbt schnell, aus dem Publikum kommen eindringliche Fragen:

»Danke für die Präsentation und die Eindrücke zum neuen Release, Thomas. Mir brennt bereits seit zwanzig Minuten eine Frage unter den Nägeln: Wurde diese Version tatsächlich mit Vertretern unserer Zielgruppe evaluiert? Ich kann mir kaum vorstellen, dass unsere Nutzer diese Software verstehen.«

»Hey Thomas, ich habe echt keine Ahnung, was ihr da in euren Büros macht, aber das, was du uns da gezeigt hast, kann ich nicht guten Herzens empfehlen – und schon gar nicht verkaufen. Das ist einfach deutlich zu komplex und geht an den Bedürfnissen unserer Nutzer komplett vorbei.«

Thomas fühlt sich mit jeder Frage unwohler. Nervös blickt er auf seine Uhr. Wie lange dauert die Fragerunde denn noch? Eines ist ihm bereits jetzt klar: Diese Präsentation ist ein Desaster. Und dieser Releasekandidat ist ebenfalls ein Desaster. Wie konnte dies nur passieren? Warum hat er die Reaktionen nicht kommen sehen?

Kaum ist die Präsentation vorüber, Thomas hat gerade das Rednerpult verlassen, klingelt auch schon sein Handy: Robert ist dran – ein sehr wenig begeisterter Robert. Robert ist Vertriebsleiter und einer der einflussreichsten Manager des Unternehmens. Er kommt ohne Umschweife direkt zum Punkt: »Thomas, ihr habt fünf Wochen Zeit, das Release in die richtigen Bahnen zu lenken. Es ist mir vollkommen egal, wie ihr das anstellt und ob ihr in den nächsten fünf Wochen zum Schlafen kommt. Die Software wird zum bereits offiziell verkündeten Termin vorgestellt – bis dahin habt ihr das jetzige Komplexitätsmonster gezähmt und daraus eine begeisternde Anwendung gemacht.«

An diesem Abend meldet sich Thomas für die nächsten Wochen bei seiner Familie ab. Er nimmt seine Regenjacke und macht sich auf den Weg. Es wird ein besonders langer Spaziergang werden. Thomas will nachdenken, sein Gehirn befindet sich in einem Ausnahmezustand. Gedanken rasen durch seinen Kopf, versuchen alle Richtungen zu erkunden und beginnen sich nur langsam zu ordnen.

Wie können wir ein Release in nur fünf Wochen grundlegend verbessern, an dem wir nun ein halbes Jahr – offensichtlich erfolglos – gearbeitet haben? Wie sollen wir das schaffen? Angenommen, wir könnten in zwei Wochen ein nachvollziehbares UX Design definieren und es dann der Entwicklungsabteilung übergeben. Vielleicht schaffen es die Kolleginnen und Kollegen ja, das Konzept dann in zwei weiteren Wochen umzusetzen. Anschließend könnten wir Usability-Tests durchführen – und hoffen, dass die rekrutierten Nutzer damit zurechtkommen. Zur Einarbeitung von Feedback oder Korrekturen hätten wir ohnehin keine Zeit mehr.

Thomas atmet beim Gehen schwer. So wird es nicht funktionieren.

Es müssen alle koordiniert zusammenarbeiten, um keine Zeit mit Irrwegen zu verlieren, die erst spät erkannt werden. Im Kopf von Thomas formt sich das Bild eines interdisziplinär zusammengesetzten Teams, dessen Mitglieder gemeinsam im gleichen Raum arbeiten. Thomas braucht schnelles Feedback – an jedem zweiten Tag möchte er Nutzer einladen, die mit dem aktuellen Stand der Software typische Aufgaben bearbeiten. Resultierende Erkenntnisse aus leichtgewichtigen Usability-Tests fließen direkt in ein überarbeitetes Konzept ein – UX Design und Development ziehen am gleichen Strang und werden durch alle Abteilungen fortlaufend unterstützt. Auf eine detaillierte Dokumentation wird verzichtet, Ergebnisse von Meetings werden in Fotografien von Flipcharts, handgezeichneten Skizzen und Anordnungen von Post-its festgehalten. Thomas stellt sich vor, wie Entwickler Layoutskizzen und Workflows lebhaft mit Designern diskutieren, gemeinsam die verschiedenen Module der Software durchgehen und erarbeitete Konzepte unmittelbar umsetzen. Im Abstand von zwei Tagen sollen alle Teammitglieder das Feedback durch die eingeladenen Nutzer erleben: Für erkannte Usability-Barrieren werden Lösungen gesucht und ihre Eignung und Belastbarkeit im aktuellen Konzept evaluiert. Thomas ist zuversichtlich, durch eine abgestimmte, kollaborative Teamarbeit die eben noch unlösbar scheinende Aufgabe doch noch bewältigen zu können.

Am Ende seines Spaziergangs zeichnet sich schließlich ein Lächeln auf seinem Gesicht ab: Thomas hat einen Plan für das weitere Vorgehen gefasst.

Gleich am nächsten Morgen stellt Thomas ein Team zusammen und folgt dabei der Vorstellung, die er während seines Spaziergangs entwickelt hat. Er organisiert einen Projektraum und ahnt, wo er und sein Team nun wohl den Großteil der folgenden fünf Wochen verbringen werden. Die Tische platziert Thomas in der Mitte des Raums, alle Wände sollen frei bleiben, um große Flächen für Klebezettel, Skizzen und Workflows bieten zu können.

Als die Mitglieder seines Teams den Raum betreten, schauen sie sich verwundert an. Was sie sehen, erscheint ihnen ungewohnt. Thomas bemerkt das Erstaunen und erklärt seinen Ansatz:

»Ich begrüße euch – wir werden in den kommenden Wochen viel zu tun haben! Wie ihr bereits gehört habt, sollen wir die Kastanien aus dem Feuer holen. Der Zeitplan ist, vorsichtig formuliert, sehr ambitioniert. Wir sind von nun an ein Team, entweder wir schaffen das gemeinsam oder unser Produkt und wir stecken in ziemlichen Schwierigkeiten. Ich möchte, dass sich jeder einbringt, in jeder Phase, bei jeder Aktivität. Rollen werden keine wesentliche Bedeutung haben, ob ihr Entwickler, Designer oder Produktmanager seid – ihr werdet über euren Tellerrand hinausschauen und eng zusammenarbeiten. Wir alle wissen, was davon abhängt.«

Thomas Einführung zeigt Wirkung, in den nächsten Tagen wird unter Hochdruck gearbeitet, die Workflows der Software werden gemeinsam kritisch analysiert und Optimierungen erkundet. Lösungsansätze werden visualisiert und mit Nutzern besprochen, wenn notwendig angepasst und zügig umgesetzt. Immer wieder kommt das Team in größeren Runden zusammen, um den Stand zu diskutieren, bevor anschließend wieder zu zweit an einzelnen Komponenten gearbeitet wird. Auch wenn eigentlich viel zu wenig Zeit zur Verfügung steht, stellt sich nach einigen Tagen eine gewisse Routine ein. Im Kern wiederholt sich ein bestimmter Ablauf: Das Team wählt eine relevante Fragestellung, befragt Nutzer hierzu, beginnt ein optimiertes Lösungskonzept zu entwickeln, setzt es um und evaluiert das Ergebnis sofort wieder mit repräsentativen Nutzern.

Nach Ablauf der vorgegebenen fünf Wochen lädt Thomas zu einem Präsentationstermin ein: Das Team hat es tatsächlich geschafft! Der neue Releasekandidat wird vorgestellt – er wurde an entscheidenden Stellen radikal vereinfacht. Und dieses Mal verläuft die Präsentation ganz anders als die erste, allen Anwesenden wird sofort klar, dass dem Team ein großer Wurf geglückt ist. Der Verkaufsleiter steht nach dem letzten Satz der Präsentation auf und gratuliert dem sichtlich erleichterten Thomas mit einer anerkennenden Umarmung. Thomas gibt das Lob sogleich an sein Team weiter und bedankt sich für das tolle Engagement in den letzten Wochen. Der dann folgende Applaus rührt ihn.

Seither sind einige Tage vergangen und Thomas nimmt mit stolzer Genugtuung die positiven Marktreaktionen nach dem Release der Software zur Kenntnis. Es hat sich gelohnt. Noch immer beschäftigt Thomas das Erlebte sehr: Was kann er hieraus für seine zukünftigen Projekte lernen? Thomas bereitet eine Präsentation vor. Er möchte bei einem Meeting des Senior Managements die Vorgehensweise zur Fortentwicklung der Software grundlegend zur Diskussion stellen. Thomas schlägt vor, kleine interdisziplinär zusammengesetzte Feature-Teams zu bilden, die jeweils in einem Raum zeitlich überdauernd zusammenarbeiten. Immer wieder werden Nutzervertreter eingeladen, mit denen Interviews geführt, Prototypen diskutiert oder lauffähige Software validiert werden. Warum sollte ein Vorgehen, das er im erlebten Ausnahmefall für das effizienteste hielt und das sich dort nachhaltig bewährte, nicht auch sonst erfolgreich sein?

Thomas erkennt verschiedene Vorteile in der cross-funktionalen Zusammenarbeit: Das gesamte Know-how des Teams fließt in das Produktdesign mit ein. Probleme, die ansonsten erst bei der Inbetriebnahme entdeckt würden, können bereits früh offengelegt werden. Hohe Revisionskosten und Fehlinvestitionen lassen sich auf diese Weise vermeiden. Der mit umfassenden Spezifikationsdokumenten verbundene Aufwand kann drastisch reduziert werden. Anforderungen können im Team diskutiert und mögliche Lösungen skizzenhaft illustriert werden. An die Stelle langer Spezifikationsdokumente treten anschauliche Prototypen. Das involvierte Team kann sich mit einem Produktkonzept identifizieren – alle Teammitglieder tragen für den Erfolg des Produktes Verantwortung.

Thomas ist sich darüber im Klaren, dass Teams bei der zielgerichteten Kollaboration umfassender Unterstützung bedürfen. Welche Methoden sind hierfür geeignet? Wie lassen sich Zwischenergebnisse in geeigneten Artefakten festhalten? Thomas möchte seine Erfahrungen in einem abstrahierenden Vorgehensmodell kondensieren.

Bereits während der intensiven Projektarbeit hatte er sich verschiedener Konzepte aus einschlägigen Entwicklungsansätzen wie Design Thinking, Lean UX, Agile Development und menschzentrierten Gestaltungsmodellen bedient. Die Produktkonzeption in cross-funktionalen Teams stand jeweils im Mittelpunkt.

Wir möchten die Geschichte um Thomas an dieser Stelle verlassen und unseren Lesern reinen Wein einschenken: Thomas haben wir uns nur ausgedacht. Um es präzise zu sagen: Wir haben uns den Namen des im Projektmittelpunkt stehenden UX Designers ausgedacht. Das berichtete Projekt aber, dessen Verlauf und dessen Ergebnis trugen sich tatsächlich so zu. Und natürlich gibt es auch den angesprochenen UX Designer, sein Name ist jedoch nicht Thomas (sondern Kevin), er arbeitet als Principle Designer bei einem führenden internationalen Softwarekonzern. Über das Projekt berichtete er in einem eindrucksvollen Vortrag im Juli 2017 auf einer Konferenz in Vancouver – wir saßen im Publikum und wussten sogleich, dass wir eine Einleitung zu unserem Buch gefunden hatten.

Das skizzierte Projekt zeigt, wie wirkungsvoll agil arbeitende, interdisziplinäre UX-Teams sein können. Im vorliegenden Buch beschreiben wir ein Vorgehensmodell auf der Basis von sieben Workshops: Sie orchestrieren die Aktivitäten eines interdisziplinären Teams bei der kollaborativen Produktkonzeption. Das methodische Vorgehen ist durch unsere Praxiserfahrungen geprägt, seine theoretischen Eckpfeiler gründen auf Ansätzen des Design Thinking, Lean UX, Agile Development und menschzentrierten Gestaltungsmodellen. Wir haben Workshops in den Mittelpunkt gestellt, weil sie sich in unserer Praxis nachhaltig bewährt haben – sie erlauben eine anschauliche Anleitung der Prozessschritte und bieten die Möglichkeit einer flexiblen Projektplanung je nach Verfügbarkeit von Teammitgliedern.

Durch die sieben Workshops führen wir unsere Leser in diesem Buch anhand einer Geschichte, eines Fallbeispiels, das den roten Faden durch die Kapitel bildet. Wir erzählen die Geschichte eines interdisziplinären Teams und dessen kollaborativer Erarbeitung eines UX Designs für das neue Release einer umfassenden Applikation. Aber auch wenn diese Geschichte unserer Fantasie entsprang, so basiert sie doch auf Anforderungen und Erkenntnissen, wie wir sie in einer Vielzahl von Workshops und Projekten mit Teams ganz unterschiedlicher Unternehmen gewinnen konnten.

DAS FALLBEISPIEL

Tim, ein erfahrener UX Designer, steht im Zentrum des Fallbeispiels. Die Geschichte beginnt mit der Bitte an Tim, das nächste Release des Produktes »4Service« als UX Designer zu begleiten. 4Service ist eine webbasierte Anwendung, die von Dienstleistungsunternehmen wie größeren Anwaltspraxen, Beratungsunternehmen, Agenturen oder auch Softwareunternehmen eingesetzt wird. Zum Funktionsumfang von 4Service gehören eine Kundenverwaltung, eine Projektverwaltung, eine Leistungserfassung, eine Finanzverwaltung und ein HR-Modul. 4Service ist eine Anwendung des Unternehmens »4Service AG« und wird von mehr als 8.000 Kunden in 91 Ländern eingesetzt.

Tim wurde von seiner Auftraggeberin bereits im Vorfeld darüber informiert, dass sich das neue Release von 4Service vor allem durch ein optimiertes Modul zur Leistungserfassung auszeichnen soll. Fast alle Mitarbeiter der Kunden von 4Service nutzen die Leistungserfassung, allerdings gab es gerade zu diesem Modul verschiedentlich Beschwerden. Eine Verbesserung der Usability der Leistungserfassung wird daher als besonders bedeutsam für den weiteren Markterfolg von 4Service eingeschätzt.

In der Leistungserfassung von 4Service dokumentieren Mitarbeiter eines Dienstleistungsunternehmens ihre Arbeitszeit für ein bestimmtes Projekt. Eine Anwaltskanzlei kann so am Monatsende einem Klienten die Arbeitszeit in Rechnung stellen, die die mit dem Fall betrauten Anwälte aufgewandt haben.

Eine typische Nutzungssituation sieht dabei so aus, dass eine Anwältin in dem Modul einträgt, wie lange sie an einem bestimmten Tag an dem Fall eines Klienten gearbeitet hat und welches ihre Arbeitsinhalte waren. Manchmal wird sie mit einer Kollegin oder einem Kollegen eine Sitzung über den Fall einberufen haben, um diesen gemeinsam zu erörtern. Der beauftragende Klient darf dann natürlich erwarten, dass die protokollierten Zeiten, die die beteiligten Anwälte in der gemeinsamen Sitzung verbrachten, auch gleich sind.

Tim, der Protagonist im Zentrum der Fallstudie, ist 47 Jahre alt. Er ist seit über 20 Jahren im Umfeld von User-Experience-Design-Projekten tätig. Tim hat in den letzten Jahren bereits menschzentrierte Entwicklungsprojekte umgesetzt, bei denen er aktuelle Methoden wie Design Thinking, Lean UX und Agile UX ausprobierte. In unserem Fallbeispiel ist Tim gleich in zwei Rollen involviert: zum einen als UX Designer, zum anderen als Mentor für ein Team, das er mit dem Ziel leitet, die Leistungserfassung zu optimieren. Damit Tim das Projekt erfolgreich für die 4Service AG meistern kann, durfte Tim ein interdisziplinäres Team zusammenstellen, dessen Mitglieder diese Herausforderung annehmen. Mit ihm besteht das Team aus den in Abbildung 1 gezeigten sechs Mitgliedern. Ausgewählt hat er die Produktmanagerin Daniela, die Projektleiterin Andrea, den Entwicklungsleiter Peter, den Frontend Engineer Tom und die Testleiterin Sarah – ein tatsächlich cross-funktionales Team, in dem er alle für das Projekt relevanten Rollen vertreten sieht.

Daniela ist 42 Jahre alt und arbeitete lange als Beraterin für die Konfiguration und Adaptierung der Software. Nach verschiedenen Tätigkeiten als Projektleiterin wurde sie schließlich Produktmanagerin für 4Service. Daniela ist neu in dieser Rolle und benötigt daher noch etwas Unterstützung durch das Team.