Was Product Owner über UX wissen sollten
Teil 1: Als PO solltest du ein SCRUM-Team mit UX-Magie haben
SCRUM oder vergleichbare agile Vorgehensmodelle werden immer häufiger eingesetzt, um Produkte und Services zu entwickeln – manchmal mehr, manchmal weniger und häufig auch gar nicht erfolgreich. Doch woran liegt es, dass so viele Produkte und Services scheitern? Die Antwort ist in den meisten Fällen: Fehlende UX-Magie! Product Owner und Produktmanager*innen orientieren sich häufig an den „4 Big Risks“: Value, Usability, Feasibility und Business Viability.
Ziel ist es, diese 4 Risiken minimal zu halten – in der Theorie einfacher gesagt als in der Praxis umgesetzt.
Was es braucht:
- Ein funktionierendes interdisziplinäres Team mit UX-Magie
- Einhaltung der 8 agilen UX Prinzipien zum erfolgreichen, nutzerzentrierten Gedränge (siehe Blogartikel „Was Product Owner über UX wissen sollten Teil 2“, erscheint am 08.12.2021)
In diesem Blogartikel wird folgend näher auf das Thema „Ein funktionierendes interdisziplinäres Team mit UX-Magie“ eingegangen:
Bei den Risiken in ihrer näheren Erläuterung nach Marty Cagan (hier geht es zur Quelle), wird ziemlich schnell deutlich, dass Product Owner in agilen Entwicklungsteams ohne UX-Magie aufgeschmissen sind. Diese brauchen ein funktionierendes interdisziplinäres Team, unabhängig davon in welcher Branche Product Owner für das Produkt oder den Service verantwortlich sind.
- value risk – whether customers will buy it or users will choose to use it
(Übersetzt: Ob die Kundschaft es kaufen oder die User es verwenden werden.) - usability risk – whether users can figure out how to use it
(Übersetzt: Ob die User herausfinden können, wie man es benutzt.)
Wie bereits aus den ersten beiden Risiken deutlich wird: Es besteht eine starke Abhängigkeit zu den Nutzenden und der Kundschaft, was häufig unwissentlich oder aufgrund fehlender Ressourcen missachtet wird. Häufig wird vermutet und mittels subjektiver Einschätzungen bzw. best guess entwickelt oder gedacht, dass die vorhandenen Informationen bereits ausreichen. Jedoch werden die Risiken dadurch maximiert anstatt minimiert. Wer es richtig machen will, kann diese Risiken durch Kompetenzen in den UX-Bereichen „Research“ und „Testing“ minimieren. Nutzende und Kundschaft werden kontinuierlich involviert. Es braucht UX Research und UX Testing Fachkräfte im Team oder zumindest das Wissen, sodass die notwendigen Aufgaben (wie bspw. Testpersonen rekrutieren, Testkonzepte aufstellen, Durchführung, Analyse und Bewertung etc.) erledigt werden, um diese beiden Risiken zu minimieren. Und bitte keine Panik, denn die meisten denken, dass Research und Testing teuer sind. Jedoch gibt es zum einen viele schnelle und kostengünstige Maßnahmen und zum anderen sind Produkte, welche nicht den „Need“ der Nutzenden und Kundschaft trifft und eine schlechte Usability hat wesentlich teurer, weil im Nachgang Extraarbeit zustande kommt. Es ist wichtig zu wissen, welche Maßnahmen, wann und wie eingesetzt werden können und sollten, jeweils mit den verfügbaren Ressourcen.
- feasibility risk- whether our engineers can build what we need with the time, skills and technology we have
(Übersetzt: Ob unsere Ingenieure und/oder Entwickler mit der Zeit, den Fähigkeiten und der Technologie, die wir haben, das bauen können, was wir brauchen.)
Hier sollte zunächst erwähnt werden, dass es darum geht, was die Nutzenden brauchen, um das Produkt, den Service oder das System effizient und zufriedenstellend nutzen zu können und nicht das Team.
Das dritte Risiko wird durch Kompetenzen in den UX-Bereichen „Architektur“ und „UI Design“ minimiert. Häufig übernehmen diese Aufgaben (wie bspw. Informations- und Navigationsstrukturen, Prototyping etc.) Product Owner oder Entwickler*innen, welche jedoch bereits zu viel mit anderen Aufgaben zu kämpfen haben. Häufig fehlt auch das Wissen, da die Erfahrungen und Spezialgebiete im Management oder IT-Bereich und nicht im psychologischen oder gestalterischen Bereich ausgeprägt sind.
- business viability risk – whether this solution also works for the various aspects of our business
(Übersetzung: Ob diese Lösung auch für die verschiedenen Aspekte unseres Geschäfts funktioniert.)
Dieses Risiko minimiert sich teilweise schon durch das Minimieren der ersten drei Risiken (Research, Design und Testing). In der Regel haben Product Owner die Geschäftsaspekte im Blick und können von Researcher*innen unterstützt werden. Alle notwendigen Informationen sollten im gesamten Team transparent sein. Auf diese Weise kann das Team Product Owner unterstützen. Researcher*innen haben meist die wichtigen und notwendigen Erkenntnisse, die Product Owner brauchen, um bspw. Ressourcen planen, Entscheidungen treffen und falls nötig beim Management argumentieren zu können – im besten Fall liegt das Wissen hierfür im gesamten Team.
In der folgenden Grafik wird gezeigt und beschrieben, wie ein agiles SCRUM-Team mit UX-Magie (in dem Fall Teammitglieder mit UX Kompetenzen) aufgestellt sein sollte:
Hier gibt´s die Grafik als PDF-Datei zum Download.
Folgendes sollte zusätzlich beachtet werden:
- Maximal 10 Teammitglieder (inkl. Product Owner und Scrum Master) – in der Praxis hat sich eine Anzahl von 6-8 Teammitglieder bisher als optimal erwiesen
- Wenn mehr Teammitglieder nötig sind, sollte überlegt werden, ob das Produkt bspw. in Teilbereiche aufgeteilt werden kann
- Für jeden notwendigen Bereich jeweils Fachkräfte oder notwendiges Wissen / Unterstützung einholen
Für ein Softwareprodukt könnte eine ideale Zusammenstellung bspw. wie folgt aussehen:
- Product Owner
- Scrum Master
- User Researcher
- Je nach Bedarf Informationsarchitekt*innen / UX Designer / Interaction Designer
- UI Designer mit Frontend Erfahrung
- Entwickler*in (Frontend)
- (Datenbank)Architekt*in (Backend)
- Nach Bedarf noch weitere Entwickler*innen Backend / Fullstack
- In nicht Softwareprojekten sollten nach Bedarf die Entwickler*innen durch Ingenieur*innen oder andere Fachkräfte ersetzt werden. Je nach Branche kann das stark variieren. SCRUM kommt zwar ursprünglich aus der Softwaretechnik, kann jedoch auf viele andere Bereiche adaptiert werden, da es ein leichtgewichtiges Modell ist, welches sich flexibel anpassen lässt
Wichtig ist, dass ein agiles Team nie ohne UX-Magie auskommt.
Sind keine UX Fachkräfte verfügbar, braucht es zumindest das Investment, notwendiges Wissen aufzubauen, sich beraten oder schulen zu lassen und die Zeit einzufordern, notwendige UX Maßnahmen durch Teammitglieder durchzuführen. Ein entscheidender Faktor des ROI ist es, mittels den richtigen UX Maßnahmen, Product Owner und das Team mit Erkenntnissen für schnelle und richtige Entscheidungen zu entlasten und wenig über etwaige Lösungen und Anwendungsfälle zu spekulieren und subjektive Einschätzungen als Argumentationsgrundlage nutzen zu müssen. Wird mittels subjektiver Einschätzungen entwickelt, werden die Risiken und Kosten maximiert. Subjektive Einschätzungen wie Annahmen oder Hypothesen sollten in frühen Phasen mittels kostengünstiger Maßnahmen, wie das Validieren dieser Annahmen anhand von Low Fidelity Prototypen, getestet und im Backlog (höher) priorisiert oder gar verworfen werden.
Wer die Risiken minimieren und erfolgreich sein möchte, sollte wissen: Keine UX-Magie ist keine Lösung ☺️.
Kennen Sie schon unsere kostenlosen UX-Webinare von und mit eresult?
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!
Beitragsbild: Jason Goodman | unsplash
Toller Artikel, aber mich als Frau hat die hohe Häufung des Gendersternchens (33x) stark vom Lesen abgelenkt. Ich arbeite als PO und empfinde es als völlig okay, dass ein Product Owner auch als Product Owner bezeichnet wird.
Ansonsten unterstreiche ich die fachliche Analyse.
Hallo Alexandra Rössner,
lieben Dank für das Feedback, welches wir sehr schätzen und nachempfinden können.
Wir haben das Thema „Gendern“ soeben nochmal im eresult Team besprochen und uns dazu entschieden, den Artikel aufgrund des Feedbacks zur besseren Lesbarkeit anzupassen.
Die englischen Begriffe sind in ihrem Ursprung bereits Genderneutral. Diese habe ich nun abgeändert und hoffe, dass der Artikel nun einfacher lesbar ist.
Ich bedanke mich auch für das positive fachliche Feedback. Ich würde mich sehr über fachliche Impulse, positive Erfahrungen und auch Herausforderungen freuen, um darüber schreiben/sprechen zu können. Ansonsten wünsche ich viel Erfolg in der Rolle als PO und den damit einhergehenden spannenden Aufgaben.
Viele Grüße
Rebecca