Agile UX: Fallbeispiel von Thomas Cook

UX KONFERENZ | 23. OKTOBER | BERLIN
AGILE PROZESSE UND UX
OLGA KOSTENCHUK, SENIOR USER EXPERIENCE MANAGER

Was hat Skifahren mit Agile zu tun?

OLGA KOSTENCHUK, SENIOR USER EXPERIENCE MANAGER, 23.10.2018 - BERLIN

Agile Manifesto, 2001

Herausforderungen für UX-Designer
Nach Sprints
arbeiten?
Nutzerfreundliches
Design
in 2 Wochen?
Zu welchem Team
gehöre ich?
Seite 5

Ganz kurz Olga Kostenchuk

Olga Kostenchuk
OLGA KOSTENCHUK, SENIOR USER EXPERIENCE MANAGER, 23.10.2018 - BERLIN Seite 7

Ganz kurz Digital Commerce von
Thomas Cook Central Europe (CE)

Unsere Webseiten in Thomas Cook CE
Neckermann-reisen.de
Thomascook.de
Oeger.de Urlaub.de
Neckermann-Urlaubswelt.de Bucher-Reisen.de
Seite 9

Unsere Webseiten

Case Study Projekt „Golden Gate“

Ziele von Web-Platform „Golden Gate”:
› Soll als technische Basis für alle CE-
Websites dienen können („White Label“)
› Optimierte User-Experience und Design
› Responsives Design
› Erlaubt eine optimierte Darstellung des
eigenen Produkts
› Omnichannel: Soll auch lange geforderte
Funktionen für den stationären Vertrieb
bieten („Im Reisebüro buchen“)
› Wesentlich bessere Conversion Rate
als die alte Plattform
Page 12

Entwicklung mit agiler Methodik nach Scrum

Scrum-Meetings
› Estimation Meeting
(Schätzung von Tickets )
› Sprint Planning
› Daily Scrum Meeting
› „Show & Tell“ (Review)
› Sprint Retrospektive
Seite 14

Livegänge und Phasen in den letzten 3 Jahren
Feb
Phase 1
Apr Jun
Phase 2 Phase 3 Phase 4
Nov Sept
Start Projekt „Golden Gate“
Mai Juli2016 2017 2018
Ckneckermann.cz
2015 Mai
Urlaub.de und Neckermann-Urlaubswelt.de
Oeger.de
Neckermann-Reisen.ch
Neckermann-Reisen.at
ThomasCook.de und Neckermann-Reisen.de
2019
Neckermann.hu
?
Seite 15
Bucher-Reisen.de
Neckermann.pl
Sept

Integration von UX & Design in die
agilen Prozesse
Phase 1: Sprint Null

Phase 1: Sprint Null
› Projektphase (Sprint Null)
› Keine Releases
› Aufbau der Arbeits-Umgebung
› Entwicklung von
Lösungsansätzen
› Recherche der
Nutzerbedürfnisse
› Erstes UX & Design
Seite 17

Phase 1: Recherche der Nutzerbedürfnisse
„Die Seite
wirkt farblos“
„Filtern nach
Flugzeiten ist
nicht möglich"
„Die Abkürzungen
der Zimmertypen
sind nicht
ausreichend erklärt"
„Das Bild ist nicht
ansprechend:
Urlauber liegen am
Strand wie „Sardinen
in der Dose“
„Die Website lädt
zu langsam und
bricht ständig
ab“
Seite 18

Phase 1: Erste Entwürfe

Phase 1: Team-Struktur
432
› Anfang: UX und Design separat, nicht als Team
› Entwickler und QA ziehen in einen Projektraum
ein
Könnte besser laufen:
› Geringe Priorisierung: wer (POs, Devs) am
lautesten schreit, kommt als Erstes dran
› Räumliche Trennung
› Wenig Kommunikation
1
Design
QA
DEV
PM
UX
Seite 20

agilen Prozesse
Phase 2: Ein Scrum-Team und ein Sprint

› Alle Gewerke sitzen in einem
Projektraum
› UX & Design – Teil des Scrum-
Teams
› 1 Sprint = 4 Wochen
› UXD + Dev = 1 Sprint
› Konzipieren & Designen, was
Entwickler brauchen
Seite 22

1
Design
QA
DEV
PM
43
Gut
› Ein Scrum-Team
› Scrum-Master
› Teilnahme an Scrum-Meetings
Könnte besser sein:
› Alle in einem Sprint schwierig, da
Entwickler auf UX und Design warten
(Bottleneck)
› Entwickler-Feedback zu Konzepten zu
spät (erst im Estimation-Meeting)
2
Design
QADEV
Scrum-
Master
PM
UX
UX
Seite 23

Phase 2: Erste Webseiten gehen “live” (Ende 2015)

agilen Prozesse
Phase 3: UX & Design vorgelagert

› UX & Design ein Sprint vor
Entwicklung
› Sprint kürzer:
• 4 > 2 Wochen
• flexibel für politische
Themen
• 2 Wochen für UXD und 2
Wochen für Entwicklung
Seite 26

UX
UX
432
1
Design
QA
DEV
PM
Design
QADEV
Scrum-
Master
PM
UX QADEV
Scrum-
Master
PM
DesignUX
Gut:
› Bottleneck gelöst, da UXD vor Entwicklung
› Bessere Kommunikation (Entwickler werden
in die Konzeption einbezogen)
Könnte besser sein:
› Sehr enge Planung von UXD-Stunden (“Du
darfst nicht mehr als 8 Stunden ins Design
investieren”)
› Sehr strikte Prozesse (unbedingt Wireframes
& unbedingt Designs für jedes Ticket)
› Zu viele Meetings, zu große Runden
› Mehr Wasserfall, Entfernung von Scrum:
 zu viele Entwickler in einem Team
 keine definierten Rollen von PO
Seite 27

› Immer mehr Komplexität
› Mehr Webs durch Migration
› Mehr Entwickler
› Immer noch 1 UX und
1 Designer
Seite 28

Integration von UX & Design in die agilen
Prozesse
Phase 4: UXD als Service-Unit

› 2 Scrum-Teams für Entwickler
gebildet
› Frage 1: Sollen UX & Design in
die Teams hinein oder bilden sie
ein eigenes Team?
› Frage 2: Gehört UXD eher
Richtung Fachlichkeit und
Business-Seite oder eher
Entwicklungs-Seite?
› Service-Unit für beide Seiten:
PO und Entwicklung
Seite 30
A
B
H,I
A
B
H,I
C
D E
F G
H
I K
L M

432
QADEV
Scrum-
Master
PM
DesignUX
Design
DEV QA DEV QA
Scrum-
Master
PO
PM
PM PM
UXDesign
QADEV
Scrum-
Master
PM
UX
1
Design
QA
DEV
PM
UX
Seite 31

› Mehr Flexibilität für neue Themen
› UXD als Schnittstelle zwischen Entwickler und
PO
› UXD immer noch vor Entwicklung, aber nicht
mehr so eng
› Enge Zusammenarbeit mit PO (Planning für
UXD wöchentlich)
› Mehr Zeit für UXD, da keine Teilnahme an
Scrum-Dailys und anderen Meetings
Läuft gut
› Wir brauchen ein Retro für UXD >> eingeführt
› Weniger Überblick über Entwickler-Themen
>> Teilnahme an Show&Tell der Entwickler
› POs benötigen eine Schätzung von UXD-Tickets
>> T-Shirt-Größen eingeführt (6h = S, 12h = M,
20h = L)
› UXD-Backlog muss aktuell bleiben
Könnte besser sein

UXD-Prozess heute

UXD-Prozess heute: Kanban
› Kanban als agile Methode für
UXD (der Sprint endet nie)
› Neben dem Dev.-Projekt in
Jira ein separates Projekt für
UXD
› Eigenes Backlog für UXD
› Backlog durch PO priorisiert
› Backlog wird mit UXD
wöchentlich abgestimmt
› Tickets werden nachgezogen,
sobald Luft ist
› UXD entscheidet, welche
Themen gebündelt werden
Seite 35

UXD-Prozess heute: Kanban
› UXD-Input wird im Dev.-Ticket
zusammengefasst
› Finale Abnahme und Kommunikation
findet im Dev.-Projekt statt
› Flexibilität: Designs und Wireframes
nicht für alle Tickets (mehr
Pragmatismus)
› Finale Themen kommen in einen
Pool mit fertigen Tickets, die durch
PO an die Entwickler verteilt werden
› Dokumentation von UX-Recherche,
Design-Varianten, Abstimmungen
usw. separat von Dev.-Projekt
Seite 36

Fazit

Ausblick in die Zukunft
Ausblick in die Zukunft
› Geschwindigkeit (Velocity)
messen:
Wie lange dauert es, bis ein
Ticket umgesetzt ist
Welche Tickets laufen gut
und welcher langsamer
(„Bottleneck“) und warum?
› „Just in time“-Prinzip: Tickets
nah am Dev.-Sprint
bearbeiten

Fazit
Fazit
› Agilität = Prozesse ausprobieren und
experimentieren
› Fehler können passieren und sind Teil
der Evolution
› Rückendeckung vom Management
› Integration von UXD ist von 2 Faktoren
abhängig:
Wie ist das Verhältnis: Anzahl von
Scrum-Teams zur Anzahl von UX-
Designern?
Soll UXD eher dem Produkt-
Management oder eher der
Entwicklung zuarbeiten?

Fazit
Fazit
› Es muss nicht Scrum sein
› Konzepte werden gemeinsam
im Entwicklungsteam
erarbeitet
› Umdenken für UX-Designer:
Minimum Viable Product –
so früh wie möglich lauffähige
Anwendungen/Seiten
produzieren
Das erste Design muss nicht
perfekt sein

„Misserfolg ist lediglich eine
Gelegenheit…“

„… mit neuen Ansichten noch
einmal anzufangen“
Henry Ford

Fragen?
Vielen Dank für die
Aufmerksamkeit!
Kontakt
Olga Kostenchuk
Senior User Experience Manager
Tel.: + 49 6171 65-3598
E-Mail: olga.kostenchuk@thomascook.de
LinkedIn: www.linkedin.com/in/olga-kostenchuk

Agile UX: Fallbeispiel von Thomas Cook

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Agile UX: Fallbeispiel von Thomas Cook

Ähnlich wie Agile UX: Fallbeispiel von Thomas Cook (20)

Agile UX: Fallbeispiel von Thomas Cook