mvp_head.png

Stolpersteine bei der MVP Entwicklung

  • Clarissa KĂŒchler

In einem Post habe ich beschrieben, welche Faktoren bei der Bestimmung des Umfangs eines MVP zu berĂŒcksichtigen sind. Der Einbezug von Nutzern und deren Feedback ist essentiell, um diesen sinnvoll definieren. In der Umsetzung gibt es – meiner Erfahrung nach – einige Stolpersteine.

Die Technik Brille

Die Gefahr (insbesondere wĂ€hrend Sprints im agilen Vorgehen) ist, dass der Fokus zu stark auf der technischen Entwicklung liegt. Dies geschieht insbesondere, wenn es an die Detailarbeit geht. Dann treten die BedĂŒrfnisse der Nutzer in den Hintergrund und der Fokus liegt auf der technischen Umsetzung.

Abhilfe schafft ein gutes Projekt Setup: die Definition und spĂ€ter die fortwĂ€hrende RĂŒckbesinnung, Reflektion und Verfeinerung von Personas und User Journeys helfen Produkte zu entwickeln, die wertgeschĂ€tzt werden. Dies bedeutet, dass User Experience Designer als “Advokat der Nutzer” auch wĂ€hrend der Entwicklungs- und Implementierungsphase involviert sind. Als Experten können sie wertvollen Input liefern oder geeignete Tools und (Test-)Methoden definieren, um (Teil-)Ergebnisse zu verifizieren.

mvp-pyramide

Jussi Pasanen in Dan Olsen in “The Lean Product Playbook” und Aaron Walter’s “Designing for Emotion”

Das Ja-Aber-Syndrom

Eine weitere Barriere im Projektteam (bestehend aus Auftraggeber und Umsetzungsteam) sind mögliche InterpretationsspielrĂ€ume: selbst bei klaren BedĂŒrfnissen der Nutzer gibt es verschiedene Möglichkeiten wie diese digital bedient und umgesetzt werden. Unterschiedliche Meinungen innerhalb des Teams und zwischen Disziplinen fĂŒhren zu Diskussionen, die in einer unterschiedlichen Priorisierung der Funktionen resultieren. Dies erschwert die Konzentration auf Kernfunktionen bzw. deren Ausgestaltung.

Der Ausweg ist, den Nutzer mit einzubeziehen und Optionen zu testen, um Entscheidungen nicht auf Basis von Meinungen, sondern tatsĂ€chlichen Erkenntnissen zu treffen. Meist ist dies einfach ĂŒber bspw. Wireframes, Papierprototypen oder A/B- Testing möglich.

Der Business-Ziele-Tunnel-Blick

FĂŒr Auftraggeber ist es schwierig, den Perspektivwechsel von einer Innen/ Unternehmens- zur einer Aussen-/Kundensicht zu vollziehen.

Bspw. setzt sich ein Unternehmen das Ziel, Daten ĂŒber Nutzer zu sammeln. Es möchte möglichst viel ĂŒber die Nutzer erfahren. Technisch gesehen kein Problem: bei der Call-To-Action, d.h. der Aufforderung, bspw. einen Newsletter zu abonnieren bedeutet dies lediglich, ein paar weitere Inputfelder neben der E-Mail Adresse zu implementieren. Gleichzeitig stellen diese Felder eine HĂŒrde dar, die verhindert, dass der Nutzer sich registriert. Es gilt, genau zu ĂŒberlegen wann und wo Daten abgefragt werden und ob der Nutzer bereit ist, die Daten preis zu geben. Aufwand und Ertrag mĂŒssen sich die Waage halten: Wieso soll ich meine Telefonnumer fĂŒr einen Newsletter preisgeben? Oh, nee, wollen, die mich anrufen? Die Conversion ist dann am höchsten, wenn ein Formular so simpel wie möglich ist: “Every time you cut a field or question from a form, you increase its conversion rate” (Nielsen Group).

Wichtig ist, immer wieder einen Abgleich zu schaffen zwischen den Absichten eines Unternehmens und den BedĂŒrfnissen der Nutzer. Ein Nutzer-Zentriertes-Vorgehen stellt sicher, dass der Nutzer nicht vergessen geht. Business-Ziele und Nutzer-BedĂŒrfnisse mĂŒssen immer wieder austariert und in Einklang gebracht werden.

Die Budget Sorge

Es kommt vor, dass Iterationen gefĂŒrchtet oder nicht gewĂŒnscht sind und der Wunsch vorherrscht, die richtige Lösung ad hoc zu definieren. Die implizite Sorge, die dahinter steht ist, Budget zu “verbrennen”, wenn Dinge zweimal “in die Hand genommen werden”.

Aufgrund der KomplexitÀt von digitalen Produkten und Anwendungen, ist es meist schwierig alle Komponenten beim Start eines Projektes zu kennen und zu identifizieren. Oftmals treten Schwachstellen erst im Laufe des Projektes auf. Ad hoc ist also hÀufig ohnehin eine Wunschvorstellung.

WÀhrend des Entwicklungsprozesses hingegen ist es einfach, mithilfe Nutzer Feedbacks Schwachstellen zu eliminieren. Werden diese erst spÀter entdeckt, ist der Aufwand um ein vielfaches höher. Beim MVP Ansatz setzen wir eine gewisse Fehlertoleranz voraus. Iterationen sind als positiv und nicht als Blocker zu verstehen. Sie verschwenden keine Ressourcen, sondern generieren Mehrwert und Output.

Entwicklung ohne Hindernisse

Der Weg, genannte Stolperstein zu vermeiden:

  • Vermeiden der Technik Brille: User zentriertes Vorgehen, RĂŒckbesinnung und Verfeinern von Personas und User Journeys wĂ€hrend des gesamten Projektverlaufs.
  • Vermeiden des Ja-Aber Syndroms: Eine grundsĂ€tzliche Bereitschaft zu iterieren muss bei allen Beteiligten braucht es: Statt Ja-Aber ist es sinnvoller Ja-Und zu argumentieren. So werden Probleme konstruktiv diskutiert und “Meinungsfronten” vermieden.
  • Vermeiden des Business-Ziele-Tunnel-Blick: Das gemeinsame Priorisieren von Funktionen und verbundenen Task aufgrund von “User Insights” schafft Sicherheit und ermöglicht ein fokussiertes den Business-Zielen dienliches Projektvorgehen. Es verhindert, dass Business Ziele und NutzerbedĂŒrfnisse auseinander triften.
  • Vermeiden der Budget Sorge: Mind Set, das Fehler zulĂ€sst und Iterationen als gewinnbringend und zielfĂŒhrend akzeptiert.

Tell us what you think