Ein gutes Doppel: User Experience Design und Scrum

Drei Personen arbeiten an einem Tisch, zeichnen und beschriften Klebezettel zum Thema UX.

In der Softwareentwicklung setzt sich Scrum als agile Projektmanagement-Methode zunehmend durch. Inzwischen gibt es zahlreiche Workshops, umfassende Literatur und eine große Anzahl erfahrener Scrum-Experten. Im Scrum-Kontext wurde es bisher jedoch vernachlässigt, andere Elemente und fachliche Disziplinen, die essenziell für ein starkes Produkt sind, zu integrieren – wie beispielsweise das User Experience Design. Eine gute User Experience (UX) führt dazu, dass Anwender ein Produkt bzw. eine Software gerne nutzen und ist damit ein wesentlicher Erfolgsfaktor.

Dennoch treten in der Praxis das User Experience Design und der Scrum-Prozess bisher meist nur nebeneinander an und haben wenige Berührungspunkte: Das User Experience Design – vom User Research über die Definition von Personas bis hin zur Erarbeitung von Skizzen und Wireframes – wird oft im Voraus erstellt und dann für die Umsetzung dem Entwicklungsteam übergeben. Erschwerend kommt hinzu, dass meist externe, spezialisierte Agenturen – die oft nach der klassischen Wasserfall-Methode arbeiten – das User Experience Design gestalten. Das liegt zumeist daran, dass bei der Gründung insbesondere der seit längerem bestehenden IT-Unternehmen das Thema UX noch nicht so sehr im Vordergrund stand wie heute.

Mit der zunehmenden Bedeutung und Verbreitung des Internets – bis auf die Bildschirme unserer Smartphones – haben sich die Ansprüche der User an eine Software jedoch verändert: Sie legen deutlich mehr Wert auf das Design und die Nutzerführung einer Software oder einer Internet-Anwendung. Um den stetig steigenden Ansprüchen der User gerecht zu werden und nicht zuletzt, um Marktanteile zu halten oder gar auszubauen, muss das UX-Design den User nicht nur bei der Anwendung unterstützen, sondern ihm auch ein gutes Gefühl bei der Nutzung der Software vermitteln. Je weniger Software-Unternehmen also auf ein optimales User Experience Design verzichten können, umso wichtiger ist es, diese Disziplin mit dem Scrum-Prozess zu verzahnen, der von ihnen meist für die Entwicklung eingesetzt wird. Denn nur wenn das User Experience Design und die Entwicklung im Rahmen eines agilen Prozesses gemeinsam antreten, steht am Ende ein Sieg: ein erfolgreiches Produkt, das nicht nur funktioniert, sondern das die Nutzer auch gerne anwenden.

Die drei wichtigsten Aspekte für eine erfolgreiche Integration von UX-Design in den Scrum-Prozess

Erfolgsfaktor 1: Räumliche Nähe – für mehr Austausch und gegenseitiges Verständnis

Eine gelungene agile Zusammenarbeit zwischen UX-Designern und Softwareentwicklern wird durch viele Faktoren bestimmt, der Hauptfaktor aber ist das Team selbst. Häufig ist jedoch das Verhältnis zwischen Designern und Entwicklern eher angespannt. Das liegt nicht selten daran, dass beiden Gruppen nur wenig über die Arbeitsprozesse der jeweils anderen Gruppe wissen. So ist es für Designer oft nicht leicht nachzuvollziehen, wie die Entwickler mit den von ihnen zur Verfügung gestellten Designs weiterarbeiten. Die Entwickler wiederum können sich häufig kein Bild von den Prozessen machen, die Designer durchlaufen, um ein valides Konzept zu gestalten. Für beide Seiten ist es mitunter sehr intransparent, was die jeweils andere Gruppe in ihrer täglichen Arbeit leistet.

Aufklärungsarbeit seitens der Projektleitung und der Teammitglieder selbst kann hier zunächst ein grundlegendes Verständnis schaffen. Dabei sollte erklärt werden, was die Aufgaben der einzelnen Rollen sind und inwiefern sich durch die Integration der Designer auch Prozesse in der Softwareentwicklung anpassen müssen. Es ist wichtig, dass alle Teammitglieder verstehen, dass nur durch ein gutes Zusammenspiel beider Prozesse – User Experience Design und Softwareentwicklung – ein gelungenes Produkt entstehen kann.

Prozess-Beispiel User Experience Design: Gutes UX-Design reicht von Business-Analyse und User Research über die Definition der Anforderungen bis hin zu Erarbeitung von Prototypen und regelmäßigen Usability-Tests.
Quelle: diva-e Digital Value Enterprise GmbH

Um das Verständnis für die Arbeit der jeweils anderen zu verbessern, ist räumliche Nähe ein wesentlicher Aspekt: Wenn Designer und Entwickler zusammen im gleichen Raum arbeiten, bekommen sie mit, an was der jeweils andere arbeitet. Sie können sich Fragen stellen und/oder ihre Arbeitsschritte wie z. B. Designs oder Softwarearchitektur-Bilder sichtbar im Raum anbringen. Durch das offensichtliche Visualisieren der aktuellen Arbeiten können einfacher und schneller Gespräche und Diskussionen entstehen. Diese Kommunikation – die weitaus häufiger stattfindet, wenn ein Team in einem Raum sitzt – fördert den kontinuierlichen Austausch, auch im Hinblick auf die technische Realisierung von Design-Ideen. Kurze Kommunikationswege führen dazu, dass Fragen häufiger gestellt und schneller geklärt werden, und wirken sich damit positiv auf das Produktergebnis aus.

Wenn es zeitlich möglich ist – und das entsprechende Fachwissen vorliegt – können die Designer die Entwickler auch bei der Programmierung unterstützen, etwa im Bereich der Frontend-Entwicklung. Der Vorteil: Selbst entworfene Designs lassen sich auch gleich technisch umsetzen und somit auf ihre Machbarkeit prüfen. Umgekehrt können sich auch die Entwickler im Rahmen des Scrum-Prozesses an der Erstellung des User Experience Designs beteiligen, etwa indem sie Mockups oder Prototypen erstellen.

Erfolgsfaktor 2: UX-Design schon in Sprint 0 berücksichtigen – für relevante Personas und gute User Stories

Im Scrum-Prozess wird die Zeit vor dem ersten Sprint für vorbereitende Maßnahmen genutzt, wie z. B. die Aufstellung der technischen Architektur. Dieser Zeitraum wird auch als Sprint 0 bezeichnet. In diese Phase lassen sich die ersten konzeptionellen und kreativen Prozessschritte des UX-Designs gut integrieren. Ziel von Sprint 0 ist in diesem Fall, gemeinsam ein grundlegendes Verständnis für den User und eine einheitliche Produktvision zu erarbeiten.

Hierfür empfiehlt sich ein Workshop, in dem alle Projektbeteiligten – Entwickler, User Experience Designer, Product Owner und idealerweise auch die Stakeholder – ein Big Picture der UX-Idee entwickeln. Ebenso sollten bereits in Sprint 0 die ersten Schritte des UX-Designs umgesetzt werden: User Research, Persona-Erstellung und das Erarbeiten von Anforderungen in Form von User Stories. Auf dieser Basis können die Beteiligten gemeinsam ein für alle verständliches Product Backlog erarbeiten. Bereits im Sprint 0 sollten Daily Scrum Meetings stattfinden, in denen sich die Teammitglieder gegenseitig über den Fortschritt und aktuellen Stand der Vorbereitungsphase informieren.

Die User Stories, die im Sprint 0 zusammen erarbeitet werden, sortiert der Product Owner am Ende des Sprints nach ihrer Priorität. Am höchsten werden die User Stories priorisiert, die das sogenannte Minimal Viable Product (MVP) abbilden – also das Produkt oder Feature, welches mit dem geringsten Aufwand den größtmöglichen Nutzen für den User bringt. Diese User Stories sollten dann in den ersten Sprints umgesetzt werden.

Um abschätzen zu können, wie viele Sprints benötigt werden, um das MVP umzusetzen, sollten die Entwickler in Sprint 0 eine Aufwandsschätzung der priorisierten User Stories vornehmen. Aufgabe der User Experience Designer in dieser Phase ist es, den Wert und Nutzen einer User Story zu beschreiben und die Entwickler an den Aufwand für die Umsetzung des Designs zu erinnern.

Für die Entwickler kann es schwierig sein, eine Aufwandsschätzung abzugeben, wenn noch kein definiertes User Experience Design vorhanden ist. Um ein gemeinsames Verständnis – und damit eine genauere Schätzung – der User Stories zu erreichen, empfiehlt es sich, während Sprint 0 einfache (Papier-)Prototypen zu erstellen. Die Ideen aller Projektbeteiligten lassen sich auf diese Weise schnell visualisieren und so besser in der Gruppe diskutieren. Die tragfähigsten Ideen können dann weiterentwickelt und idealerweise anhand von mit Prototypen noch in Sprint 0 auf ihre Benutzerfreundlichkeit getestet werden, z. B. von Kollegen. Das Feedback der Tester lässt sich dann in einer schnellen Iteration berücksichtigen.

Der parallelen Entwicklung geschuldet, wird es im Laufe des Projekts nur noch den User Experience Designern möglich sein, den kompletten Prozess immer wieder durchzuführen, d.h. kontinuierliche User Research, Anpassung – und falls erforderlich Neuerstellung – von Personas, Erstellung und Test von Prototypen etc. Die User Experience Designer sollten im Laufe des Prozesses darauf achten, ihre gewonnenen Erkenntnisse und Resultate regelmäßig mit dem restlichen Team zu teilen.

Erfolgsfaktor 3: UX-Designer an allen Scrum-Meetings beteiligen – für das „Big Picture“

Voraussetzung für eine ganzheitliche Integration der User Experience Designer in den Scrum-Prozess ist deren Teilnahme an allen Scrum-typischen Meetings. Dazu zählen Daily Scrum, Plannings, Product Backlog Refinement, Retrospektiven und Reviews.

Beispiel für einen agilen Projektprozess im WaterScrum-Modell: Nur wenn User Experience Design und Entwicklung zusammenspielen, steht am Ende ein erfolgreiches Produkt.
Quelle: diva-e Digital Value Enterprise GmbH

Im Rahmen dieses „institutionalisierten“ Austauschs zwischen Entwicklern und User Experience Designern – idealerweise zusätzlich unterstützt durch räumliche Nähe – können beide Gruppen schnell herausfinden, ob sich das erstellte User Experience Design mit angemessenem Aufwand umsetzen lässt. Weiterhin haben die Entwickler so auch die Möglichkeit, ihre Ideen und Ansichten in den UX-Design-Prozess einfließen zu lassen.

Ebenfalls empfiehlt sich eine enge Zusammenarbeit zwischen UX-Designern und Product Ownern, speziell bei der Ausgestaltung von User Stories. Sie können ihre Erfahrung im Umgang mit den Nutzern und deren Bedürfnisse bei der Erstellung von User Stories einfließen lassen und User Experience Designs zu den geplanten User Stories anfertigen. Dabei sollte darauf geachtet werden, sehr detailliertes User Experience Design erst dann zu erstellen, wenn es benötigt wird – und nicht schon weit im Voraus. Das Gleiche gilt auch für die finale Ausformulierung der User Stories, da es sehr wahrscheinlich ist, dass sich initiale User Stories aufgrund neuer Erkenntnisse im Laufe des Projekts ändern. Somit ist es ratsam, die User Stories auch hinsichtlich ihrer User Experience erst ein bis zwei Sprints vor der geplanten Umsetzung zu finalisieren, um den Arbeitsaufwand zu minimieren.

Als fester Bestandteil eines Scrum Teams stehen die User Experience Designer jederzeit für Rückfragen zur Verfügung. Das trägt dazu bei, Mehrfach-Arbeit zu verhindern, etwa wenn ein Detail zum Verhalten des User Interfaces vom Entwickler anders verstanden und ohne Rückfrage implementiert wurde. Indem sie die Akzeptanzkriterien einer User Story prüfen, unterstützen die UX-Designer auch den Product Owner, der die User Stories maßgeblich mitprägt.

User-Tests sind ein weiteres Aufgabenfeld, dessen sich UX-Designer während der Entwicklung annehmen können. Hierfür empfiehlt es sich, mit ausgewählten Anwendern in regelmäßigen Abständen – etwa alle zwei Sprints – Usability-Tests durchzuführen, idealerweise zunächst mit Prototypen. So hat die Zielgruppe die Möglichkeit, neu implementierte Produktinkremente zu evaluieren. Eine frühe Rücksprache mit den Anwendern hat den Vorteil, dass etwaige Änderungswünsche der User umgehend berücksichtigt werden können. Insbesondere wenn die Anpassungen bereits an Prototypen erfolgen und nicht erst an der bereits entwickelten Software, bedeutet das enorme Zeit- und Kostenersparnisse. Anpassungen lassen sich direkt in einer darauffolgenden Iteration vornehmen, oder die Änderungswünsche werden in neuen User Stories verankert. Um den transparenten Austausch mit dem Scrum Team aufrecht zu erhalten, sollten die UX-Designer die Ergebnisse der User Tests im Daily Scrum präsentieren.

Fazit

User Experience Designer können in einem Scrum-Team umfassende Aufgaben übernehmen und wesentlich zum Erfolg des Produkts beitragen. Voraussetzung dafür ist, dass die UX-Designer als Doppelpartner der Entwickler im Scrum-Prozess mitspielen. Zum einen ist es ihre Aufgabe, nach vorne zu schauen und mittels User Research, User Tests und Prototyp-Erstellung eine auf den Anwender ausgerichtete Entwicklung des Produkts voranzutreiben. Zum anderen sollten sie immer für Nachfragen der Entwickler bezüglich aktuell bearbeiteter User Stories verfügbar sein, die bereits implementierten User Stories validieren und gegebenenfalls an der Zielgruppe testen.

Dabei sollten sich alle Beteiligten bewusst sein, dass es in der agilen Softwareentwicklung im Grunde keine endgültige Lösung gibt. Mit sich verändernden Bedürfnissen der User muss sich schließlich auch das Produkt verändern – indem es stetig angepasst und weiterentwickelt wird. Daher sind mit der Freigabe eines Softwareprodukts die Entwicklung und das User Experience Design nicht abgeschlossen. Im Prinzip beginnt in diesem Moment schon ein neues Match.

Portraitfoto: Heidi Oltersdorff

Heidi Oltersdorff

Consultant

diva-e Digital Value Enterprise GmbH

Bisher veröffentlichte Beiträge: 1

7 Kommentare

  • J. Hänfling

    Hallo Frau Oltersdorff,
    einigen Kernthemen Ihres Beitrags stimme ich ganzen Herzens zu, wie der absoluten Wichtigkeit guten UX-Designs für die Akzeptanz in der heutigen Zeit wie auch die Notwendigkeit, dies bereits in der ersten Produktphase zu berücksichtigen.
    Ihre Einteilung der Welt in „UX“ und „Entwickler“ lässt mich jedoch vermuten, dass Sie das Scrum-Vorgehen nur in dem Aspekt der iterativen Softwareentwicklung betrachen. Im Kern geht es bei Scrum jedoch seit eher darum, alle Aspekte des Produkts, und dazu gehört auch UX/UI, gemeinsam zu erstellen.
    Ihre Trennung sorgt wiederum eher dafür, dass die „Entwickler“ durch die „UX“ Spezifikationen in Form von User-Stories bekommen, und diese dann genauso umzusetzen haben.
    Sie heben UX als wichtigere Disziplin (als beispielsweise Softwarearchitektur) heraus und platzieren diese als weiteren Stakeholder ausserhalb des Teams. Das Gegenteil ist meiner Meinung nach der richtige Weg. Ein UX-Spezialist muss sich als vollwertiges Teammitglied begreifen und seine Stärken voll in den Dienst des Teams stellen. Dann hat auch ein Product-Owner die Möglichkeit, echte, am Gesamt-Nutzen und -Wert orientierte Stories zu schreiben, die ein starkes, voll funktionales Team in ein gutes Gesamt-Produkt zu verwandeln.
    Viele Grüße
    J. Hänfling

    • Das sehe ich ähnlich, allerdings ist meine Erfahrung noch etwas anders.
      So muss ich feststellen, dass UX Designer deutlich häufiger in Ihrer Arbeit „gegängelt“ werden, als dies bei Entwicklern der Fall ist.
      Wann kam es mal vor, dass sich ein Entwickler gegenüber dem Kunden dafür rechtfertigen muss, dass er eine Schnittstellenabfrage mittels Observable anstelle eines Promises gestaltet, dass er Switches anstelle von if Abfragen verwendet, ob sein Code den Ansprüchen des Clean Codings genügt und ob er nun in Java, PHP oder Node.js das Backend programmiert.
      Wenn es allerdings um Designfragen geht, meint jeder, egal ob Kunde, Entwickler oder Scrum Master (!) kompetent zu sein, der Designerin / dem Designer zu sagen WIE! sie/er die Designanforderung umzusetzen hat.
      Dabei ist es ja gerade die Autonomie des Teams, zu entscheiden, wie eine Anforderung umgesetzt wird, was Scrum so erfolgreich macht.
      Hier beraten sich Entwickler – meist in Form von Code Reviews / Pull-Requests auf fachlicher Augenhöhe über ihr fachliches Vorgehen.
      Designerinnen und Designer sehen sich häufig der Tatsache konfrontiert, dass sie ihr Design gegenüber fachlichen Laien verteidigen müssen und dieses freigeben lassen müssen. Ihnen wird nur in Ausnahmefällen eine Autonomie über das Design zugestanden, wie dies ein Coder im allgemeinen genießt.
      Daher bin ich auch dafür, dass Designer im Scrum-Team aufgehen, sich auf fachlicher Augenhöhe mit anderen Designern über ihre Entwürfe austauschen und natürlich eine fachliche Schnittstelle zur Entwicklung aufbauen – denn nur wenn ein Design die technischen Bedingungen kennt und berücksichtigt, kann es ein gutes Design sein.
      Dazu gehört aber auch ein Umdenken aus Richtung des Kunden, der lernen muss, Designanforderungen zu formulieren und deren Erfüllung durch Usability-Tests und Zielgruppen-Evaluation zu überprüfen, statt wie so häufig die Designerin / den Designer zu Pixelschubserinnen und Pixelschubsern zu degradieren.

  • Pingback: Lesenswert: Februar/März 2017 | produktbezogen.de

  • Pingback: Confluence: UBS Intranet

  • Pingback: Confluence: Team Thinking

  • Pingback: Confluence: Team Thinking

  • Pingback: Confluence: FIO Design

Schreibe einen Kommentar

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