Dieser Artikel beschäftigt sich mit dem 5. Schritt des Lean-Productmanagement-Zyklus.
Einen Überblick über den Lean-Productmanagement-Zyklus finden Sie hier.
5. Erstellen der Experimente/des Minimal Viable Products
Bis zum vierten Schritt sind die Hypothesen aus dem Problembereich mehr und mehr verfeinert worden und im vierten Schritt dann noch um Annahmen und Ideen des Teams im Lösungsbereich überführt und ergänzt worden. Um nun ein gewinnbringendes Produkt mit herausragender User-Experience und dem entsprechenden Mehrwert für den Kunden erstellen zu können, müssen diese Hypothesen und annahmen mit Hilfe von User-Experience-Design in ein funktionales Produkt überführt werden. Es ist eine aufwändige, zeitintensive und damit kostspielige Aufgabe digitale Produkte umzusetzen, auch wenn es sich „nur“ um ein minimales Feature-Set handelt. Es zeigt sich aber bis hierher, dass sehr viele Unsicherheiten, Hypothesen und Annahmen in dem Prozess hineingeflossen sind und nun Designaufwände und Implementierungsaufwände notwendig sind, um im nächsten Schritt den MVP – Kandidaten auch wirklich testen zu können. Daher sollte sich der Produktmanager in diesem Schritt nun bewusst Zeit zum Reflektieren nehmen und eine Entscheidung treffen, wie das Produkt umgesetzt werden soll. Soll das digitale Produkt in Sourcecode gegossen und umgesetzt werden, um dann den Tests im nächsten Schritt die Annahmen und Hypothesen und Designentscheidungen zu überprüfen, oder sollen lieber low-fidelity, Prototypen (MVPs) mit wenig Interaktionsmöglichkeiten (wie beispielsweise Mockups) gebaut werden und diese zunächst mit Test-Kunden „getestet“ oder besser „validiert“ werden. Die zweitere Variante, sollte vor allem dann gewählt werden, wenn Programmierressourcen knapp und gute Designerressourcen verfügbar sind und vice versa ersteres bei knappen Designerressourcen.
MVP vs. Spikes
Bevor überhaupt ein MVP und dessen User-Experience designt umgesetzt werden kann muss zunächst der begriff MVP geklärt werden.
MVP steht für Minimum Viable Product, also das minimal Umsetzbare Produkt mit geringem Feature-Set welches jedoch noch „lebensfähig“ ist. Also das Produkt was für sich alleine stehen kann und aus eigener Kraft gewisse Kennzahlen wie z.B. Umsätze erreichen kann. Ein MVP muss also alle Eigenschaften eines Produkts erfüllen und darf nicht nur ein Teil eines Produkts (wie beispielsweise nur die Backendlogik) sein. Die folgende Grafik veranschaulicht dies
Abb. MVP vs. Spike angelehnt an The lean Product-Playbook von Dan Olsen Mai 2015 Seite 90
MVPs umfassen und beinhalten alle Bereiche die ein voll ausgereiftes Produkt aufweist und beweisen dessen Lebensfähigkeit. Keine MVPs sind jedoch Spikes die beispielsweise nur die Funktionalität umsetzen jedoch nicht auf Benutzbarkeit, Zuverlässigkeit etc. achten. Zu oft werden MVPs nämlich als ausrede für schlechte Usability oder Fehleranfälligkeit verwendet. Eine rein funktionale Umsetzung um ggf. technische Unsicherheiten zu eliminieren wird Spike genannt und dient der Risikominimierung und Steigerung der Planungssicherheit.
Zwei Möglichkeiten MVPs zu kategorisieren
Es gibt zwei Möglichkeiten MVPs zu kategorisieren. Die erste Möglichkeit MVPs zu kategorisieren ist die Art des Produkts. Entweder ist ein MVP-Test ein produktbasierter MVP-Test oder ein marketingbasierter MVP-Test. Denn eines sollte nie außer acht gelassen werden, das Ziel von MVPs ist es etwas über den Markt und seine Bedürfnisse zu lernen und somit etwas über die Kunden zu lernen und einen guten Product-Market-Fit zu erreichen. Das P im MVP könnte auch durch ein E für Experiment ausgetauscht werden. Immer wieder gibt es Diskussionen darüber, ob dieses oder jenes Experiment als MVP bezeichnet werden kann. So kann beispielsweise eine Croudfunding- Kampagne, oder ein Erklärungsvideo auch ein sehr wichtiges Mittel sein, etwas über den Markt zu lernen und Hypothesen zu validieren. Während bei produktbasierten MVP-Tests teile des Produkts ausgearbeitet, und diese dann mit Kunden validiert werden, werden bei marketingbasierten MVP-Tests „nur“ Marketing -Materialen über das Produkt erzeugt und diese mit dem Markt validiert. Es wird also nicht über das Produkt perse gelernt sondern viel mehr über den Markt und das Marketing des Produkts. Die zweite Möglichkeit MVP-Tests zu kategorisieren ist, ob der MVP-Test quantitative oder qualitative Ergebnisse liefert. Qualitative Tests werden mit Kunden oder kleinsten Kundengruppen direkt gemacht. Das Produktmanagement tritt mit den Kunden direkt in Kontakt und startet eine Dialog über das Produkt oder das Marketingmaterial, und lernt somit direkt vom Feedback der Personen. Quantitative Tests können kein direktes Feedback einsammeln, sind aber statistisch auswertbar. Somit sind Ergebnisses quantitativer Tests einfacher argumentierbar und wissenschaftlich nachzuvollziehen. Dazu ist es aber notwendig eine große Anzahl an direkten Testteilnehmern zu haben um diese Signifikanz auch tatsächlich aufzuzeigen. Somit können quantitative Tests gut aufzeigen „was“ „wie viele“ Kunden gemacht haben, können aber nicht klären „warum“ sie etwas gemacht/nicht gemacht haben. Das „Warum“ kann nur in qualitativen Tests erarbeitet werden.
| Qualitative MVP-Tests | Quantitative MVP-Tests | |
| Marketingbasierte MVP-Tests | Marketing Materialen | Landing-Pages Smoke-Tests Werbungs- Kampagnen Erklärungsvideos Croudfunding- Kampagne Marketingtests A/B-Tests |
| Produktbasierte MVP-Tests | Handgezeichnete Skizzen, Wireframes Mockups Interaktive Prototypen Wizzard-of-Oz-Prototypen Live-Produkte | Fake-Door 404 statistische Produktanalysen A/B-Tests |
Tabelle in Anlehnung an The lean Product-Playbook von Dan Olsen Mai 2015 Seite 93
Eine Unterkategorisierung bei den produktbasieren qualitativen MVP-Tests kann anhand zweier weiterer Eigenschaften vorgenommen werden. So können die Tests einerseits nach Interaktivität und andererseits nach Fidelity (also Realitätstreue) eingeordnet werden. Die folgende Grafik zeigt dieses Spannungsfeld gut auf.
Abb. angelehnt an The lean Product-Playbook von Dan Olsen Mai 2015 Seite 100
Aus den obigen Aufstellungen und grafiken ist ebenfalls sehr schön ersichtlich dass Produktmanagement eine starke Schlüsselposition zwischen Produktumsetzung auf der einen Seite und dem Markt und somit dem Marketing auf der anderen Seite ist. Die Möglichkeiten MVPs und Experimente zu testen sind, wie aufgezeigt, zahlreich und je nachdem was getestet werden soll und wie getestet werden soll, muss das Produkt oder das Experiment anders umgesetzt werden. Allen Produktentwicklungen gemein ist, dass das Produktmanagement nach sehr guter User-Experience und sehr guten Product-Market-Fit strebt.
Doch um sehr gute User-Experience zu erreichen muss zunächst der Begriff definiert werden und geklärt werden welche Tätigkeiten zum User-Experience-Design zählen.
User-Experience-Design mit dem Ux-Eisberg
Großartige Produkte weisen eine großartige User-Experience auf. Doch was ist User-Experience?
User-Experience ist all das was der User vor, während und nach der Nutzung des Produkts wahrnimmt und erfährt. In der Product-Market-Fit-Pyramide steht User-Experience an der Spitze in der obersten Stufe. Mit der Usability geht User-Experience Hand in Hand, es geht aber viel weiter und fängt früher an. Denn ein Produkt kann in der Verwendung noch so gut sein, wenn der Bestellprozess oder die Erfahrung die beim Kauf gemacht wurden sehr negativ sind, wird der Kunde das Produkt nicht weiterempfehlen. Es können also zwei Bereiche definiert werden der relevant für gute User-Experience ist. Einerseits das Produkt und somit die Verwendung des Produkts und andererseits alle Kontaktpunkte die der Kunde mit dem Unternehmen vor, während und nach der Verwendung des Produkts hat. Diese zwei Bereiche müssen gut optimiert werden, um beim Kunden einen möglichst positiven Eindruck und gute Gefühle zu erreichen.
| Als Kernaussage kann festgehalten werden, dass schlechte User-Experience und schlechte Usability dem Kunden bei der Erfüllung seiner Bedürfnisse hinderlich sind, er mehr Energie dafür aufwenden muss und negative Gefühle bekommt, während gute User-Experience dazu führt dass die Erledigung seiner Jobs und die Erfüllung seiner Bedürfnisse leicht und schnell von der Hand gehen und sehr positive Gefühle auslösen. |
In der Praxis wird auch oft vom User-Experience-Eisberg1 gesprochen. Das ist ein Modell welches sehr gut veranschaulicht, auf welche Design-Aspekte es beim User-Experience- Design und Usability- Design ankommt.
Abb. Ux-Eisberg nach The lean Product-Playbook von Dan Olsen Mai 2015 Seite 116
Das Modell wird deswegen in Form eines Eisbergs dargestellt, weil die einzelnen Schichten aufeinander aufbauen und für den eigentlichen User/Kunden nur die oberste Spitze des Eisbergs sichtbar und erlebbar sind, während alles was sich unterhalb der Wasseroberfläche befindet für den User nur indirekt erlebbar bleibt.
Der Eisberg ist in vier Schichten aufgeteilt welche von unten nach oben folgendermaßen aufeinander aufbauen:
- Conceptual Design
- Information Architecture
- Interaction Design
- Visual Design
Conceptual Design
Das Conceptual Design2 ist das Grundkonzept des digitalen Produkts. Es Baut auf den Basisbedürfnissen, Pains und Gains des Users auf und stellt diese gezielt in den Mittelpunkt. Somit bildet das Conceptual Design der Software den Grundstein für alle weiteren Ux-Eisberg-Schichten.
Als Beispiel könnte hier die App von Uber herangezogen werden. Die Customer-Profiles die Uber machte zeigten klar, dass viel Kunden von Taxi-Diensten frustriert waren über Taxis die viel zu spät auftauchten oder vielleicht sogar gar nicht auftauchten. Daher Entschieden sich die Designer von Uber eine Landkarte als zentrales Element der App zu verwenden. Auf dieser Landkarte wurden alle freien Uber-Taxis in der Umgebung und deren voraussichtliche Ankunft beim Kunden angezeigt. Wurde ein Uber-Taxi bestellt konnte dieses auf der Karte in Realtime verfolgt werden. Dieses Feature und dieses Design führte zu einem großen Vertrauensgewinn für die Anwender.
Information Architecture
In digitalen Produkten befinden sich sehr viele Daten und Informationen. Diese Datenstrukturen müssen in eine sinnvolle Reihenfolge und einen Kontext gestellt werden. In der Informations-Architektur werden Daten und Informationen und Funktionalität strukturiert und in Zusammenhang gebracht. Das einfachste Beispiel ist hier eine Website bei der entschieden werden muss, Auf welcher Seite welche Informationen stehen und wie diese Seiten zueinander verlinkt sind. Dadurch ergibt sich auch die grobe Navigationsstruktur, welche genau geplant und designt werden muss. Dieser Schritt hängt daher sehr eng mit dem nächsten Schritt dem Interaction Design zuammen.
Interaction Design
In diesem Design-Schritt werden nun auch die internen Workflows und Abläufe die der User durchlebt entworfen. Ein wichtiges Hilfsmittel hierzu können Flussdiagramme oder Geschäftsprozess-Modelle sein, die genau aufzeigen wie der User durch die Anwendung navigiert und welche Interaktionsmöglichkeiten er auf den diversen Screens zur Verfügung hat. Dabei werden aber auch die im Hintergrund durchgeführten Prozessschritte genauer durchdacht und in die Diagramme und Abläufe mit einbezogen. In diesem Schritt werden auch die ersten Wireframes erzeugt. Diese beinhalten noch kein Visuelles Design und werden bewusst in Schwarz weiß gehalten um sich voll und ganz auf die Bedienoberflächen und Interaktionsmöglichkeiten konzentrieren zu können. In diesem Schritt spielt Usability eine starke Rolle, welche im nächsten Schritt noch verfeinert werden muss.
Visual Design
Im Visual Design werden nun die ersten Mockups erstellt und dem digitalen Produkt ein Branding verliehen. Es werden Aspekte wie Farben, Grafiken, Layouts und Anordnungen der Elemente definiert und in Mockups umgesetzt. Hier wird die grundlegende Usability aus dem vorherigen Schritt nochmals verfeinert und erweitert. Auch müssen in diesem Schritt verschiedene Endgeräte und Bildschirmgrößen berücksichtigt werden (Responsive-Deisgn). In den meisten Produktentwicklungen werden spätestens in diesem Schritt parallel die ersten Sourcecode-Zeilen geschrieben und die Software umgesetzt.
Je nach Teststrategie wird also entschieden ob hier bereits Sourcecode umgesetzt wird, oder die Kunden mittels Mockup-Präsentationen und clickable Mockups oder mittels echter MVP-Kandidaten befragt werden. Mehr dazu im nächsten Schritt.
Artefakte und Outcome aus diesem Schritt:
In diesem Schritt wurde nun der MVP-Kandidat bis zu dem geplanten Reifegrad umgestzt. Denn je nachdem welche Ressourcen zur Verfügung stehen und welche Lern-/Teststrategie gewählt wurde muss das Ux-Design weiter oder weniger weit betrieben werden. Es kann durchaus auch genügen zu Beginn mal reine Pen&Paper-Prototypen zu bauen und diese mit den ersten ausgewählten Test-Kunden zu testen, darüber zu diskutieren und zu lernen. Ziel ist es in dieser Phase so wenig wie möglich und so viel wie nötig umzusetzen, um lernen zu können und den MVP-Kandidaten zu verfeinern bis dieser „viable“ ist.
Artefakte:
- Test- und Lernstrategie
- Überblick über die Vorhandenen Ressourcen
- Design-Artefakte wie Pen&Paper Prototypen, Wireframes, Mockups, Conceptual Design, Information-Architektur, Interaction-Design, klickbare Prototypen aus Mockups oder Wireframes, etc.
- Produktinkremente
- Marketingmaterialien wie Flyer, Werbezettel, Landing-Pages, Werbevideos, Erklärungsvideos Croudfunding- Kampagnen etc.
Navigation
Überblick – Lean Productmanagement
- Zielkunden definieren und finden
- Verstehen der Kundenbedürfnisse
- Wertangebot definieren
- Setzen des Feature-Sets für das Minimal Viable Product
- Erstellen der Experimente/des Minimal Viable Products
- Testen der Experimente/des Minimal Viable Products mit dem Kunden
Quellen
1The lean Product-Playbook von Dan Olsen Mai 2015 Seite 115ff
2The lean Product-Playbook von Dan Olsen Mai 2015 Seite 117f
DigitalisierungsCoach 