Agile UX: Die Zusammenarbeit von UX-Agentur und Kunde muss sich ändern

Das letzte halbe Jahr hat mich zum Nachdenken gebracht – zum einen durch bestimmte Projekte, zum anderen durch Talks auf der UXLX-Konferenz und vor kurzem der MobX in Berlin. Ich würde von meinen Kollegen und mir behaupten, dass wir einen guten Job machen, in Projekten immer unser Bestes geben und dass auch die Ergebnisse stimmen. Aber leider hat unsere Arbeit als UX-Agentur am Ende häufig nicht den erhofften Einfluss auf das Endprodukt, sondern die Erkenntnisse und Empfehlungen bleiben irgendwo auf der Strecke.

Die Gründe dafür liegen hauptsächlich in den organisatorischen Silos, die leider viele Unternehmen prägen. Die Art, wie UX-Agenturen meistens mit Kunden arbeiten, kreiert ein noch viel abgeschotteteres Silo und ist deshalb ineffektiv und ineffizient. Punktuelle, exakt definierte Projekte mit genauen Deliverables sind ein überholtes Modell. Ich glaube es ist Zeit für eine neue Form der Zusammenarbeit von UX-Agentur und Kunden – eine partnerschaftliche und agile UX.

Der Status Quo: Ein Wasserfall von Silo zu Silo

brad-frost-team1Abb. 1: Der typische Wasserfall – Kein Involvement in anderen Phasen (von Brad Frost)

Sicherlich kommen die folgenden Probleme vielen bekannt vor:

  • Verschiedene Disziplinen im Projekt wie User Research, Informationsarchitektur, Design und Entwicklung sind stark getrennt und folgen im Wasserfall-Prinzip nacheinander (Abb. 1).
  • Es werden Deliverables produziert, die dann vom einen ins andere Silo geschickt werden. Es gibt zu wenig direkte Kommunikation und die Deliverables verschwinden häufig in der Schublade. Informationen etwa aus dem Research werden vergessen und bei späteren Entscheidungen nicht mehr beachtet.
  • Besonders das Design leidet darunter, weit von der Entwicklung entfernt zu sein. Wie Stephen Hay es beschreibt, haben UX-Designer im Vergleich etwa zu Fashion oder Print Designern eine unglaublich große Distanz vom eigentlichem Medium, dem Code (Abb 2).
  • Das äußert sich dann darin, dass statische Photoshop-Dateien entworfen werden, bei responsiven Seiten auch für 3 verschiedene Breakpoints. Und später ärgert sich der Designer dann, dass die finale Website ganz anders aussieht und das responsive Verhalten auch nicht perfekt ist. Aber wen wundert es: Photoshop ist halt kein HTML-Code und eigentlich sind nicht die Breakpoints wichtig, sondern all die vielen Auflösungen dazwischen.

stephen-hay-designer-mediumAbb. 2: Designer von Websites sind weiter als alle anderen Designer vom finalen Medium entfernt (von Stephen Hay)

Im Grunde genommen treten diese Probleme an den Schnittstellen zwischen Projektphasen und Verantwortlichkeiten auf. Es wird zu viel Wert auf Deliverables und Dokumentation gelegt und zu wenig auf Kommunikation und Zusammenarbeit – organisatorische Silos eben.  Diese Probleme gibt es auch innerhalb von Unternehmen mit internen UX-Abteilungen zur Genüge, aber bei der Zusammenarbeit mit einer UX-Agentur oder sogar noch weiteren Agenturen treten sie noch deutlicher zu Tage.

Dann ist die Silo-Bildung noch viel schlimmer und auf Grund eigener Interessen und vertraglich festgelegter Deliverables leidet die Zusammenarbeit noch mehr. Anstatt dynamisch auf Probleme und Unvorhergesehenes reagieren zu können – und dazu kommt es in jedem Projekt – sind die Beteiligten an den geplanten Ablauf gebunden. Häufig lernt man die später weiter am Projekt arbeitenden Personen nicht einmal kennen.

Agile UX: Partnerschaftliche Zusammenarbeit über alle Phasen

Der Schlüssel zum Aufbrechen dieser Silos liegt in der Kommunikation über Abteilungen, Rollen und Phasen hinweg. Aber bei reiner Kommunikation sollte es nicht bleiben – stattdessen ist tatsächliche Kollaboration notwendig. Es ist naiv zu denken, dass etwa ein Entwickler nicht auch in früheren Phasen etwas beitragen kann. Bedingt durch die hohe Komplexität von Projekten ist das frühe Involvement aller Beteiligten unabdingbar. Hier nur ein paar Beispiele:

  • User Research: Zu klärende Fragen können von allen kommen und auch die Beobachtung und Protokollierung kann im Team erfolgen.
  • Interaktionsdesign: Entwickler können bewerten, was nicht geht und welche Alternativen es gibt.
  • Visuelles Design: Content-Verantwortliche liefern Input zum Umfang der Inhalte und möglichen Sonderfälle.
  • Entwicklung: An diesem Punkt treten immer noch Unklarheiten und nicht geplante Sonderfälle ein, die dann gemeinsam gelöst werden müssen.

Natürlich läuft ein Projekt nicht so strikt linear ab, aber prinzipiell ist es wichtig, alle von Anfang an zu beteiligen. Dabei hat nicht jeder zu jedem Zeitpunkt ein gleich starkes Involvement, aber alle müssen auf dem Laufenden bleiben (Abb. 3). So können sie mögliche Probleme aus ihrer Sicht frühzeitig aufwerfen und fühlen sich auch einfach besser abgeholt.

brad-frost-agile-uxAbb. 3: Durchgängiges, aber wechselnd starkes Involvement über verschiedene Phasen (von Brad Frost

Unter Agile UX wird meistens die Integration von UX in agile Softwareentwicklung verstanden – ein spannendes Thema, dem ich mich in weiteren Blogbeiträgen widmen werde. Der Grundstein für Agile UX ist aber die Kommunikation und Kollaboration, die ich beschrieben habe. Dies lässt sich auch sehr gut aus dem Agile Manifesto ablesen und auf UX-Arbeit übertragen:

  • Individuals and interactions over processes and tools: Mehr direkte Kommunikation mit allen Stakeholdern und frühe Beteiligung aller im Projekt.
  • Working software over comprehensive documentation: Arbeit am finalen Produkt, zusammen mit den Entwicklern, statt pixelgenaue Photoshop-Designs und ordnerweise Spezifikationen.
  • Customer collaboration over contract negotiation: Zusammenarbeit mit dem Endprodukt als gemeinsames Ziel und kein bis ins letzte Detail festgelegter Vertrag.
  • Responding to change over following a plan: Immer das aktuell Beste fürs Projekt tun, auch wenn es zuvor nicht vorgesehen war.

Bei eResult: Wie wir versuchen, agiler mit unseren Kunden zu arbeiten

Wie bereits erwähnt, wird die gewünschte Zusammenarbeit nicht gerade einfacher, wenn man als UX-Agentur im Projekt beteiligt ist. Wie versuchen wir bei eResult, mit diesen Herausforderungen umzugehen?

  • Wir nennen das aktuell Rent an eResulter. Es ist ein Rückbesinnen auf die Rolle als Berater, der das Projekt in seiner Gesamtheit begleitet – vielseitig und ganz nach Kundenbedarf.
  • Ein erfahrener UX-Consultant bringt UX-Expertise ins Kunden-Team – Wissen zu Prozessen, User Research, Konzeption und angrenzenden Bereichen.
  • Er arbeitet viel vor Ort beim Kunden, meistens an festen Tagen in der Woche, kann aber bei Bedarf auch spontan per Telefon beraten. Wie viel Zeit das ist, variiert je nach Projektphase und nach geplanten Aufgaben des Consultants.
  • Durch die längerfristige Zusammenarbeit vor Ort wird er ins Team integriert und kann darauf eingehen, wie es beim Kunden wirklich läuft. Die unsichtbaren Barrieren für gute UX in Unternehmen können viel besser umgangen werden, als wenn er nur extern arbeitet.
  • Wenn es akute Erfordernisse oder Chancen für ein höheres UX-Involvement gibt, etwa in Form von User Research oder einem UX-Test, kann er diese erkennen. Kleinere Fragestellungen können häufig direkt mit einem schnellen AB-Test geklärt werden. Andere Methoden können, wenn gewünscht, unter Beteiligung von weiteren eResultern kurzfristig umsetzt werden. So wird die gesamte UX-Arbeit schneller und auch iterative Prototypen-Tests können leichter abgewickelt werden.
  • Parallel zur operativen Arbeit läuft häufig noch das Enabling des Kunden durch Schulungen und kontinuierliches Coaching bei der Arbeit. So baut der Kunde auch intern UX-Expertise auf.

Natürlich ist diese Art der Zusammenarbeit mit Kunden nicht trivial:

  • Vom UX-Consultant erfordert dies ein sehr breites Wissen auch angrenzender Disziplinen und noch mehr als sonst die Fähigkeit, mit verschiedensten Stakeholder zu kommunizieren.
  • Kein Projekt ist wie das nächste, da kein Kunde wie der andere ist. Man muss die Gegebenheiten und Besonderheiten schnell erkennen und sich daran anpassen können.
  • Viel Kommunikation über die eigene Rolle und die aktuelle Arbeit ist erforderlich, damit keine Missverständnisse entstehen. Auch wenn man in viele verschiedene Rollen schlüpft und spontan neue Aufgaben übernimmt, so muss dies immer transparent für den Kunden bleiben.
  • Auch vom Kunden erfordert diese Zusammenarbeit ein Umdenken. Wenn es keine fest definierten Pläne und Deliverables gibt, ist der Wert der Arbeit schwer messbar. Es ist viel Vertrauen notwendig, um sich darauf einzulassen.

Aus eigener Erfahrung mit dieser Arbeitsweise bin ich fest davon überzeugt, dass es die effektivste und effizienteste Art der Zusammenarbeit ist. Denn ich will, dass meine Arbeit nachhaltig ist und größtmöglichen, positiven Einfluss hat. Statt nur für in Schubladen verschwindende Reports möchte ich Verantwortung übernehmen für das finale Ergebnis des Projekts, indem ich mich bis zum Ende einbringe. Und ich möchte immer das aktuell Beste für das Projekt tun, statt blind dem lange im Voraus vereinbarten Vertrag zu folgen. Ich glaube und hoffe, dass darin die Zukunft für UX-Agenturen liegt.

5 Kommentare zu „Agile UX: Die Zusammenarbeit von UX-Agentur und Kunde muss sich ändern

  1. Pingback: Lesenswert: September 2015 | produktbezogen.de

  2. Sebastian Feige

    Ein ganz toller Artikel, der viele unbequeme Wahrheiten benennt und dem ich vollstens zustimme.

    Danke und viel Erfolg!

    P.S. : Den Begriff „Rent an eResulter“ solltet ihr imho unbedingt überdenken.

  3. Pingback: Am 30. gehen wir ins Lab - jeden Monat! - Usabilityblog.de

  4. Pingback: Agile UX: User Research in Agile integrieren

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *