Eine praktische Anleitung für den Product Canvas

Skip navigation

Eine praktische Anleitung für den Product Canvas

/ February 26, 2019

Es war einmal ein hoch angesehener Mann, der sagte: „Indem ihr euch nicht vorbereitet, bereitet ihr euch darauf vor, zu versagen.“ Dieser Mann war Graham Bell, und seine Aussage trifft auch heute noch zu.

Die meisten von Ihnen sind mit der Scrum-Methodik in Kombination mit der Mendix-Plattform vertraut. Und wahrscheinlich wissen die meisten von Ihnen auch, dass Scrum nichts darüber sagt, wie Sie sich auf Ihre Produkte vorbereiten sollen. Jedoch ist auch in einem agilen Umfeld eine gute Vorbereitung immer noch der Schlüssel zum Erfolg.

Wir bei Mendix hatten großen Erfolg mit der „Product Vision & Product Canvas“ Methodik, mit der wir unsere Projekte vorbereiten und uns für unseren ersten Sprint fertig machen. Lassen Sie uns deshalb nun mit der Verwendung des Product Canvas vertraut machen.

Planen Sie Veränderungen mit der Product Vision & Product Canvas Methodik

Ein häufiges Missverständnis in Bezug auf agile Methoden ist, dass keine Vorbereitung oder Dokumentation erforderlich ist und dass der Prozess auf magische Weise von den Ergebnissen und dem Feedback jedes Sprints geleitet wird. Das stimmt natürlich nicht. Im agilen Manifest heißt es: „Responding to change over following a plan“. Das bedeutet, dass Sie einen Plan haben sollten, der sich leicht an Veränderungen anpassen lässt, was wiederum zu einer angemessenen Vorbereitung führt.

Angemessen bedeutet in diesem Zusammenhang Folgendes:

  • Vorbereitung auf die Bereitstellung von Geschäftswerten.
  • Ausarbeitung einer klaren Vision für das Projekt.
  • Genügend Vorbereitung, um Prognosen zu ermöglichen.
  • Gerade genug Details, um mit dem ersten Sprint zu beginnen.

Alles, was darüber hinausgeht, ist zu viel des Guten. Denken Sie daran: Wir versuchen, einen „Plan“ zu erstellen, der sich leicht an Veränderungen anpassen lässt. Je größer und detaillierter der Plan, desto starrer ist er und desto schwieriger wird es, ihn zu ändern.

Aufgrund der erzielten Erfolge wird die Product Vision & Product Canvas Methodik von Mendix befürwortet. Trotzdem ist sie keineswegs die einzige Methodik auf dem Markt. Auch wenn man andere Methoden, wie zum Beispiel einen „Sprint Zero“ anwendet, wird dieser Blogbeitrag wertvoll sein. Denn er gibt einen Einblick in die Art von Fragen, die zur Vorbereitung auf ein Projekt beantwortet werden sollten.

Ein kurzer Blick auf das Product Vision Board

Der erste Schritt ist die Erstellung einer umfassenden Vision für das Projekt. Dies geschieht über das Product Vision Board. Da dieser Teil recht einfach ist, werden wir in diesem Blogbeitrag hierfür nicht allzu tief ins Detail gehen.

Product Vision Board

Grundsätzlich beantwortet das Product Vision Board die folgenden Fragen:

  • Warum erstellen wir die Anwendung?
  • Wer ist unsere Zielgruppe?
  • Was sind ihre Bedürfnisse?
  • Wie kann unser Produkt diese erfüllen?
  • Was sind dabei unsere Unternehmensziele?

Es dient auch als Input für den Product Canvas. Beide liegen in der Verantwortung des Product Owners. Das bedeutet jedoch nicht, dass dieser die ganze Arbeit machen muss. Es wird dringend empfohlen, bei Bedarf das Scrum-Team und Experten einzusetzen.

Der Product Canvas und sein Layout

Nachdem Sie Ihre Produktvision definiert haben, gilt es nun herauszufinden, wie Sie diese Vision umsetzen können. Anschließend werden Sie die folgenden Fragen beantwortet können:

  • Wer sind unsere Nutzer?
  • Was sind ihre Aufgaben und wie stellen wir uns vor, dass sie diese erfüllen?
  • Was sind relevante hochrangige Constraints?
  • Wie wird das Design in groben Zügen aussehen?
  • Was sind unsere Epics und Ready User Stories, um dies zu erreichen?

Abbildung 2 Product Canvas

Beim Vergleich der Fragen, die auf dem Product Canvas beantwortet werden, wird deutlich, dass das tatsächliche Layout des Product Canvas die Geschichte nicht in chronologischer Form erzählt. Aber um zu verstehen, wie man den Product Canvas erstellt, ist diese Chronologie sehr wichtig.

Chronologisches Layout des Product Canvas

Chronologisches Layout des Product Canvas

Die obige Abbildung zeigt die logischen Schritte zur Erstellung eines Product Canvas. Ein Schritt führt zum nächsten, beginnend mit einer Zusammenfassung der Produktvision, der Recherche über die tatsächlichen Nutzer des Produkts und die Erstellung von Personas bis hin zur Erstellung von Ready Stories für den ersten Sprint.

Beachten Sie, dass die Constraints parallel zu den User Journeys erstellt werden. Es ist auch möglich, dies vorher zu tun, da einige Constraints die User Journeys beeinflussen können.

Schritt 1 – Product Vision & Name

Die Product Vision Box ist nichts anderes als eine Zusammenfassung des Product Vision Board. Eine gute Möglichkeit, dorthin zu gelangen, ist zu versuchen, die Frage zu beantworten, wie man die wichtigsten Teile der Vision in nur einem oder zwei Sätzen beschreiben würde.

Das am meisten unterschätzte Element eines jeden (unternehmensinternen) Anwendungsentwicklungsprozesses ist der Name der Anwendung. Es kommt selten vor, dass man den ersten Sprint bereits mit einem guten Anwendungsnamen startet. Denn einen guten Namen zu finden, ist harte Arbeit. Er sollte einprägsam sein und dennoch eine starke Verbindung zur eigentlichen Anwendung haben. Keine leichte Aufgabe.

Der wichtigste Grund, von Beginn an einen guten Namen zu haben, ist die positive Wirkung auf alle Projektbeteiligten. Genau wie bei Personas, beginnen Menschen eine emotionale Bindung mit der Anwendung aufzubauen, die sie erstellen oder mitgestalten. Und wenn die Namensfindung nicht am Anfang erledigt wird, wird sie zu einer dieser „Kleinigkeiten“, die es nie an den Anfang der Prioritätenliste finden wird (sofern es sich nicht um eine externe Unternehmensanwendung handelt).

Schritt 2 – Erstellen von Personas

Bevor wir mit der Entwicklung von Funktionalitäten beginnen können, ist es essentiell zu verstehen, für wen und warum wir diese Funktionalitäten entwickeln. Dies geschieht durch User Research, die schließlich zu den Personas führt.

Beispiel für eine Persona

Beispiel für eine Persona

Im Grunde genommen ist eine Persona ein archetypischer Nutzer, der basierend auf Forschung erstellt wird. Wichtig ist hierbei, dass die Persona-Methodik zur Modellierung einer Gruppe von Nutzern kein kreativer Trick ist, den Marketingspezialisten und UX-Designer anwenden, sondern tatsächlich auf wissenschaftlichen Untersuchungen basiert, sowohl inhaltlich als auch in Bezug auf die Wirksamkeit der Nutzung. Sie helfen beim Aufbau von Empathie, bei der Fokussierung des Projekts, bei der Kommunikation und Konsensbildung im Projektteam sowie bei der Entscheidungsfindung und -verteidigung.

Darüber hinaus wird der Forschungsanteil dieses Schrittes dazu beitragen, alle Annahmen zu validieren, die bei der Erstellung der Project Vision getroffen wurden. Denken Sie daran, dass wir in der Project Vision angegeben haben, wer die Zielgruppe ist und welche Bedürfnisse sie hat. Dieser Schritt wird fast immer ohne Rücksprache mit den Nutzern durchgeführt. Das ist nicht unbedingt schlecht, aber eine Überprüfung der getroffenen Annahmen ist dennoch erforderlich. Wie bei der Behebung von Bugs ist der Zeit- und Arbeitsaufwand für die Änderung der Anwendung zu Beginn eines Projekts 10 bis 100 Mal höher als nach der Inbetriebnahme.

Bei einem schnellen Mendix-Projekt ist eine der Herausforderungen der Zeitmangel, der die Schaffung von (traditionellen) Personas, die auf quantitativer wissenschaftlicher Forschung basieren, unmöglich macht. Glücklicherweise bieten provisorische Personas eine Lösung, bei der als Recherche eine sehr begrenzte Anzahl von Interviews durchgeführt wird. Zugegebenermaßen dienen sie nur als Ausgangspunkt und sind weniger wertvoll als traditionelle Personas, aber sie können in ein bis zwei Tagen erstellt werden, was sie für Mendix-Projekte sehr attraktiv macht.

Schritt 3 – Erstellen von User Journeys

An dieser Stelle wissen Sie und Ihr Team genau, wer Ihre Nutzer sind, was ihre Bedürfnisse sind und was sie mit ihrer Anwendung erreichen wollen. Der nächste Schritt ist, die Lücke zwischen Ihren Personas und deren Aufgaben zu schließen und darzustellen, wie die Anwendung funktionieren wird. User Journeys bieten eine gute Möglichkeit dafür.

Sie können verschiedene Ebenen von User Journeys definieren, die jeweils ihre eigenen Vor- und Nachteile haben.

1. Customer Journeys

In der Welt des Marketings ist es üblich, die gesamte User Experience darzustellen, der die Anwendung angehört (die aber oft nur ein Teil der gesamten User Journey ist). Es kann gut sein, dass die Customer Journey bereits festgelegt ist. Falls ja, sollte diese als Teil der Vorbereitung verwendet werden.

Beispiel für eine Customer Journey

Beispiel für eine Customer Journey

2. Storyboards

Storyboards sind eine konkretere Methode, die stark an Graphic Novels oder Film-Storyboards erinnert. Sie bieten eine großartige Möglichkeit, nicht nur die Art und Weise zu definieren, wie ein Nutzer mit der Anwendung interagiert, sondern bei Bedarf auch den Kontext hinzufügen.

Beispiel für ein Storyboard

Beispiel für ein Storyboard

Beachten Sie, dass das obige Beispiel viel Kontext bietet. Das ist gut, aber nicht immer notwendig. Es ist auch möglich, Screens als Zeichnungen grob zu skizzieren und Text und Pfeile hinzuzufügen, um die Geschichte zu erzählen. Ein Storyboard muss auch nicht „schön“ sein. Es muss helfen, die User Journey zu gestalten und Ideen im Team zu kommunizieren.

3. User flows

Auf der untersten Abstraktionsebene befinden sich User Flows, die den Microflows sehr ähnlich sind. Sie stellen schematisch den Ablauf dar, den ein Nutzer zur Erfüllung einer Aufgabe nehmen kann.

Beispiel für einen User Flow

Beispiel für einen User Flow

User Flows sind einfach zu erstellen (PowerPoint ist zum Beispiel gut dafür geeignet) und sehr hilfreich bei der gemeinsamen Gestaltung der User Experience im Team.

Wir empfehlen, Storyboards zu erstellen, da sie deutlich mehr Kontext bieten und weniger relevante Details zunächst übersprungen werden können. Diese Details können zu einem späteren Zeitpunkt über die User Flows abgebildet werden.

Ein praktischer Hinweis hierzu: Erstellen Sie nicht jede User Journey, sondern konzentrieren Sie sich auf die wichtigsten. Schließlich handelt es sich um eine agile Arbeitsweise, das heißt: Übertreiben Sie die Vorbereitung nicht.

Schritt 4 – Definieren von relevanten Constraints

Wie bereits erwähnt, gibt es für Definition der Constraints keinen festgelegten Zeitpunkt. Es muss jedoch beachtet werden, dass einige Constraints die User Journeys beeinflussen können. Daher sollten diese vor oder parallel mit den User Journeys erstellt werden. Ein gutes Beispiel dafür wäre der Constraint, nur Netzwerkfunktionen innerhalb des physischen Büros nutzen zu können, was den Standort eines Nutzers zu einem sehr wichtigen Bestandteil jeder User Journey macht.

Ein Tipp zur Definition von Constraints: Es sollten nur die relevantesten bestimmt werden. Eine Liste von hundert Constraints ist kein produktives Werkzeug für die Vorbereitung, sondern ein kontraproduktives Hindernis. In den eigentlichen Sprints bleibt genügend Zeit, sich um die Definition weiterer Constraints zu kümmern.

Schritt 5 – Design

Der Design-Abschnitt ist der erste Schritt bei der Übersetzung der User Journeys in die zu erstellende Anwendung. Das Vorgehen bei diesem Schritt kann je nach Art der Anwendung, Kundentyp und Reife des Kunden in Bezug auf die Nutzung der Mendix-Plattform stark variieren.

Im Allgemeinen haben sich dabei mindestens vier Werkzeuge als sehr effektiv erwiesen.

1. Sitemaps (oder App-Maps)

Ein Werkzeug, das häufig beim Design und der Entwicklung von Websites verwendet wird, aber im Bereich Anwendungsdesign und –entwicklung etwas unbekannter ist. Im Wesentlichen wird es dafür eingesetzt, um die (Seiten-)Struktur der Anwendung abzubilden.

Beispiel einer Sitemap

Beispiel einer Sitemap

2. Wireframes

Wireframes sind Designskizzen von realen Screens, die sowohl in der Genauigkeit als auch im Abstraktionsgrad variieren. Dies ist den meisten Menschen bekannt. Da diese Phase als Vorbereitung auf das Projekt gedacht ist, sollte man dabei nicht allzu sehr übertreiben. Konzentrieren Sie sich auf das Design eines Systems und nicht auf einzelne Seiten. Finden Sie die Balance, indem Sie sowohl die Grundzüge der gesamten User Experiece entwerfen, als auch den ersten Sprint vorbereiten. Bei Wireframes können drei Stufen der Genauigkeit definiert werden: Low Fidelity, Medium Fidelity und High Fidelity. Dabei hat jede Stufe ihre eigenen Vor- und Nachteile.

Beispiel für Wireframes und verschiedene Stufen der Genauigkeit

Beispiel für Wireframes und verschiedene Stufen der Genauigkeit

Ähnlich wie bei User Journeys wird Low Fidelity als Minimum angesehen und mindestens ein paar Medium Fidelity Wireframes werden empfohlen. Obwohl am besten von einem UI- oder UX-Designer erstellt, kann eigentlich jeder Low Fidelity Wireframes erstellen. Es gibt dafür großartige Werkzeuge wie Balsamique, und selbst Stift und Papier oder ein Whiteboard können ausreichen, um loszulegen. Es geht immer schneller, mithilfe von Wireframing verschiedene Designs und Lösungen auszuprobieren, als nach dem Modellieren alles zu ändern. Darüber hinaus wird Ihnen ein guter Wireframe genau erklären, wie Sie bestimmte Pages aufbauen können.

3. Style Tiles

Die visuelle Sprache einer Nutzeroberfläche ist sehr wichtig für die Nutzerfreundlichkeit und das Branding der Anwendung. Diese visuelle Sprache zusammen mit der bestmöglichen Nutzerfreundlichkeit zu entwickeln, kann aber schnell zu viel werden. Sowohl in der Design-Phase als auch bei der Kommunikation und Diskussion des Designs im Team oder mit Stakeholdern. Das Entwerfen von Style Tiles hilft, die visuelle Sprache der Anwendung zu designen, ohne gleich die ganze Anwendung gestalten zu müssen.

Beispiel für eine Style Tile

Beispiel für eine Style Tile

Wie Sie im Beispiel sehen können, definiert das Design der Kachel klar die visuelle Sprache und das Branding der Anwendung, ohne uns die eigentliche Anwendung zu zeigen. Es ist eine sehr schnelle und effektive Methode, vor allem, wenn man mit mehreren Designs experimentieren möchte.

4. Design / Corporate-Identity-Richtlinien

Die meisten Unternehmen verfügen bereits über Richtlinien und Assets, die sich mit dem Design von Websites oder Anwendungen befassen. Falls vorhanden, sollten sie unbedingt in den Design-Bereich des Product Canvas aufgenommen werden.

Schritt 6 – Erstellen von Epics

An dieser Stelle kennen Sie Ihre Nutzer bereits recht gut und wissen, was diese mit der Anwendung erreichen möchten. Wie die Nutzer das erreichen können, haben sie ebenfalls entworfen und Sie haben dafür sogar schon ein Design-Framework geschaffen. Das heißt Sie haben jetzt alle Informationen, um Epics zu erstellen. Dies ist der erste Schritt, Ihr Anwendungsdesign in User Stories umzusetzen.

Epics können entweder als sehr große User Stories angesehen werden, die nicht in einem einzigen Sprint abgeschlossen werden können, oder sie müssen in separate User Stories unterteilt werden, um daraus eine „Ready“ User Story erstellen zu können. Meistens beschreibt ein Epic ein größeres Feature, das in Abschnitte zerlegt werden muss, um es zu realisieren.

Ein Beispiel wäre das Epic „Unseren Nutzern ermöglichen, ihre Lebensmittel online zu kaufen“. Dieses Epic lässt sich in verschiedene User Stories unterteilen, die sich mit der Auswahl von Lebensmitteln aus dem Shop, der Festlegung einer Lieferadresse und der Art der Bezahlung der Lebensmittel befassen.

Indem man Epics anstelle von reinen User Stories erstellt, kann man viel Zeit einsparen und dem Projekt mehr Aufmerksamkeit verleihen. Denn die Erstellung von Ready User Stories kann viel Zeit in Anspruch nehmen. Darüber hinaus kann man mit einem Backlog von 500 User Stories nicht wirklich gut arbeiten. Daher ist es besser, 10 Epics und 20 User Stories zu haben.

Schritt 7 – Erstellen von Ready Stories

Der letzte Schritt bei der Erstellung Ihres Product Canvas ist die Erstellung von Ready User Stories, die mindestens die ersten ein oder zwei Sprints abdecken.

Beachten Sie, dass eine Ready User Story bedeutet, dass sie mit der „Definition of Ready“ übereinstimmt. Da dies das erste Mal sein wird, dass Ready User Stories erstellt werden, ist es eine gute Idee, das gesamte Scrum-Team in diesen Schritt einzubeziehen.

Positive Erfahrungen von Mendix mit der Methode

Bei Mendix haben wir sehr gute Erfahrungen mit der Anwendung der Product Vision & Canvas Methodik gemacht. Wir haben diese für den Kick-off einer Reihe von Projekten verwendet. Wir haben sogar eine kompakte Version des Product Canvas für ein einwöchiges Proof-of-Concept-Projekt eingesetzt, in dem Storyboards, Sitemaps, Wireframes und Style Tiles enthalten waren.

Unsere Projektmanager, Scrum Master und Entwickler haben im Praxiseinsatz viele positive Erfahrungen mit der Methodik gemacht:

  • Selbst wenn nur relativ wenig Zeit in die Vorbereitung investiert wird, erhöht sich die Qualität des Endergebnisses deutlich.
  • Die Assets aus dem Product Canvas helfen dabei, den Projekt-Fokus zu finden, um die Anwendung schneller entwickeln zu können.
  • Gleich beim ersten Mal richtig machen: Beim Product Canvas besteht jeder Schritt aus Forschung, Experiment, Design und Reflexion. So wird bereits der Einstieg in die Entwicklungsphase verbessert, was wiederum zu wenig bis keinem Nacharbeiten während des Projekts führt.
  • Steigerung der Kommunikation und Effizienz im Team.

Aufgrund dieser positiven Erfahrungen gilt das Durchführen einer Vorbereitungsphase und insbesondere die Product Vision & Canvas Methodik inzwischen als Best Practice.

Fazit

Obwohl dieser Blogbeitrag den Product Canvas sehr detailliert beschreibt, ist das Wichtigste eigentlich die Vorbereitungsphase vor Beginn des ersten Sprints. Die Methodik funktioniert gut mit Mendix-Projekten, aber letztendlich geht es um den Inhalt und die Fragen, die in der Vorbereitungsphase beantwortet werden, sowie um den Nutzen für den Rest des Projekts.

Ein weiteres interessantes Detail ist, dass einige Teams sich dafür entscheiden, die Product-Canvas-Methodik oder Teile davon während des gesamten Projekts weiter zu verwenden, anstatt es nur zur Vorbereitung zu verwenden – zum Beispiel den Product Canvas als Teil einer Wand in ihrem Büro.

Mendix-Teams haben User Flows als Teil der „Definition of Ready“ für User Stories verwendet. Der Grund dafür: Aufgrund der schematischen Art des User Flows konnte das Team die User Story viel schneller und besser verstehen, als nur durch Text.

Aber vor allem ist es egal, ob ein Projekt klein oder groß, wenig oder hoch komplex ist: Genügend Zeit für die Vorbereitung führt immer zu einer zielgerichteten und effizienten Entwicklung sowie zu einer Qualitätssteigerung der eigentlichen Anwendung.

Weitere Informationen und Downloads

Neben den Vorlagen, die zum Herunterladen und Verwenden zur Verfügung stehen, ist das Mendix Expert Webinar zur Integration von UX-Projekten ein interessanter weiterführendes Video, da es den Product Canvas und seine Elemente innerhalb eines gesamten Projektzyklus platziert.

Laden Sie hier die Vorlagen herunter: