Konfiguration-UIs für Marketingkampagnen
Kunde: PAYBACK
🎯 Problem
PAYBACK ist ein Treue-Programm, bei dem Endkund*innen mit ihren Einkäufen bei vielen Partnern und Shops Punkte sammeln können, mit dem Ziel Kundenbindung und Loyalty zu stärken. In einem Programm mit Thoughtworks wurden neue Produktteams besetzt, die alte Legacy-Systeme ablösen und den Umzug in die Cloud bewerkstelligen sollten. In diesem Rahmen wurde ein neues Marketingprodukt entwickelt, die “Challenges”, bei denen Endkund*innen in der App begehrte Coupons freischalten können, indem sie für einen bestimmten Beitrag einkaufen oder mit mehreren Einkäufen eine Stempelkarte ausfüllen. Ein weiteres Produkt waren sogenannte “Frequency Campaigns”, bei denen das Einlösen eines Coupons weitere freischaltet. Diese Produkte waren attraktiv für die B2B-Partner von PAYBACK, die dadurch mehr Möglichkeit hatten, Incentives für ihre Kund*innen zu setzen.
Die Aufgabe meines Teams bestand darin, diese Mechanismen sinnvoll in interne Tools umzuwandeln, mit denen auch komplexe Kampagnenkonfigurationen möglich sind und damit den unterschiedlichen Anforderungen der Partner gerecht zu werden.
👩🏻💻 Rolle
Ich arbeitete anderthalb Jahre als (Senior) Consultant Experience Designer in diesem Team. Anders als bei anderen Projekten wurden in dieser Zeit die Produkte stets weiterentwickelt (aufgrund der Fülle kann in diesem Portfolio-Case nicht auf alle Details eingegangen werden). Besetzt war das große Team u.a. mit einem Product Owner (PO, Kunde), Business Owner (BO, Kunde), Tech Lead (TL), einer Business Analystin (BA), Quality Analyst*innen (QA), vielen Fullstack-Developer*innen (Dev, Kunde + Thoughtworks).
Meine Verantwortung: Als Solo-Designerin war ich zuständig für alle designverwandten Aufgaben, ich war Ansprechperson, und kümmerte mich um den kompletten Designprozess, inkl. Research, Ideation, UX Design, UI Design, Testing.
⚡ Prozess
Das ganze Produktteam folgte einem klassischen agilen Software-Delivery-Prozess, bei dem wir mit einem Kanban-Board arbeiteten, mit Epics und Stories. Dazu gehörten Zeremonien wie Stand-Up, Sprint Planning, Refinement, Retrospektiven, etc.
Der Designprozess folgte ebenso einem klassischen Schema:
- Research / DiscoveryVorschlag eines neuen Features, aus dem Backlog oder vorgegeben aus Business-Sicht (z.B. Partner-Anforderung); Priorisierung der Features
- AnalyseAnalyse der Requirements mit BA/PO/BO, Sammeln der Use Cases und Szenarien
- Erstes Konzept Entwurf und Visualisierung, Prototyping, Machbarkeit und Komplexität mit Devs checken
- User Testing
- Iteration Anpassung der Designs, basierend auf Erkenntnissen
- DesignDesign verfeinern, Komponenten bauen, existierende oder zusammenhängende Designs updaten, Definition von exakten Specs und Zuständen
- Story schreiben User Story fürs Development schreiben, in Abstimmung mit BA/PO/TL/QA, Feedback und Input erhalten und einarbeiten
- Implementierung der Story begleitenProaktiv Ansprechpartnerin sein, einchecken bei Devs; später auch eigenes Testing und Abnahme
Besonders essentiell war die enge Zusammenarbeit im Team, und ich musste mich manchmal behaupten, um im Delivery-Prozess die Relevanz von nutzer*innenzentrierten Design und Research herauszustellen.
Die primäre Usergruppe sind Kampagnenmanager*innen, die bei PAYBACK arbeiten. Jedes Land hat ein oder mehrere dieser Kampagnenmanager*innen, die intensiv mit den Partnern kollaborieren und deren spezifische Bedürfnisse kennen. Sie brauchen ein internes Tool, mit dem sich verschiedene Kampagnenarten konfigurieren lassen.
Challenges: Dieses Produkt basiert auf vielen Details und Einstellungen in Form eines Formulars mit Freitextfeldern, Dropdowns und anderen Selektionsmöglichkeiten. Die Hauptschwierigkeit bestand darin, die wachsenden Features sinnvoll zu integrieren und die User*innen mithilfe von progressive disclosure nicht zu überfordern. Challenges haben auch eine Verbindung zum mobilen Interface in der PAYBACK-App, wo Endkund*innen ihren Fortschritt verfolgen können. Hinsichtlich des Designs blieben die Challenges jedoch ein simples Produkt, da es letztendlich doch vor allem ein Formular war.
Frequency Campaign: Dieses Kampagnentool besitzt keine mobile Repräsentation für Endkund*innen. Die Grundlogik ist, dass mit jedem Nutzen der Coupons ein noch wertvollerer ausgespielt wird, um auch hier die Häufigkeit eines Einkaufs zu erhöhen. Daher basiert das Produkt auf einer Verkettung von Coupons. Neben der grundlegenden bzw. linearen Verkettung von Coupons, z.B. 5fach Coupon
🏔️ Herausforderungen
Relevanz von UX und Usability:
Obwohl ich viele Ideen hatte, die die UX und Usability hätten verbessern können, wurden diese Vorschläge aufgrund des Workloads und anderer Stories nicht priorisiert. Argumente waren, dass die User*innengruppe in Zukunft sehr überschaubar bleiben wird (20-30 Personen), und es sich “sowieso nur” um ein internes Produkt handelt (Stichwort: captive users). Wenn die Verbesserungen notwendig gewesen wären, hätte ich auch für sie gekämpft, jedoch konnte ich deren geringe Relevanz im Gesamtkontext ebenso nachvollziehen. Es wurde mir klar, dass das Projekt insgesamt sehr fokussiert war auf Backend-Funktionalitäten und die komplexe Infrastruktur.
Geringer Einfluss über das Produkt hinaus:
Zwar hatten wir im Team die Kontrolle über das Produkt und wie wir es bauten, jedoch gab es wenige Überschneidungspunkte darüber hinaus. Beispielsweise gab es ein ganz anderes Department, das sich um die mobile App kümmerte. Auch als Designerin fühlte es sich relativ begrenzt an, das Produkt nur als solches zu betrachten und nicht als Teil eines ganzen Services, inkl. anderer Stakeholder. Die Features wurden oft von Business oder Partnern diktiert, sodass man sich eher im Delivery- als jemals tatsächlich im Discovery-Modus befunden hat. An der Stelle sollte man sich auch seines eigenen (limitierten) Einflusses als externer Consultant bewusst werden.
Aufgrund dieser Limitierungen fokussierte ich mich eher auf das Team selbst und wie Design angegangen wird. Nach dem Motto “Design as a team” folgte ich der Prämisse, dass Designerfolge im besten Fall in Kollaboration entstehen und jede*r hilfreiche Designideen hat. Dieser Ko-Kreationsprozess lädt das Team ein, kreativ zu sein und bietet Raum für Austausch. Dabei behalte ich immer noch die Verantwortung für das Design selbst. In dem Zuge veranstaltete ich Workshops wie Design Ideation Workshops, bei denen wir die Funktionsweise des Frequency Campaign Produkts erörterten und imaginierten, oder auch eine Design Critique Session, wo Feedback und Alternativen zu einem Designvorschlag gesammelt wurden. Ich führte Design Hours ein, ein Meeting, wo wir dediziert über Design redeten und reservierte immer einen Platz für Developer in User Testings. Durch diese Maßnahmen konnte ich Teammitglieder häufiger involvieren und mehr Berührungspunkte mit dem Thema Design schaffen.
🏆 Ergebnisse
Übersichtsseite Challenges
Von User*innen gab es Feedback, dass unser Produkt intuitiv zu bedienen wäre (Frequency Campaigns), dass es einfach zu handhaben und zu verstehen ist. Andere Erfolge waren eher technisch, z.B. der technische Erfolg der Kampagnen, korrekte Daten und wenige Bugs.
Hinsichtlich von “Design as a team” erhielt ich positives Feedback, wie in einem Workshop:
💡 Learnings
Über den Projektzeitraum der anderthalb Jahre sind mehrere Learnings zusammengekommen, z.B. dass die Relevanz von Design nicht immer selbstverständlich ist im ganzen Team, und ich einfordern kann, als Designerin mehr involviert zu sein. Es hilft auch früh und bestimmend nach Zugriff auf User*innen fragen und Beziehungen zu ihnen aufbauen. Auch wenn Design depriorisiert wird, gibt es Wege, z.B. mit dem Team gemeinsam in einem Design-Mindset zu arbeiten und mehr Awareness zu schaffen. Es war insgesamt sehr interessant, Teil eines großen Teams zu sein und ein wachsendes Produkt zu begleiten und stets zu optimieren.