Anzeige
Anzeige
Ratgeber
Artikel merken

Ein gutes Doppel: Scrum und User-Experience-Design erfolgreich anwenden

Die Bedeutung der User Experience bei der Software-Entwicklung ist im Smartphone-Zeitalter wichtig wie nie. Doch wie lassen sich User-Experience-Design und der Scrum-Prozess vereinen?

Von Heidi Oltersdorff
8 Min. Lesezeit
Anzeige
Anzeige

(Foto: M S / Flickr Lizenz: CC BY-SA 2.0)

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.

Anzeige
Anzeige

Dennoch treten in der Praxis das User-Experience-Design und der Scrum-Prozess bisher meist nur nebeneinander an und haben wenige Berührungspunkte: Das UX-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 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.

Anzeige
Anzeige

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.

Anzeige
Anzeige

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.

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 tätig sind, bekommen sie mit, woran der jeweils andere arbeitet. Sie können sich gegenseitig Fragen stellen und/oder ihre Arbeitsschritte wie etwa 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.

Anzeige
Anzeige

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, etwa 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.

Anzeige
Anzeige

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.

(Grafik: Shutterstock)

(Grafik: Shutterstock)

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 Prototypen noch in Sprint 0 auf ihre Benutzerfreundlichkeit getestet werden, zum Beispiel von Kollegen. Das Feedback der Tester lässt sich dann in einer schnellen Iteration berücksichtigen.

Anzeige
Anzeige

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, also kontinuierliche User Research, Anpassung – und falls erforderlich Neuerstellung – von Personas, Erstellung und Testung von Prototypen etc. vorzunehmen. 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.

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 UX-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.

Anzeige
Anzeige

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.

(Grafik: Medium.com)

Als fester Bestandteil eines Scrum-Teams stehen die User-Experience-Designer jederzeit für Rückfragen zur Verfügung. Das trägt dazu bei, Mehrfacharbeit 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 aufrechtzuerhalten, sollten die UX-Designer die Ergebnisse der User-Tests im Daily Scrum präsentieren.

Anzeige
Anzeige

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.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
5 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Andre Böker

räumliche Nähe ist überhaupt nicht relevant. Wir nutzen fast täglich Skype mit Bildschirmübertragung in der Entwicklung von Verwaltungssystemen.

Antworten
derDoubleD

Hallo Andre. Super, dass das bei euch so klappt – kann und muss deswegen nicht allgemeingültig sein. Was sind aus deiner Sicht die Erfolgsfaktoren, dass dieses Remote-Arbeiten funktioniert?

Antworten
Andre Böker

Hallo DoubleD,

am besten sind gleiche Arbeitszeiten oder eine Abstimmung, wann man über Vorlagen und Lösungsbeispiele, konkrete Aufgaben, erreichte Ergebnisse, gewonnene Erfahrung, erkannte Fehler und abgeleitete Verbesserungen spricht.
Zeigt man den Entwicklern nicht, dass man die Lösung und Probleme bereits kennt, liefern sie nur das nötigste ab und das ist in der Regel nur ausreichend.

Mehr möchte ich an dieser Stelle nicht sagen.

derDoubleD

Hier die Slides eines passenden Erfahrungsberichts: Agile UX – oder We have not failed. We’ve just found 10.000 ways that didn’t … #agile #experience http://www.slideshare.net/derDoubleD/agile-ux-oder-we-have-not-failed-weve-just-found-10000-ways-that-didnt-work-nach-edison via @SlideShare

Antworten
Alex

Meine Erfahrung als Agile Coach zeigt, dass die Integration von UX und Design in das Scrum-Team eine wesentliche Voraussetzung für eine erfolgreiche Produktentwicklung ist. Gleiches gilt auch für Tester, Ops bzw. alle Expertisen, die benötigt werden, damit ein Team ein Produkt möglichst unabhängig entwickeln kann. Das fällt für mich unter Cross-functional Teams.
Bisher hält sich aber manchmal noch die Idee, dass das Interface und das Design möglichst vollständig vorab entwickelt werden und im Nachgang von den Entwicklern lediglich umgesetzt werden. Das entspräche aber eher einem Mini-Wasserfall im agilen Gewand.
So früh wie möglich sollten Prinzipien und Guidelines erstellt werden, damit sich das Produkt am Ende wie „aus einem Guss“ anfühlt. User-Stories bis ins kleinste Detail zu spezifizieren – womöglich schon im Sprint 0 und pixelperfekt – ist unmöglich und widerspricht dem Ziel agiler Methoden. Das gleicht eher klassischen Vorgehensweisen.
Ist es nicht sinnvoller, dass das gesamte Team gemeinsamen Guidelines folgt, Stories gemeinsam definiert und auch gemeinsam umsetzt?
Für neue (besonders knifflige) Features können die Teammitglieder mit ihren unterschiedlichen Expertisen regelmäßig und parallel zum aktuellen Sprint (Timeboxing), gemeinsame Product-Discoveries durchführen, wo auf UX und Designfragen eingegangen werden kann und auch die technische Machbarkeit überprüft wird, wo auch verschiedene Varianten ausprobiert und Prototypen evaluiert werden.
Die Ergebnisse und Erfahrungen daraus fließen dann in die entsprechenden Stories ein. Der Vorteil ist, dass das Team frühzeitig eine gemeinsame Richtung erarbeitet und alle das gleiche Zielbild im Kopf haben. Das Team beschäftigt sich so noch viel mehr mit dem eigenen Produkt!
Zudem wird durch diesen integrativen Ansatz die Distanz zwischen einzelnen Expertisen abgebaut und gegenseitiges Verständnis aufgebaut – am Ende benötigen wir ja EIN funktionierendes Team. Auch jeder Entwickler kann mit der aufgesetzten Kundenbrille wertvollen Input zur Produktentwicklung geben und nicht nur Code hacken ;)

PS: Soweit ich mich entsinne, ist der PO per Definition für die Bestimmung und Kommunikation von Wert und Nutzen einer Story verantwortlich, niemand sonst. Die Informationen dafür können aber natürlich von jedem aus dem Team oder von außerhalb kommen.
PPS: Räumliche Nähe ist immer vorteilhafter und kann gleichwertig nur schwer durch Tools ersetzt werden. Es ist aber nicht unmöglich.

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige