Collaborative UX Design (eBook)

Lean UX und Design Thinking: Teambasierte Entwicklung menschzentrierter Produkte

Toni Steimle, Dieter Wallach (Autoren)

eBook Download: EPUB

2022 | 2. Auflage
239 Seiten
dpunkt (Verlag)
978-3-96910-805-5 (ISBN)

Infos

UX Design im Fokus der Produktentwicklung

• sehr systematisches Vorgehen
• leicht verständlicher Zugang zu hilfreichen in der Praxis anwendbaren UX-Methoden
• illustriert mit einem durchgehenden Praxisprojekt, in dem der Leser Tim, einen erfahrenen UX Designer, kennenlernt

Software wird zunehmend in cross-funktionalen Teams konzipiert. Die einzelnen Mitglieder eines zeitlich überdauernd zusammenarbeitenden Teams bringen Expertise aus verschiedenen Bereichen in gemeinsame Workshops zur Produktgestaltung ein.
Die Autoren vermitteln dem Leser kompakt und leicht verständlich ein fundiertes Grundwissen zu kollaborativen Methoden des UX Designs. Sie beschreiben die Auswahl und den Einsatz von disziplinübergreifenden UX-Methoden und illustrieren deren Verzahnung in einem auf Workshops basierenden Vorgehensmodell. Der dargestellte kollaborative Ansatz ist in menschzentrierten Entwicklungsmodellen, Design Thinking und Lean UX verwurzelt und stellt ein agiles, hypothesenbasiertes Vorgehen in den Vordergrund. Die fachliche Darstellung wird anhand eines durchgehenden Praxisprojektes illustriert.
Auf einer das Buch begleitenden Website findet der Leser Vorlagen zur Anwendung der im Buch angesprochenen Methoden sowie ein Glossar. Die 2. Auflage wurde durchgehend aktualisiert und erweitert.

Toni Steimle ist Ökonom und leitet mit der Ergosign Switzerland AG einen führenden UX-Design-Dienstleister. Er lehrt an der Hochschule Rapperswil, an der Hochschule Olten und der Universität Basel rund um Themen des User Experience Design. Seine Arbeitsschwerpunkte sind Vorgehensmodelle der Softwareentwicklung, User-Experience-Strategien, Kreativität und digitale Märkte. Dieter Wallach ist promovierter Kognitionswissenschaftler und prägte als UX-Pionier und Hochschullehrer die deutschsprachige User-Experience-Szene mit. Er ist Gründer und Co-Geschäftsführer der Ergosign GmbH. Er erhielt Rufe an die Universität Würzburg und an die Hochschulen Heilbronn, Trier und Kaiserslautern. Dieter Wallach forscht und lehrt als Professor für Human-Computer Interaction und Usability Engineering im Fachbereich Informatik und Mikrosystemtechnik an der Hochschule Kaiserslautern.

Textauszug

WORKSHOP: SCOPING

Im Scoping-Workshop konkretisieren wir die mit einem Vorhaben verbundenen Ziele und Randbedingungen. Wir definieren, welche (quantitativen) Metriken zur Messung des Erfolgs der bevorstehenden Projektarbeit geeignet sind. Gemeinsam mit dem Projektteam und der Auftraggeberin wollen wir die hinter einem Vorhaben liegenden Annahmen aufdecken und hierbei kritische Annahmen identifizieren.

ÜBERBLICK

Der Scoping-Workshop ist der erste in einer Reihe von acht Workshop-Schritten unseres Vorgehensmodells: Er markiert den Beginn der Verstehen-Phase des Entwicklungsprozesses. Ziel eines Scoping-Workshops ist es, einen Projektauftrag möglichst umfassend zu verstehen, die Messung des Projekterfolgs zu operationalisieren und herauszufinden, auf welchen Annahmen anvisierte Projektziele basieren.

Ein präzises Verständnis des Projektauftrags ist von entscheidender Bedeutung für dessen zielorientierte Bearbeitung. Allzu oft wird dieser Schritt als trivial angesehen und daher leichtfertig übersprungen. In einer Vielzahl von Projekten konnten wir lernen, wie wichtig die umfassende Klärung des Projektauftrags ist: Gemeinsam mit der Auftraggeberin schärfen wir im Scoping-Workshop den Blick auf die vorliegende Problemstellung.

Im späteren Research-Workshop werden wir Methoden auswählen, mit denen wir die Belastbarkeit der identifizierten Annahmen empirisch prüfen können. Im Synthese-Workshop führen wir anschließend die erhaltenen Ergebnisse zusammen und können auf der so konsolidierten Grundlage Inhalt und Formulierung des Projektauftrags ergänzen und – sofern notwendig – anpassen.

Der Scoping-Workshop verläuft typischerweise in zwei Phasen. In der ersten Phase arbeiten wir den eigentlichen Projektauftrag heraus. In der zweiten Phase identifizieren wir dann die Annahmen, die dem gewonnenen Verständnis des Projektauftrags zugrunde liegen.

Bei kleinen Projekten dauert ein Scoping-Workshop oft lediglich einen halben Tag. Bei sehr ambitionierten Projektvorhaben kann es hingegen lohnenswert sein, den Scoping-Workshop aufzutrennen und entsprechend mehr Zeit zu reservieren: Der erste Teil des Scoping-Workshops kann dann beispielsweise Kick-off-, der zweite Annahmen-Workshop genannt werden.

Begleiten wir nun den Scoping-Workshop in unserem Fallbeispiel zur Leistungserfassung bei 4Service.

Ziel

• › Klärung des Projektauftrags

Teilnehmende

• › Projektteam, Auftraggeberin

Hauptergebnisse

• › Problem Statement Map, Proto-Personas

Ablauf

• › Proto-Problem Statement Map erstellen
• › Proto-Personas formulieren
• › Proto-Journey formulieren
• › Annahmen priorisieren

PROTO-PROBLEM STATEMENT MAP

Im Scoping-Workshop erarbeiten wir erste Ergebnisse und dokumentieren diese in Form modellierter Artefakte, die wir häufig als – physische oder digitale – Maps konkretisieren. Maps sind zweidimensionale, aus einzelnen Karten bestehende Strukturen, die sich leicht arrangieren und verändern lassen. Um zu verdeutlichen, dass es sich an dieser frühen Stelle im Projektverlauf noch um vorläufige, nicht validierte Ergebnisse handelt, stellen wir diesen Modellen oder UX-Artefakten den Terminus »Proto« voran, der im Lateinischen »erstmalig« oder »frühest« bedeutet.

Starten wir nun mit dem Scoping-Workshop: Tim hat das Produktmanagement von 4Service eingeladen. Er weiß, wie wichtig ein guter Verlauf des ersten Workshops für die weitere Projektarbeit und damit für den Gesamterfolg eines Projekts ist. Damit sein Team über eine solide Ausgangslage verfügt und alle Mitarbeitenden die mit dem neuen Release von 4Service verbundenen Projektziele umfassend nachvollziehen können, möchte Tim die Erwartungen und Annahmen der Auftraggeberin möglichst detailliert verstehen.

Nachdem alle Beteiligten im Raum Platz genommen haben, bittet Tim die Anwesenden um eine kurze Vorstellungsrunde: Er will die beteiligten Personen und ihre Rollen als Stakeholder bekannt machen.

Stakeholder:

Stakeholder sind Anspruchsgruppen, die von einer Lösung direkt oder indirekt betroffen sind. Oft haben sie auch ein unmittelbares Interesse an der Lösung.

Die im Workshop zur Verfügung stehende Zeit soll möglichst produktiv genutzt werden: Tim öffnet seinen Moderationskoffer und beginnt damit, Karten an eine vorbereitete Pinnwand zu hängen. Er verwendet zunächst blaue Karten und ordnet sie horizontal in einer Reihe an (Abbildung 4). Mit Überschriften auf den Karten gibt Tim die Struktur eines Proto-Problem Statement vor, das er nun erarbeiten möchte. Eine erste Map entsteht.

Abbildung 4:
Struktur eines Problem Statement

Die erste Karte beschriftet Tim mit »Nutzende«. Er fragt die Anwesenden: »Zwischen welchen Nutzergruppen sollten wir unterscheiden? Welche Nutzergruppen haben unterschiedliche Anforderungen an die Leistungserfassung?« Tim erhält auf seine Frage eine Reihe von Antworten – nicht alle davon weisen jedoch in die gleiche Richtung: Es finden sich durchaus widersprüchliche Meinungen.

Problem Statement:

Ein Problem Statement beschreibt die zu bearbeitende Fragestellung. Das Statement definiert, welches Problem konkret zu überwinden ist, wer von dem Problem und dessen Lösung betroffen ist und welche Randbedingungen dabei zu berücksichtigen sind. Im Scoping-Workshop sprechen wir bewusst noch von Proto-Problem Statement, um die Unsicherheit der darin zusammengefassten Annahmen auszudrücken. Im Verlauf der Verstehen-Phase wird das Bild des Problem Statement zunehmend geschärft und gegebenenfalls in Teilen auch revidiert.

In einem ersten Versuch zur Segmentierung der Nutzenden von 4Service arbeiten die Teilnehmenden schließlich vier unterschiedliche Nutzergruppen heraus. Diese sind:

• › Projektleitung
• › Teamleitung
• › Personalleitung
• › Mitarbeitende

Tim hält die Wortmeldungen auf Karten fest und ordnet sie in der Spalte »Nutzende« an: Eine Tabelle entsteht (Abbildung 5).

Abbildung 5:
Problem Statement mit der ausgefüllten Spalte »Nutzende«

Als Nächstes fragt Tim: »Welche Probleme möchten wir für die direkten User von 4Service mit Blick auf die Zeiterfassung lösen?« Die Teilnehmenden des Workshops vermuten, dass es viele Reklamationen wegen falscher Rechnungen geben wird. Zum Beispiel dann, wenn eine Anwaltskanzlei, als Kunde von 4Service, für zwei Anwälte, die sich in einer gemeinsamen Sitzung beraten haben, unterschiedliche Zeitaufwände in Rechnung stellt.

Ein weiteres Problem resultiert für Kunden, wenn Arbeiten für einen Klienten zwar ausgeführt, jedoch nicht abgerechnet werden: Der Kanzlei oder einem Unternehmen entstehen Aufwände, denen keine Einnahmen gegenüberstehen. Für dieses Problem lassen sich unterschiedliche Ursachen annehmen: Eine regelmäßige Zeiterfassung könnte für Nutzende zu aufwendig und ineffizient sein und daher vielleicht erst gesammelt am Monatsende durchgeführt werden. Kleinere Arbeiten für einen Klienten »zwischendurch« geraten dann schon mal in Vergessenheit. Da die 4Service AG keine Smartphone-App zur Nutzung von 4Service anbietet, ist eine mobile Erfassung von Arbeitszeiten nicht möglich. Personen, die eine Leistung außerhalb des Büros erbringen, müssen sich die angefallenen Aufwände daher merken oder notieren, bis sie wieder Zugriff auf 4Service haben.

Tim moderiert die Diskussionsrunde zu möglichen Ursachen für ausbleibende Zeiterfassungen, hinterfragt die ausgetauschten Aussagen der Vertreterinnen des Produktmanagements und hält resultierende Erkenntnisse auf Karten fest – sukzessive werden die Spalten des Proto-Problem Statement gefüllt (Abbildung 6).

Abbildung 6:
Erste Übersicht von zu lösenden Problemen

Die sorgfältige Unterscheidung zwischen Problemen und Ansätzen zu ihrer Lösung ist hilfreich: Wir richten den Fokus zunächst auf das Verständnis der Ausgangslage und die Zielsetzungen eines Projekts.

Tim möchte wissen, ob es unter den Teilnehmenden aus dem Produktmanagement bereits Ideen zu möglichen Lösungsansätzen gibt. Tim weiß, dass es wichtig ist, bestehende Ideen der Auftraggeberin in Erfahrung zu bringen: Zum einen gelingt hierdurch der Einbezug dieser Stakeholder leichter – zum anderen sollen bereits vorliegende Lösungsideen nicht unberücksichtigt gelassen werden. Vorhandene Lösungsideen zu kennen, ist auch deswegen bedeutsam, weil wir dann die dahinter verborgenen Annahmen hinterfragen können.

Mit der...

Produkt-Details

• Erscheint lt. Verlag: 7.12.2022
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Agile • design thinking • Human-Computer interaction • kollaboratives Design • Lean UX • Menschzentrierte Softwareentwicklung • Produktentwicklung • Usability Engineering • User Experience Design • UX Design
• ISBN-10: 3-96910-805-5 / 3969108055
• ISBN-13: 978-3-96910-805-5 / 9783969108055