Dabei wird ein Produkt mit dem einfachsten Funktionsumfang – ein Minimum-Viable-Product – entwickelt, um Kundenbedarfe zu decken und Feedback zu ermöglichen. Viel zu häufig wird daraus jedoch eine Minimalversion, deren Funktionalität in Frage gestellt werden kann. Die UX bleibt häufig als erstes auf der Strecke.

Wie kommt es dazu? Und vor allem: Wie lässt sich das verhindern? Die Methode des MVP als nutzlos abzustempeln, ist zu kurz gedacht, zumal diese in der Regel in eine agile Methodik eingebettet ist und gemeinsam mit dieser betrachtet werden muss.

Das MVP ist ein kurzer Begriff für eine Entwicklungstechnik, die bei der Herstellung neuer Produkte eingesetzt wird, die an Kunden verkauft oder von diesen bedient werden. Das Produkt durchläuft nach seinem Markteintritt entweder einen schnellen Iterationsprozess, um einen wünschenswerten Zustand zu erreichen, oder aber die Entwicklung wird abgebrochen, wenn der Markt das Produkt für unbrauchbar oder unerwünscht hält.

Um den Entwicklungsprozess eines MVP zu visualisieren, werden häufig diese oder ähnliche Grafiken verwendet. Das Beispiel: Der Kunde will sich fortbewegen, also fängt die Produktentwicklung mit einem Skateboard an und macht es zunehmend schneller und besser, bis es schließlich ein Auto ist.

Doch auch wenn der Gedanke dahinter richtig sein mag, so ist diese Grafik aus UX-Sicht schlicht irreführend und falsch. Denn:

1. Niemand, der ein Auto will, gibt sich mit einem Skateboard zufrieden.
2. Gerade in großen Projekten mit mehreren Product-Ownern kann diese Betrachtungsweise dazu führen, es irgendwann viele tolle Fahrräder mit guter Musikanlage gibt, aber die Kunden immer noch auf das Auto warten.

Denn obwohl es möglich ist, ohne ein einheitliches Zielbild anzufangen, ist es trotz hoher Entscheidungsfreiheit bei den einzelnen agilen Teams sinnvoll, eine Vorstellung davon zu haben, wie ein mögliches finales Produkt aussehen könnte – und davon das MVP abzuleiten. Dabei ist ein solches Zielbild keinesfalls statisch, im Gegenteil. Seine kontinuierliche Anpassung verhindert die Schaffung vieler loser Enden durch Teams, die die Bedeutung ihres Teilbereichs über den der Gesamtfunktionalität stellen.

Unverzichtbar ist der stete Kontakt mit den Kunden beziehungsweise Nutzern. Denn ein MVP kann nur dann funktionieren, wenn deren Bedürfnisse immer wieder berücksichtigt werden und kundenzentriert gearbeitet wird. Denn ein rein funktionales MVP lässt zumindest ein Bedürfnis außer Acht: Menschen wollen ein Produkt leicht bedienen können. Selbst überragend konzipierte Funktionen müssen angenehm zu benutzen sein, um auf breite Akzeptanz zu stoßen. Wird die UX in den Hintergrund gedrängt, bedeutet dies eine Abkehr von der Kundenzentrierung. Und am Ende ist es auch die User-Experience, die für den Erfolg des Produkts von entscheidender Bedeutung ist.

Im linearen Wasserfallmodell, wie es früher Standard war, wird erst viel Forschung betrieben, dann über lange Zeit an Konzepten gearbeitet und diskutiert, bis die Verantwortlichen sicher sind, das Richtige zu entwickeln. Und dann möglicherweise feststellen, dass das Produkt am Kunden vorbeigeht oder es nach langer Konzept- und Entwicklungszeit bereits überholt ist. Bei dieser Methode ist die Rolle von Konzept und Entwicklung klar, nämlich linear. Entwickelt wird im Großen und Ganzen das, was im Konzept steht.

Im agilen Prozess können hingegen Vorschläge und Ideen auch direkt umgesetzt werden. Früher waren Entwickler in der Regel nicht diejenigen, die sich mit UX, Kunden oder auch Markenfit auseinandergesetzt haben. Befreit von alten Zwängen schlägt das Pendel heute mitunter zu sehr in die nun andere Richtung aus: Verstärkt durch den Effekt, dass in agilen Teams ein UI/UX-Designer häufig mit mehreren Entwicklern zusammenarbeitet, bekommt die technische Perspektive schnell Übergewicht. In Kombination mit Iterationen mag der Eindruck entstehen, gute UX basiere auf reinem Ausprobieren. Doch dies ist nicht der Fall. Gute UX baut auf einem Fundament aus empirischen Erkenntnissen, Standards und Fakten auf, bietet aber dennoch viele Wege zum Ziel.

Schnelligkeit steht im Vordergrund des Prozesses. Oft scheint es sogar, dass für richtiges Research und verschiedene Designoptionen kaum Zeit mehr ist. Der gesamte Prozess von der Recherche bis zum Design soll in der Zeit eines einzigen Sprints durchgeführt werden. Das ist aber mit grundlegenden Methoden und Strategien des UX Designs nur schwer vereinbar.

Kein leicht zu lösendes Problem, auch wenn UX-Designer bemüht sind, die Lücke zu schließen zwischen der Erstellung von Produkten, die nutzerfreundlich sind, und Produkten, die in Bezug auf Zeit, Budget und Technik realisierbar sind. Dazu kommt, dass UX-Designer schwerer in den agilen Prozess integriert werden können, da sie eben nicht programmieren. In der Praxis wird sich häufig mit einem Sprint 0 oder einem agilen Wasserfall beholfen, bei dem UX-Design grundsätzlich einen Sprint Vorlauf hat. Aber das ist eben nicht prozesskonform, und Sonderrollen können zu einem Gefühl der Ungleichbehandlung oder gar Bevormundung führen.

Eine der größten Herausforderungen besteht zusätzlich darin, dass sich eine ganzheitliche User-Experience eben nicht über Teil-Konzepte und -Funktionen herstellen lässt. Fühlen sich UX-Experten unverstanden und Entwickler nicht gleichberechtigt, führt im schlimmsten Fall dazu, das die User-Experience im Prozess als Störfaktor wahrgenommen wird.

Ein Schlüssel liegt sicher in der Kommunikation. Ein ständiger Austausch im Team, ein frühzeitiges Einbeziehen des gesamten Teams in UX/UI-Themen, eine Kommunikation auf Augenhöhe sowie vor allem Offenheit gegenüber den Belangen anderer überwinden so manche Hürde. Hierbei sollte man sich nicht davor scheuen, feste Zeiträume für Themengebiete zu definieren, um sich zu besprechen und Verständnis für die Position aller Beteiligten zu erzielen.

Zudem hilft es, sich auf die Ideen, die hinter MVP und agilen Prozessen stecken, zu besinnen und diese nicht nach eigenem Vorteil neu zu definieren. Werden die Methoden darauf ausgerichtet, schnell, häufig und immer wieder Feedback von Nutzern/Kunden zum Produkt zu erhalten, werden sie funktionieren. Nur eine kundenzentrierte Denk- und Arbeitsweise führt zu einem einheitlichen Verständnis über die künftig notwendigen Entwicklungen. Alle anderen Ansätze sind rein Meinungs- oder Hierarchie-gesteuert.

Yona Gidalevitz schlägt in Usabilitygeek einen angepassten Zyklus vor, in dem UX Designer an MVP arbeiten können:

UX → Measure → Learn → Repeat

Im Gegensatz zum traditionellen MVP-Zyklus von:

Build → Measure → Learn

Damit wird ein wesentlicher qualitativer Unterschied im traditionellen Zyklus der MVP-Iteration aufgezeigt und behoben. Es mag auch helfen, Features oder Funktionen aus der MVP-Definition zu streichen. Übrig bleibt die Frage: Wie sieht das Minimum aus, damit es die Nutzer akzeptieren und gerne verwenden?

Denn fest steht: Weder agile Methoden noch der MVP-Ansatz lösen alle Probleme und Herausforderungen im Entwicklungsprozess. Aktuell sind sie vermutlich dennoch die besten Vorgehensweisen, die wir derzeit haben – auch wenn einige Anpassungen von vorgegebenen Prozessen wie zum Beispiel Scrum notwendig sind, um die eigene Struktur oder Produktentwicklung abzubilden. Denn nur kundenzentriertes Arbeiten und das Überwinden technischer Hürden und Restriktionen, wie sie nun mal Projektalltag sind, führt zu guten Produkten und Interfaces.