Stattdessen möchte ich erzählen, was passieren kann, wenn man eine gute Idee, Neugier, Vertrauen, eine gesunde Fehlerkultur und ein motiviertes Team in einen Topf wirft – am Beispiel eines konkreten Projektes. Nicht als Business-Evangelist, Top-Level-Manager oder Fachtheoretiker mit erhobenem Zeigefinger, sondern als operativer Digital-Aficionado, der als Ray Sono UX-Berater schon in so manch agilem Projekt mitmischen durfte und am liebsten gar nicht mehr anders arbeiten möchte. Und ich verrate, was ich ganz konkret gelernt habe – und wie euch das auch helfen könnte.
Das Projekt
Es geht um nichts weniger als eine Web-App, die das Autofahrverhalten ihrer Nutzer auf den Kopf stellen will: den eMobility Coach von E.ON. Auf Dänisch Elbilguiden, denn für den dänischen Markt wurde die Web Application als Erstes entwickelt.
Die Web-App zeigt jedem Nutzer, wie sich ein Umstieg auf Elektromobilität auf seinen Alltag, seine Finanzen und auf die Umwelt auswirkt – mit konkreten, herstellerunabhängigen Fahrzeug- und Handlungsempfehlungen. Dazu das Angebot, für ihn eine kostenlose und unverbindliche Probefahrt in einem Fahrzeug seiner Wahl zu arrangieren.
Das Briefing: ein Traum! Es bestand aus einer Idee, der Vision dahinter, einem ersten Scribble sowie ein paar relevanten Insights. Der Auftrag so unmissverständlich wie motivierend:
Lasst uns gemeinsam 100 Tage an dieser Idee arbeiten und schauen, was dabei herauskommt!
Beste Voraussetzungen also, wie den Musterbeispielen eines „How to agile“-Leitfadens entnommen. Doch ein guter Start führt nicht immer zum richtigen Ziel. Warum auch die folgenden 100 Tage so brachial effizient, massiv beflügelnd und am Ende auch noch so richtig erfolgreich waren? Hier folgt die Antwort:
5 Dinge, die das Projekt „eMobility Coach“ zum Erfolg geführt haben:
1. Teamwork – jetzt erst recht
Für agiles Arbeiten ist Teamplay DIE Grundvoraussetzung. Weil wirklich alle simultan dran sind und allein deswegen schon jeder wissen muss, was die anderen so machen.
Das gilt gewerke- und unternehmensübergreifend und in alle Richtungen. Hierarchische Auftraggeber-Auftragnehmer-Verhältnisse und Konkurrenzdenken zwischen mehreren Dienstleistern sind der Tod des Projekts. Funktionierendes Teamplay mit allen gebotenen Soft Skills will daher gelernt sein – gibt dann aber auch eine Menge zurück.
2. Gute Ideen entstehen durch Vielfalt
Ich verwende nur ungern den Begriff Innovation. Aber wenn das Teamwork in agilen Prozessen flutscht, entsteht das, was die Propheten des Design Thinking häufiger runterbeten als strenggläubige Katholiken den Rosenkranz: Vielfalt! Vielfalt an Perspektiven, Vielfalt an Ideen. Und auch der Weg dorthin kann – ganz genau – ziemlich vielfältig sein. Denn agile Frameworks sind auch eine prima Spielwiese für die Anwendung methodischer Praktiken. Das ist der Grund dafür, dass jedes Stockfoto zum Thema mit Maps, Canvas und Klebezetteln vollgepflastert ist.
An dieser Stelle ein Eingeständnis: In gemeinsamen Lösungsfindungen habe ich bisher immer deutlich bessere Ergebnisse erzielt, als ich sie mir als Konzeptbeauftragter jemals allein hätte ausdenken können. Zudem schneller und ohne anschließende Präsentation und Diskussion unter Kolleginnen und Auftraggebern. Es waren ja bereits alle involviert! Das macht es nochmals schneller. Win-win-win!
Neben einem Blumenstrauß an Ideen, Optimierungen und Vorschlägen wäre ohne diese Schwarmkreativität in unserem E.ON Projekt nie das nun integrierte mathematische Modell entstanden, welches für die Berechnung der einzelnen Scores herangezogen wird und den Nutzerinnen wirklich relevante Ergebnisse liefert.
3. Wir sind alle UX Designer
Die Spielregeln sind denkbar einfach: Jeder darf seine Ideen in den Ring werfen, jede Meinung ist gleichberechtigt, wir entwickeln das Produkt gemeinsam. Und wir sind gemeinsam dafür verantwortlich, dass es in seiner Gesamtheit funktioniert.
UX ist damit nicht nur Aufgabe des UX-Titelträgers. Aus Sicht des Nutzers (um den es nun mal geht) ist die Erfahrung mit dem Produkt die Summe aus allem, was auch nur im Entferntesten damit zu tun hat: Mehrwert, Usability, Content, Umsetzung, Anknüpfung an andere Touchpoints und, und, und. Dass diese Summe stimmt, muss jeder im Projekt im Blick haben – Product Ownership als kollektives Mindset.
Das heißt nicht, dass es keinen UX-Experten mehr braucht: Detailkonzepte wirklich komplexer Themen, die höchste Konzentration erfordern, wollen dennoch erstellt werden. Aber was die Exploration und Entwicklung grundlegender Interfaces, User Flows und Ideen angeht, gilt das bereits erwähnte Prinzip der Vielfalt.
4. Testing ist keine Option
Testing ist Pflicht! Geht es um knappes Timing oder Budget, steht das Testing gern an erster Stelle der Abschussliste. Lieblingsfrage: „Warum braucht es denn ein Testing? Sie sind doch die Experten!“
Das Problem: Auch wenn wir bereits etablierte Mechaniken anwenden, ist das noch lang keine Garantie, dass diese jedes Produkt zum Erfolg führen. Denn Zielgruppen sind verschieden, die Erwartungen an das Produkt sowieso – und die Uhr tickt: Technischer Fortschritt, steigender Anspruch und die nicht schlafende Konkurrenz drehen kräftig am Rad der Zeit! Darum müssen vorhandene Ansätze immer wieder aufs Neue herausgefordert werden. Neben der Gewissheit, dass man auf dem richtigen Weg ist (oder auch nicht), diktiert die Zielgruppe im Testing meistens zudem noch hilfreiche Optimierungsvorschläge direkt ins Backlog.
Innerhalb der 100 Tage haben wir den eMobility Coach gleich dreimal ins Testing gegeben:
Es gab bei wirklich jedem Entwicklungsstand wertvolle Erkenntnisse – denn „richtige“ Nutzer sehen das Ganze noch mal mit anderen und vor allem mit frischen Augen.
Ein gut organisiertes Testing hat keine gravierenden Auswirkungen auf Tempo und Dynamik, ganz im Gegenteil: Durch die Erkenntnisse ist der Fokus hinterher schärfer, die Arbeit zielgerichteter.
Letzten Endes hat das Testing dazu geführt, dass wir mit guter Gewissheit unser Produkt veröffentlichen konnten – wohl wissend, dass es noch Optimierungspotenzial gibt.
Testing ist ein elementarer Bestandteil, wenn das Produkt am Ende nicht einfach nur fertig, sondern auch wirklich sinnstiftend und zweckerfüllend sein soll.
Apropos fertig:
5. Einfach mal machen!
Das Produkt ist niemals fertig! Wenn man es auf die Zielgruppe loslässt, ist dies erst der Anfang. Insights, Performance, Research, neue Ideen, sich ändernde Anforderungen, aufholender Wettbewerb, neue Technologien, Sicherheitslücken … Die Gründe für Anpassungen sind mannigfaltig.
Vor allem während der initialen Entwicklung kann es passieren, dass sich das Backlog schneller füllt, als es abgearbeitet wird.
Die Gefahr: Der Live-Gang verschiebt sich immer weiter nach hinten, das Team schießt mit großen Ambitionen über das Ziel hinaus und wird deshalb nie fertig. Ehrbares Scheitern.
Die Lösung: sich nicht dem eigenen Perfektionismus ergeben und lieber der Zielgruppe eine Freude machen. MVP first – also ein minimal funktionsfähiges Produkt an den Start bringen, das anschließend sukzessive erweitert wird. Sobald das Produkt einen Mehrwert bringt, sich gut bedienen lässt, keine nennenswerten Bugs mehr hat und natürlich alle gebotenen Sicherheitsaspekte erfüllt sind: Raus damit! Perfektion ist definitiv eine lobenswerte Ambition – aber manchmal steht sie auch einfach nur im Weg.
Transparenz ist in diesem Fall das A und O. Wird offen kommuniziert, was noch fehlt und für künftige Releases geplant ist, ist die Nutzerschaft gnädig.
Besser noch ist die zusätzliche Einbindung einer Feedback-Option. Die wird zwar nicht übermäßig benutzt, aber wenn, dann hat sich jemand wirklich Gedanken gemacht und liefert wertvollen Input.
Releases in kurzen Intervallen eröffnen übrigens auch einen guten Raum für Experimente. Optimierungen, neue Features oder A/B-Tests lassen sich zur Insight-Gewinnung fix zu- und wieder abschalten.
Zu guter Letzt
Ich könnte noch so viel mehr Argumente liefern. Aber das wichtigste Argument lässt sich ohnehin nur in der Praxis vermitteln: Das Arbeiten in agilen Teams macht ungeheuer viel Spaß! Das ist nicht nur toll, sondern ganz nebenbei auch die beste Voraussetzung für beste Ergebnisse.
Sascha Köhn ist Senior UX Consultant bei Ray Sono und als solcher immer erst dann zufrieden, wenn hinter allem ein Sinn und ein Zweck steht.
Willst du noch mehr über Ray Sono erfahren? Get in touch!
_v01.png)
