Was Product Owner über UX wissen sollten

Lady Justice

Teil 2: 8 agile UX Prinzipien zum erfolgreichen, nutzerzentrierten „Gedränge“

Inspiriert durch die agilen Prinzipien und die gesammelten Erfahrungen im SCRUM- und UX-Bereich, werden folgend 8 agile UX Prinzipien zum erfolgreichen, nutzerzentrierten „Gedränge“ ergänzt. Die Einhaltung dieser Prinzipien hilft SCRUM-Teams, erfolgreiche Produkte und Services zu entwickeln. Es gibt in dem Fall kein richtig und kein falsch und auch keinen Anspruch auf Vollständigkeit.

  1. Unsere Priorität ist es, die Nutzer- und Kundschaft regelmäßig in den Entwicklungsprozess zu involvieren und zu begeistern
  2. Eine nutzerzentrierte Produkt- / Servicevision muss von Beginn an, zu jeder Zeit, im gesamten Team gelebt und sich stets an dieser Vision orientiert werden
  3. Nutzende zu beobachten und mit ihnen zu sprechen ist effektiver als sie nur zu befragen
  4. Passende (UX-) Maßnahmen und Methoden sind nicht optional, sondern obligatorisch. Dabei gilt Pragmatismus vor Dogmatismus
  5. Alle Artefakte/Hilfsmittel werden nutzerzentriert beschrieben und sind zu jeder Zeit für das Team sichtbar, zugänglich und iterativ lebendig
  6. Visionsorientierte Ziele sind messbar und Inkremente nutzerzentriert testbar
  7. UX-Magie ist Teil des Teams und kein Zusatz. (siehe auch Blogartigel: Was POs über UX wissen sollten Teil 1 – Als PO solltest du ein SCRUM Team mit UX-Magie haben)
  8. Täglicher Austausch im Team zu neuen (Nutzer-)Erkenntnissen ist essenziell

Warum ist die Einhaltung dieser Prinzipien für den Erfolg wichtig?

1.  Unsere Priorität ist es, die Nutzer- und Kundschaft regelmäßig in den Entwicklungsprozess zu involvieren und zu begeistern

Es ist kein Geheimnis, dass viele Produkte und Services failen (in manchen Studien ist von mehr als 80% die Rede). Das liegt überwiegend an der fehlenden Akzeptanz durch fehlende Relevanz für die Nutzer und Nutzerinnen. Die User Experience ist wichtiger als die Produkt- und Serviceeigenschaften selbst, sprich wenn das Produkt für alle Beteiligten (bspw. Management, Team) nicht optimal scheint, die Nutzenden dennoch begeistert sind, wird das Produkt erfolgreich sein. Obwohl diese Erkenntnis schon lange bekannt ist, finden UX-Methoden selten, punktuell, zufällig oder unbedacht Einsatz. Im Team wird sich mehr auf einzelne Funktionen fokussiert und subjektiven/eigenen oder internen Meinungen mehr Beachtung geschenkt als die der Nutzer- oder Kundschaft. Sollen die User begeistert werden, müssen diese regelmäßig in den Entwicklungsprozess involviert werden, die User sind die relevante Wissensquelle. Denn wer weiß besser, was die Nutzer und Nutzerinnen brauchen, als sie selbst? Ist es nicht möglich, regelmäßig echte User und User-Daten zu involvieren, gibt es ausreichend Methoden, wie dennoch die User stets im Prozess involviert sein können (mehr dazu in Prinzip 4).

2.  Eine nutzerzentrierte Produkt- / Servicevision muss von Beginn an, zu jeder Zeit, im gesamten Team gelebt und sich stets an dieser Vision orientiert werden

Gibt es keine nutzerzentrierte Produktvision (im besten Fall auch nutzerzentrierte Unternehmensvision), kann das Team nicht selbstorganisiert arbeiten und es kommt zu vermeidbaren Missverständnissen bei allen Beteiligten. Die Produktvision ist das, woran sich das Team und auch die User und Kundschaft, im besten Fall die gesamte Organisation, zu jeder Zeit des Produkt-/ Servicelebenszyklus, orientiert. Es ist das, was allen (Team, User, Kundschaft, Management, …) die gemeinsame Richtung vorgibt. Zudem entlastet die Vision Product Owner maßgeblich, da zum einen das Team zu jeder Zeit weiß, worauf es sich fokussieren muss und zum anderen die Kommunikation erleichtert. Dabei ist zu beachten, dass die Vision nutzerzentriert sein muss. Eine problemlösende, nutzerzentrierte Vision kann erst formuliert werden, wenn das Team weiß, wer die Zielgruppe ist und was für Probleme und Bedürfnisse diese Zielgruppe hat. In dieser Phase sollte noch nicht über konkrete Lösungen nachgedacht und gesprochen werden. Ein guter Blogartikel dazu ist hier zu finden: Ausarbeitung der UX Vision.

3.  Nutzende zu beobachten und mit ihnen zu sprechen ist effektiver als sie nur zu befragen

Mit das Wichtigste, was Product Owner oder weitere Beteiligte nicht kennen, missachten oder aufgrund verschiedener Gründe nicht beachten können, sind implizite Bedürfnisse. Häufig wird Feedback über den Service an die Teams weitergegeben oder User über Umfragen gefragt, wenn diese gerade ein Produkt oder Service genutzt haben oder sich sogar Beschweren wollen. Bitte nicht missverstehen, es ist besser als die User gar nicht zu involvieren und häufig hört man, dass es keine andere Möglichkeit gibt. Jedoch können implizite Bedürfnisse dadurch nicht erfasst werden und es sollte in passende Maßnahmen investiert werden. User können nur das ausdrücken, was ihnen bewusst ist. Da sich die meisten mit der Zeit und den gegebenen Lösungen abfinden (weil sie sich daran gewöhnt haben oder nichts anderes nutzen können/dürfen), schaffen sie sich Workarounds, die irgendwann zur Selbstverständlichkeit übergehen. Im besten Fall möchte man die Nutzer- und Kundschaft zufriedenstellen oder gar begeistern. Das geht nur dann, wenn man versteckte, unbewusste, eben die impliziten Bedürfnisse miterfassen kann. Dazu sollten User bspw. im Verhalten und bei der Erledigung von Aufgaben beobachtet werden. Hierfür bieten sich Methoden wie die teilnehmende Beobachtung, Think Aloud, u.s.w. an. Auch bei diesen Beobachtungsmethoden kann explizit nachgefragt werden. Diese Methoden können sowohl bei neu entstehenden als auch bereits bestehenden Produkte und Services angewendet werden.

4.  Passende (UX-) Maßnahmen und Methoden sind nicht optional, sondern obligatorisch. Dabei gilt Pragmatismus vor Dogmatismus

Abbildung 1 – Brady Bonus (2015)

UX Methoden anwenden ist leicht. Einen Blogartikel lesen und einfach machen. Zu Erkenntnissen kommt man immer – irgendwie. Passende UX-Methoden anwenden ist hingegen eine Kunst.  So wie es einen Koffer voller agiler (SCRUM-)Methoden und Artefakte/Hilfsmittel gibt, gibt es so einen Koffer auch für UX-Methoden. Diese lassen sich mit dem richtigen Know-how super vereinen bzw. überschneiden sich teils. Wichtig ist es, effizient zu arbeiten und durch Unwissenheit keine Mehrarbeit durch unpassende Methoden zu erzeugen. Werden die richtigen Methoden zum richtigen Zeitpunkt gewählt und die Erkenntnisse in die SCRUM-Artefakte und Hilfsmittel integriert, erhält man die Wombo Combo (perfekte Kombination) für die Zusammenarbeit im Team. Darüber hinaus werden stets die User involviert und die interne Kommunikation vereinfacht. Es ist ein Mythos, dass UX-Methoden zu teuer sind und viel Vorlaufzeit brauchen. Sowas wie das UX Designer Paradox (siehe Abbildung 1) entsteht, nur dann, wenn keine passenden Methoden geplant und durchgeführt werden und es keine Erkenntnisse über die User und dessen Probleme und Bedürfnisse gibt und im Team direkt in Lösungen denkt, anstatt zunächst das Problem zu verstehen. Es benötigt den pragmatischen Kompromiss und genau darin steckt die Kunst. Hier sollten sich Product Owner auch Scrum Master zur Hilfe nehmen und so investieren und kaizen, dass das Team sensibilisiert ist und Grundkenntnisse hat. Es muss nicht das gesamte Team Research und Testings durchführen (können). Es reicht auch schon das Zuschauen bei Testings, um gegenüber den User und beteiligten Rollen Empathie aufzubauen. Zu empfehlen ist, mehrere Testpersonen zu beobachten, damit die Ergebnisse nicht fehlinterpretiert werden, da Testpersonen jeweils sehr unterschiedlich sein können, auch wenn sie zu einer Zielgruppe passen.

5.  Artefakte/Hilfsmittel werden nutzerzentriert beschrieben und sind zu jeder Zeit für das Team sichtbar, zugänglich und iterativ lebendig

Wie bereits bei den Maßnahmen und Methoden lassen sich die Artefakte wie das Produkt-Inkrement, Backlog, User Stories, DoR/DoD etc. mit UX-Artefakten wie Produkt-Prototyp-Inkrement, Personas, Journeys etc. vereinen und ergänzen. Die Artefakte entstehen aus den Erkenntnissen der angewendeten Methoden und sollten, sobald sie einmal bestehen, iterativ aktualisiert werden. Die Artefakte leben über den gesamten Lebenszyklus mit. Jedes Teammitglied muss wissen, welche Artefakte es gibt, wozu diese dienen und wo der aktuelle Stand zu finden ist. Die Anzahl dieser Artefakte sollte vgl. zur Anzahl der Backlog-Items überschaubar bleiben und kollaborativ verfügbar sein (dabei können Tools wie Miro, JIRA, Axure, Figma etc. in der digitalen Welt helfen. Das funktioniert auch analog an Wänden, ist nur meist nicht so beliebt). Wichtig ist, dass Kommentare und Anpassungen zu jeder Zeit im gesamten Team gemacht werden können. Hier sollte unbedingt nachhaltig gearbeitet werden, jedoch sollten Working Documents nicht in Schönheit sterben. Product Owner sollten dem Team regelmäßig die Möglichkeit geben, die Artefakte auf einem aktuellen Stand zu halten und aufzuräumen. Je länger gewartet wird, desto schwieriger wird es und der Aufwand steigt exponentiell. Von aktuell gehaltenen Artefakten profitieren alle Beteiligten.

6.  Visionsorientierte Ziele sind messbar und Inkremente nutzerzentriert testbar

Eine Vision ist ein erstrebenswerter Zustand. Um diesen Zustand erreichen zu können, braucht es Ziele und Werte – und zwar „Warum“ und „Wie“ dieser Zustand erreicht werden kann. Gemäß dem Zitat von Mark Twain – „Wer nicht weiß wo er hinwill, darf sich nicht wundern, wenn er woanders ankommt“ – sollten Product Owner immer mithilfe des Scrum Masters und des Teams überprüfen können, ob die Ziele erreicht wurden und das Team in die Richtung der Vision läuft. Häufig werden in diesem Zusammenhang Begriffe wie Key-Performance-Indicator (KPI), Objectives and Key Results (OKR) oder Ähnliches genutzt. Zu beachten ist, dass diese Ergebnis-/Leistungskennzahlen sehr komplex sind und eher zur Messung des Erfolgs einer Organisation eingesetzt werden. Es handelt sich um quantitative Daten, die einen Wert ausgeben und häufig nicht analysiert und, auch fehlinterpretiert werden und paralysierend wirken. Das Team wird dann meist durch Einflüsse von außen oder auch durch Demotivation ausgebremst. Innerhalb eines SCRUM-Teams mit UX-Magie sollte sich auf die Vision, das Sprintziel und Backlog fokussiert werden. Die entstandenen Inkremente sollten in regelmäßigen Abständen getestet werden. Im besten Fall mit echten User oder anhand heuristischer Evaluationen oder vergleichbaren UX-Methoden. Je nach dem, um was für Produkte und Services es sich handelt, können hier auch (automatisierte) Verhaltensmessungen angestrebt werden, je früher desto besser.

Weitere Hilfreiche Whitepaper und Blogeinträge dazu sind:

7.  UX-Magie ist Teil des Teams und kein Zusatz

So wie Agilität ein Mindset ist, ist es Nutzerzentriertheit auch. Viele Möglichkeiten, wie UX wird (intern) von anderen Teams als Service durchgeführt und sind innerhalb eines Sprints für mehrere Teams zeitgleich zuständig, scheitern oft – genauso wie Product Owner nicht parallel mehrere Produkte/Services ownen und Scrum Master nicht mehrere Teams parallel kaizen (stetige Verbesserung fördern) können. Modelle wie UX als Service können dann funktionieren, wenn interne UX-Fachkräfte jeweils klar einem SCRUM-Team zugeordnet sind oder externe Mitarbeitende die Erwartungshaltung des Teams kennen. Dabei sollte immer klar abgegrenzt sein, was als Dienstleistung für das Team zu tun ist und was das Team braucht, um mit den Ergebnissen und Artefakten effizient und zielführend weiterarbeiten zu können. Jeder der denkt, dass UX nicht als regelmäßiger Bestandteil im Team notwendig ist, hat entweder die Erfahrung noch nicht gemacht, unterschätzt die soziologischen Aspekte innerhalb eines Teams oder hat ein Team noch nicht richtig performen gesehen. Die Phasen eines Teams nach Tuckman und Klotz kennt fast jeder: Forming, Storming, Norming, Performing, Adjourning und manchmal auch Endjourning. Die wichtigste Phase für das Team ist die Phase „Performing“. Am performantesten ist ein SCRUM-Team, wenn man das Team zusammenbringt, ein agiles und nutzerzentriertes Mindset fördert und ein gemeinsames Verständnis der Vision bekräftigt. Um das agile Mindset zu fördern, haben Product Owner und das Team die Unterstützung des Scrum Masters, doch wer sorgt dafür, ein nutzerzentriertes Mindset zu fördern? Dabei können UX-Fachkräfte helfen, entweder als fester Bestandteil des Teams oder durch die Übermittlung von Wissen durch Schulungen und regelmäßiger Unterstützung beim Erstellen und Pflegen der verschiedenen Artefakte. Solange, bis das Team diese Aufgaben autonom und selbstorganisiert übernehmen kann und weiß, wie man mit den Artefakten arbeitet. Bis dieser Zustand erreicht ist, sollten die Fachkräfte an den Events (Planning, Dailys und Retrospektiven) teilnehmen.

8.  Täglicher Austausch im Team zu neuen (Nutzer -) Erkenntnissen ist essenziell

Ist nichts Neues und ist durch das Daily Scrum eigentlich abgedeckt. Oft wird dieses jedoch nicht durchgeführt, Teammitglieder oder UX-Fachkräfte nehmen nicht Teil, UX Artefakte werden in zu großen Abständen bereitgestellt, Teammitglieder denken es ist nicht relevant und sprechen es nicht an etc. Das bremst das gesamte Team aus. Das Risiko, dass Filter und Wissensinseln entstehen, ist groß und häufig fördert es fehlende Empathie sowohl für die User als auch für andere Teammitglieder. Häufig gibt es Erkenntnisse, die hilfreich sein können oder Impediments (architektonisch, gestalterisch, technisch, …), die im direkten Austausch schnell adressiert und geklärt werden können. Zudem ist wichtig, dass es immer jemanden gibt, der die Rolle der User einnimmt oder darauf achtet, dass aus der Sicht der User gedacht und gehandelt wird. Immer im Hinblick auf die nutzerzentrierte Vision und das Sprintziel (hier können auch sehr gut Personas helfen).

Abschluss

Alle Product Owner, die SCRUM und UX nicht vereinen, dürfen nicht überrascht sein, wenn das Produkt failt. Sowohl SCRUM als auch der nutzerzentrierte Gestaltungsprozess sind iterativ, fokussieren sich auf schnelle mögliche Releases, Produktqualität, effiziente Entwicklung, schnellen ROI und auf eine hohe Begeisterung der User und Kundschaft. Beides zusammen ist die Wombo Combo (perfekte Kombination) der Produkt-/ und Serviceentwicklung. Mit der richtigen Expertise und Auswahl der Maßnahmen und Methoden sowie Hilfsmittel, werden die Risiken der Produktentwicklung und des Misserfolgs auf das Minimum reduziert.

Der Blogartikel umreißt das Thema nur und beschreibt, warum es wichtig ist, UX-Magie mit SCRUM zu kombinieren.

Weitere Informationen, Blogartikel und Whitepaper folgen im Laufe des Jahres. Bei offenen Fragen, Anmerkungen, Diskussionsbedarf oder einfach den Bedarf, sich über das Thema auszutauschen, nutzen Sie gerne die Kommentarfunktion.


Beitragsbild: Tingey Injury Law Firm | unsplash


Kennen Sie schon unsere kostenlosen UX-Webinare von und mit eresult?

angeschnittener Laptop und eresult-Logo

Unsere UX-Expertinnen und Experten geben ihr Know-how aus Theorie und Praxis preis:
Nutzerzentrierte Softwaregestaltung (Human-Centered Design, kurz HCD), UX Basics für Product Owner, die Entwicklung von Personas & Customer Journeys, digitaler Wandel mit Hilfe von Design Sprints, die Messung und Optimierung von Usability sowie UX-Strategien und Maßnahmen für Ihr Unternehmen – zu diesen spannenden Themen bieten wir unsere begehrten kostenlosen Webinare an.

Alle Webinare werden per Zoom durchgeführt, sind live, interaktiv und dialogorientiert gestaltet. Den jeweiligen Referent*innen können via Chat Fragen gestellt werden, die im Anschluss beantwortet werden. Unseren Newsletter-Abonnent*innen steht zudem kostenloser Zugriff auf unseren Download-Bereich mit weiterführenden Materialien wie spannenden Whitepapern oder unserem UX-Toolkit zur Verfügung.

>> Jetzt informieren und anmelden!

2 Kommentare

  • Interessanter Beitrag über das Vereinen vom Product Owner und UX. Ich selber habe damit noch keine Erfahrung gemacht, doch teile diesen Beitrag gerne.

    • Hallo Sebastian,

      vielen Dank, das freut mich sehr zu hören.
      Falls du mal Erfahrungen oder Berührungspunkte dazu haben solltest oder dich generell einfach mal austauschen möchtest, melde dich gerne.

      Beste Grüße
      Rebecca

Schreibe einen Kommentar

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