1. Einleitung
A/B-Tests durchzuführen ist kompliziert. Als Conversion-Verantwortlicher gilt es viele verschiedene Prozesse zu koordinieren. In den meisten Fällen sind auch noch viele verschiedene Personen an den Prozessen beteiligt:
- Conversion Manager
- Webanalyst
- Grafiker
- Frontend-Entwickler
- Backend-Entwickler
- möglicherweise Texter
- Vorgesetzte, die Tests freigeben
- Corporate-Design-Abteilung, die Tests freigibt
Die häufigste Art der Abstimmung zwischen den einzelnen Parteien ist wohl per E-Mail. Von der ersten Idee und Analyse für einen Test bis zur Auswertung werden also gerne mal über 100 E-Mails ausgetauscht. Die Koordination per E-Mail hat jedoch zwei entscheidende Nachteile:
- Es ist zeitaufwendig und kompliziert, eine Übersicht über den Fortschritt der Vorbereitung eines Tests zu führen. Dies führt zu längeren Wartezeiten bis ein Test starten kann.
- Beteiligte eines Tests müssen oft lange nach Informationen suchen und möglicherweise darauf warten, bis ihnen die entsprechende E-Mail weitergeleitet wird.
In diesem Praxisguide stellen wir Kanban als eine alternative Form des Projektmanagements für A/B-Tests vor. Das Versprechen von Kanban für die Vorbereitung von A/B-Tests lautet, dass beide gerade beschriebenen Probleme mit Leichtigkeit beseitigt werden.
Die restlichen Kapitel beschreiben diese Themen:
- Grundlagen und -prinzipien von Kanban (2. Kapitel)
- Anwendung von Kanban auf das Projektmanagement von A/B-Tests (3. Kapitel)
- Wie etablierte Testing-Prozesse mit Kanban abgebildet werden können (4. Kapitel)
2. Was ist Kanban?
2.1 Ursprünge
Kanban (Japanisch für „Signalkarte“) kommt aus der Autoproduktion und wurde schon 1947 vom Autohersteller Toyota entwickelt, um nur so wenige Teile wie tatsächlich benötigt, zu produzieren. In der Produktionshalle ist ein Mitarbeiter für die Montage der Türen verantwortlich und holt diese jeweils vom entsprechenden Stapel. Sobald die Türen zur Neige gehen, wird dies auf einer Signalkarte notiert. Auf diese Weise kann identifiziert werden, wie viele Teile tatsächlich benötigt werden.
2007 wurde Kanban von David Anderson für die Software-Entwicklung adaptiert und gehört in die Familie der agilen Methoden. Diese Adaptierung wenden wir in diesem Praxisguide auf A/B-Tests an.
Die Adaptierung zur Software-Entwicklung wurde wiederum auf viele andere Bereiche angewandt:
- Planung von Marketingaktionen
- Optimierung von HR-Maßnahmen
- Bei ConversionBoosting planen wir sogar die Veröffentlichung unserer Praxisguides und Dokumente per Kanban.
2.2 Grundprinzipien von Kanban
Kanban lässt sich anhand zentraler Grundsätze erläutern. Vier dieser Prinzipien lauten.
2.2.1 „Visualisiere den Fortschritt der Arbeit“
Kanban setzt zur Visualisierung des Fortschritts auf ein sogenanntes Kanban-Board. Die unterschiedlichen Schritte eines Projektes werden, zum Beispiel, auf einem Whiteboard oder einfach einer weißen Wand festgehalten.
Das Board ist wiederum eingeteilt in mehrere Spalten. Jede Spalte entspricht einer Phase eines Projekts. In der einfachsten Ausführung lauten die drei Spalten:
In jeder Spalte können nun Karten platziert werden, welche von links nach rechts „wandern“, sobald sie die jeweilige Phase erreichen:
|
To do
|
Doing
|
Done
|
|
Weitere Klebezettel kaufen
|
Praxisguide fertig lesen
|
Einleitung des Praxisguides lesen
|
|
|
|
Kanban-Board anlegen
|
Neben der eigentlichen Aufgabe können auf Karten viele weitere Informationen platziert werden. Mehr dazu im nächsten Kapitel.
2.2.2 „Miss und steuere den Fortschritt der Arbeit“
Da auf dem Kanban-Board alle Aufgaben und deren Status übersichtlich markiert sind, ist das zweite in der Einleitung angesprochene Problem sofort behoben. Als Conversion-Verantwortlicher sieht man auf einen Blick, wie weit die Vorbereitungen für verschiedene Tests sind und welchen Personen die Aufgaben zugeteilt wurden.
Da Veränderungen an Boards aufgezeichnet werden, kann der Fortschritt eines Projekts außerdem sehr einfach analysiert werden. Beispielsweise kann überprüft werden, wie lange eine Karte in der Spalte „Doing“ verbracht hat, das heißt, wie langen auf diesen Schritt gewartet werden musste.
2.2.3 „Begrenze die Menge angefangener Arbeit“
Um angefangene Arbeit auch fertigzustellen, sollte die Anzahl der Karten in der Spalte „Doing“ – auch „work in progress“ (WIP) genannt – begrenzt werden. Auf diese Weise sind nicht zu viele Aufgaben vorhanden, in die zwar Arbeit investiert wurde, die jedoch kein unmittelbares Ergebnis bringen.
2.2.4 „Bilde bestehende Prozess ab“
Statt neue Prozesse einzuführen, bildet Kanban die bestehenden ab und bietet die Möglichkeit diese zu visualisieren. Entsprechend ist die Beschreibung des Testing-Prozesses auch nicht Teil dieses Praxisguides.
2.3 Implementierungen von Kanban
Neben einer physischen Tafel oder Whiteboard gibt es unterschiedliche Software, um Kanban elektronisch umzusetzen. Dazu gehören beispielsweise:
Die meisten der Tools sind entweder kostenfrei (jedenfalls in der Basisversion) oder bieten mindestens eine 30-Tage-Testversion. Wählen Sie sich also nach der Lektüre des Praxisguides die passende Software aus.
3. Ein Kanban-Board für A/B-Tests
Vor allem das erste Prinzip „Visualisiere den Fortschritt der Arbeit“ ist für A/B-Tests hilfreich. In diesem Kapitel beschreiben wir deshalb, wie ein Kanban-Board zur Vorbereitung von A/B-Tests aussehen kann.
Die Screenshots stammen aus Trello (der wahrscheinlich einfachsten Implementierung von Kanban). Das Board und die Prozesse können jedoch auch mit jeder anderen Implementierung (siehe Kapitel 2.3) oder einem Whiteboard umgesetzt werden.
3.1 Spalten
Jede Spalte eines Boards entspricht einer Phase der Testvorbereitung. Diese Spalten sind empfehlenswert:
- Ideen und Hypothesen
- Konzeption
- Grafik
- Entwicklung
- Qualitätssicherung
- Freigegeben (wartet auf Start)
- Laufende Tests
- Beendet
Spalten in Trello (eigentlich nebeneinander)
Ideen werden nun auf Karten in die erste Spalte eingefügt und „wandern“ dann mit der Zeit von dort bis zu „Beendet“.
Wie in Kapitel 2.2.2 beschrieben, sollte die Anzahl der Karten pro Spalte beschränkt sein. (Ausnahmen bilden natürlich Ideen und Beendet.) Denn jeder Tag ohne aktiven Test ist eine verlorene Chance darstellt, Erkenntnisse über Besucher zu sammeln und/oder Conversion Rate und Umsatz zu steigern. Es ist deshalb wichtig, dass die Pipeline für neue Tests (Spalte Freigegeben) immer gut gefüllt ist und die Vorbereitungen in den anderen Phasen/Spalte entsprechend getroffen werden. Wenn also beispielsweise die Spalte Konzeption schon sehr voll ist, sollten die Konzepte in grafische Entwürfe umgesetzt werden, statt weitere Konzepte zu entwickeln.
3.2 Karten
Nun zu den wichtigsten Bestandteilen eines Kanban-Board: den einzelnen Karten. Diese Karte aus Trello soll als Beispiel dienen:
3.2.1 Name der Karte
Jede Karte sollte nach der zu testenden Hypothese oder Idee benannt werden. In der ersten Spalte könnte beispielsweise die Karte „Vertrauen im Checkout erhöhen“ platziert sein.
„[allgemein]“ verweist auf unsere Gliederung von Ideen und Hypothesen in drei Kategorien:
- Ideen beziehen sich auf Seitentypen oder Prozesse. Ein Beispiel ist „Die Bounce Rate auf unseren Landing Pages ist sehr hoch.“ Diese Ideen lassen sich nur schwer in eine Hypothese überführen, die verifiziert oder falsifiziert werden könnte. Es muss noch Arbeit investiert werden, um herauszufinden, welche Elemente oder Eigenschaften des Checkouts problematisch sind und getestet werden sollten.
- Auf eben dieser Elemente oder Eigenschaften bestimmter Seitenkategorien beziehen sich die allgemeinen Hypothesen. Ein Beispiel hierfür ist „Besucher erhalten auf unseren Landing Pages nicht genügend Informationen.“ Im Gegensatz zur vorherigen Idee wird hier das Problem genannt. Wir nennen diese Ideen „allgemeine Hypothesen“, da sie sich zwar auf ein bestimmtes Elemente bzw. eine bestimmte Eigenschaft (Informationsgehalt) der Website beziehen, jedoch noch keine konkrete Lösung anbietet. In den meisten Fällen wird es mehrere mögliche Lösungen – und damit Testvarianten – geben.
- Diese Lösungen sind dann in den konkreten Hypothesen enthalten. Zwei konkrete Hypothesen zur vorigen allgemeinen Hypothesen könnten beispielsweise so lauten:
- a.Zusätzlicher erklärender Text führt zu einer Steigerung der Conversion Rate.
- b.Ein Erklärvideo führt zu einer Steigerung der Conversion Rate.
Diese Unterscheidung hilft Karten in der ersten Spalte zu einem einzelnen Test zusammenzufassen (siehe Kapitel 4.2.2).
3.2.2 Beschreibungstext
Im Beschreibungstext sollten alle weiteren Informationen zu einer Hypothese notiert werden. Im Laufe der „Reise“ von links nach rechts werden diese Informationen immer weiterwachsen. Im nächsten Kapitel besprechen wir, welche Informationen in welche Phase notiert werden sollten.
3.2.3 Kategorisierung von Karten
Entsprechend der Einteilung einer Website können Karten verschiedene Kategorien zugewiesen werden. In unserem Beispiel für einen Online-Shop sind diese Kategorien Produktdetailseite, Kategorieseite, Startseite, Landingpages, Checkout und anderes. Jede Kategorie bekommt eine eigene Farbe.
Die Kategorisierung hilft, einen schnellen Überblick darüber zu bekommen, für welche Teile einer Website gerade die meisten Tests vorbereitet werden.
4. Prozesse für A/B-Tests mit Kanban
In diesem letzten Kapitel zeigen wir nun, wie die Spalten und Karten des vorigen Kapitels eingesetzt werden können, um bestehende Prozesse mit Kanban abzubilden und zu verbessern.
4.1 Allgemeine Prozesse
Zuerst zu den allgemeinen Prozessen, die in allen Phasen/Spalten eines Projekts vorkommen.
4.1.1 Abstimmung zwischen Teammitgliedern
In der Einleitung wurde das große Problem der Kommunikation per E-Mail erläutert: Beteiligte eines Tests müssen oft lange nach Informationen suchen und möglicherweise darauf warten, bis ihnen die entsprechende E-Mail weitergeleitet wird.
Über Themen spezifischer Karten sollte deshalb direkt „auf“ diesen Karten kommuniziert werden. Bei Trello können andere Benutzer einfach mit einem „@“ angesprochen werden. Die anderen Tools bieten die gleichen Möglichkeiten:
Wenn die komplette Kommunikation auf der Karte erfolgt, ist diese sogleich dokumentiert und für alle Benutzer (mit den entsprechenden Rechten) sichtbar.
4.1.2 Testvorbereitung voranbringen
Das Grundprinzip von Kanban – das Verschieben von Karten weiter nach rechts – findet natürlich auch bei der Vorbereitung von A/B-Tests seine Anwendung. Sobald eine Aufgabe erledigt ist, wird die Karte per Drag-and-Drop nach rechts verschoben.
Auch Freigabeprozesse werden durch das Weiterschieben von Karten abgebildet. Das heißt, erst wenn eine Freigabe erfolgt ist, darf eine Karte zum Beispiel von Konzeption zu Grafik verschoben werden.
4.1.3 Karten Anderen zuweisen
Sobald ein Teammitglied seine Aufgabe, zum Beispiel die grafische Umsetzung eines Wireframes, erfüllt hat und die Karte nach rechts verschoben hat, sollte die Karte wieder einem anderen Benutzer zugewiesen werden. Dieser wird per E-Mail über seine neue Zuständigkeit in Kenntnis gesetzt.
Nach der grafischen Umsetzung geht eine Karte normalerweise an den Conversion Manager zur Freigabe bei Vorgesetzen zurück. Andere Prozesse können aber natürlich auch definiert werden.
4.1.4 Deadlines setzen
Jeder Karte sollte eine Frist zugewiesen werden, bis wann die jeweilige Aufgabe erledigt werden muss. In Trello sieht dies beispielsweise so aus:
Die Einhaltung von Deadlines kann nun vom Conversion-Verantwortlichen sehr einfach überprüft werden. Dazu wird einfach der Kalender mit allen Terminen geöffnet:
4.1.5 Priorisierung von Hypothesen und Aufgaben
Nicht jede Karte ist gleich wichtig. Hypothesen mit höherem geschätztem Einfluss sollten stärker vorangetrieben werden.[1] Diese Tatsache sollte unbedingt im Kanban-Board berücksichtigt werden.
Aber auch in anderen Phasen, nicht nur der Konzeption, kann sich die Priorität von Karten ändern. Wenn beispielsweise klar wird, dass die Qualitätssicherung sehr umfangreich wird, könnte die entsprechende Karte herunterpriorisiert werden.
Mögliche Umsetzungen der Priorisierung sind:
- Jeder Karte wird eine bestimmte Anzahl Sterne zugewiesen (Trello besitzt diese Funktion nicht)
- Je höher eine Karte angeordnet ist, desto höher wurde sie priorisiert
Beispiel für eine Priorisierung mit Sternen bei SwiftKanban
4.2 Die einzelnen Schritte der Vorbereitung eines A/B-Tests
Was gibt es speziell bei der Abbildung der einzelnen Schritte der Vorbereitung eines A/B-Tests in Kanban zu beachten?
4.2.1 Ideen und Hypothesen
Im Beschreibungstext sollte unbedingt die Motivation für die Hypothese notiert werden. Wie kam die Idee zustande? Welche Daten wurden bei der Analyse verwendet? Entweder einen entsprechenden Link, einen Screenshot oder eine Datei anhängen!
Auch die Person, welche die Idee vorgebracht hat, sollte für Rückfragen inklusive Kontaktdaten notiert sein.
4.2.2 Konzeption von Tests
In der Konzeptionsphase ist vor allem der Beschreibungstext einer Karte wichtig. Hier sollten diese Informationen hinzugefügt werden
- Beschreibung von Testvarianten in Textform
- Links zu Wireframes
- KPIs
Wenn mehrere Hypothesen in der Konzeptionsphase zu einem Test zusammengefasst werden, sollte dies auch im Kanban-Board repräsentiert werden. Dazu können die Hypothesen in vielen Tools als „Unterkarten“ in eine übergeordnete Karte integriert werden.
4.2.3 Grafik
Sobald grafische Entwürfe fertig gestellt sind, sollten diese an die entsprechende Karte angehängt werden.
4.2.4 Entwicklung [2]
In den Beschreibungstext sollten die Links zu den fertig programmierten Varianten im Testing-Tool eingefügt werden.
4.2.5 Qualitätssicherung [3]
In der Phase der Qualitätssicherung sollten neben der Dokumentation der Qualitätssicherung (möglicherweise als Excel-Tabelle) auch Screenshots der fehlerhaften Testvarianten hochgeladen werden.
4.2.6 Freigegeben (wartet auf Start)
Keine besonderen Prozesse.
4.2.7 Laufende Tests
Setzen Sie Deadline in dieser Spalte auf den Tag, an den der Test laut Schätzung statistisch signifikante Ergebnisse erzielt.
4.2.8 Tests beendet
In der letzten Phase gibt es keinen eigentlichen Prozess für A/B-Tests, der mit Kanban umgesetzt werden soll. Stattdessen sollte jetzt analysiert werden, wie lange die einzelnen Schritte des Projekts benötigt haben, um Verbesserungsmöglichkeiten zu finden.
