Alle landeten hier. Niemand war zuständig.
16 % der Nutzer brachen bei ihrem zweiten Besuch ab. Das Onboarding hatte einen eigens dafür gestalteten Flow; er übergab die Menschen an ein Dashboard, das lange niemand angefasst hatte — sie kamen mit einer Datei in der Hand und bekamen eine leere Leinwand angeboten. Das Problem nicht als Usability-, sondern als Architekturfrage des Einstiegs zu verstehen, steigerte die aktivierten Nutzer um 11 %.
Director of Product Design & Research. Ich habe das Problem in den Verhaltensdaten entdeckt, gegenüber Product dafür argumentiert, bis es priorisiert wurde, das Briefing auf den Job der Nutzer ausgerichtet, die Designrichtung vorgegeben und die Ergebnis-Metriken verantwortet.
Die UX beim zweiten Besuch. 16 % der Nutzer brachen bei ihrem zweiten Besuch ab — zu verbessern war also die Oberfläche, auf die Menschen bei ihrer Rückkehr trafen, nicht das Onboarding, das ohnehin alle im Blick hatten.
Die Oberfläche, an die jeder Prezi-Nutzer nach dem Onboarding übergeben wird — auf einer Plattform mit über 160 Mio. Nutzern.
+11 % aktivierte Nutzer. Erstellte Präsentationen insgesamt +3 %.
Die Oberfläche am Ende aller anderen Flows.
Für das Onboarding war jemand zuständig. Für das, was danach kam, nicht.
Neue Nutzer starteten nicht auf dem Dashboard. Sie durchliefen einen eigens dafür gestalteten Onboarding-Flow — entworfen, gepflegt, beobachtet. Das Dashboard war der Ort, an dem dieser Flow sie losließ: am Ende des Onboardings oder beim nächsten Besuch.
Und genau dort verloren wir Menschen. 16 % der Nutzer brachen bei ihrem zweiten Besuch ab — nicht während des Onboardings, das alle beobachteten, sondern unmittelbar danach, auf der Oberfläche, die niemand im Blick hatte. Diese Zahl hat den Scope bestimmt: Zu verbessern war das Erlebnis beim zweiten Besuch.
der Nutzer brachen bei ihrem zweiten Besuch ab — für die meisten die erste Begegnung mit dem Dashboard.
Das Dashboard war lange nicht angefasst worden. Es bot drei Wege zum Erstellen, sortiert nach dem, was das Produkt ausgeben konnte: eine Präsentation, eine Infografik, ein Video. Darunter die Projekte, die man bereits erstellt hatte. Es war in der Sprache des Produkts organisiert, nicht in der der Nutzer — und niemand hatte diese Annahme seitdem hinterfragt. Als die KI-Generierung eingeführt wurde, erschien sie als Banner über genau diesen Kacheln — doch um sie zu nutzen, musste man weiterhin zuerst eine Vorlage wählen; im Vorlagen-Flow arbeitete jetzt lediglich KI im Hintergrund. Das fügte eine Fähigkeit hinzu, änderte aber nichts daran, wie Menschen ihren Einstieg fanden. Die übliche Lesart eines Abbruchs an dieser Stelle: ein Usability-Problem.
Das war es nicht. Die Verhaltensdaten sagten etwas Konkreteres: Menschen kamen mit vorhandenem Material — einer PowerPoint, einem PDF, einem Dokument, das sie bereits geschrieben hatten. Sie suchten keine Vorlage und keine leere Leinwand. Sie suchten einen Ort für ihre Datei.
Ein anderes Problem als das, das man uns gestellt hatte.
Niemand wacht morgens auf und braucht eine Infografik.
Diese Erkenntnis veränderte das Briefing. Die Frage lautete nicht mehr Wie machen wir dieses Dashboard einfacher?, sondern Wie gestalten wir die Einstiegsarchitektur rund um den Job neu, mit dem Menschen ankommen?
Das ist ein Jobs-to-be-Done-Reframe, und der Ausgangszustand zeigt genau, warum er nötig war. Das Dashboard war nach den Artefakten sortiert, die Prezi erzeugen konnte — Präsentation, Infografik, Video. Doch niemand kommt mit dem Wunsch nach einem Artefakttyp. Man kommt mit einem Job: Ich präsentiere das am Donnerstag vor dem Vorstand, und das Dokument habe ich schon geschrieben. Wer den Einstieg nach Ausgabetyp sortiert, verlangt von Menschen, ihren Job in die Kategorien des Produkts zu übersetzen, bevor das Produkt ihnen hilft. Wer ihn danach sortiert, wie sie ankommen, nimmt ihnen diese Übersetzung ab.
Das ist eine größere Behauptung als ein Usability-Fix, und sie brauchte Research, um zu tragen. Eine Usability-Anfrage in eine Architekturänderung umzudeuten, ist nur glaubwürdig, wenn man auf das Verhalten zeigen kann, das sie rechtfertigt, und sich vorab auf die Metrik festlegt, an der sie gemessen wird.
Die entscheidende Weichenstellung war nicht das visuelle Styling, sondern welche Jobs das Dashboard sofort verfügbar machte.
Drei Entscheidungen, ein bewusster Trade-off.
Wer etwas hervorhebt, stuft etwas anderes zurück.
- Dateiimport sichtbar machen. Der Weg über vorhandene Inhalte war nicht länger etwas, das man kennen musste, sondern etwas, das das Dashboard aktiv anbot.
- Einen stärkeren KI-Einstieg schaffen. Ein klarer, prominenter Zugang statt einer Fähigkeit, die man nur im Editor entdecken konnte.
- Vorlagen weniger betonen. Für jemanden, der mit einer Datei oder einem klaren Briefing kam, bedeutete eine Vorlage, bereits erledigte Arbeit noch einmal zu machen. Sie im Vordergrund zu lassen, kostete uns genau diese Nutzer.
Was die beiden hervorgehobenen Wege gemeinsam haben, zählt mehr als jeder für sich: Sie landeten im selben Eingabefeld. Eintippen, was man braucht, oder die vorhandene Datei ablegen — ein Feld, eine Frage, gestellt in der Sprache der Nutzer statt in der des Produkts. Das Erstellen nach Ausgabetyp wanderte in die Seitenleiste, wo es weiterhin allen dient, die es nutzen möchten.
Die dritte Entscheidung ist der Trade-off. Wir wussten, dass die Nutzung von Vorlagen sinken würde, und haben das akzeptiert — denn gemessen wurden wir an der Aktivierung, nicht an der Nutzung von Vorlagen. Weil wir das im Voraus benannt hatten, war das Ergebnis im Nachhinein eindeutig lesbar statt strittig.
Was sich tatsächlich verändert hat.
Aktivierte Nutzer. Das geschäftsrelevante Ergebnis — und die Metrik, an der die Arbeit gemessen wurde.
Erstellte Präsentationen insgesamt auf der Plattform.
Frühindikatoren erklären es. Aktivierung ist das Ergebnis.
Die Mechanismus-Metriken belegen, dass die Hypothese stimmte: Menschen konnten jetzt den Job angehen, mit dem sie ankamen — und taten es, deutlich. Datei-Starts und Uploads bewegten sich am stärksten, weil dieser Weg von versteckt zu primär wurde. Der KI-Einstieg legte zu, weil er von implizit zu explizit wurde.
Doch das sind Frühindikatoren, nicht die Antwort. Die aktivierten Nutzer stiegen um 11 %, die erstellten Präsentationen insgesamt um 3 % — darauf kommt es dem Business an, und für diese Zahl stehe ich mit meinem Namen ein.
Es zu erkennen, war nicht das Schwierige.
Die Daten waren früh eindeutig. Die Roadmap nicht.
Ich habe das Thema angesprochen, sobald ich es in den Daten sah. Bis es umgesetzt wurde, dauerte es deutlich länger: Das Dashboard gehörte niemandem, also stand es auf keiner PM-Roadmap — niemand wollte die Arbeit auf die eigene nehmen. Ich musste immer wieder dafür argumentieren, bis es ein Zuhause fand.
So sieht ehrlicherweise die meiste Arbeit auf dieser Ebene aus. Es ging nie darum, eine zögerliche PM zu überzeugen. Das Dashboard scheiterte nicht lautstark, und „die Oberfläche, auf der alle landen, löst den falschen Job“ lässt sich schwerer auf eine Roadmap bringen als ein Feature, nach dem bereits jemand gefragt hat — weil es mit niemandem beginnt, dessen Aufgabe es eindeutig ist. Die Designarbeit war echt, aber sie war nicht der Teil, der die meiste Beharrlichkeit erforderte.
Erst die Eingrenzung auf das Erlebnis beim zweiten Besuch machte es gewinnbar. Ein Vorschlag, den gesamten Bogen von der ersten Session bis zur Gewohnheit neu zu denken, wäre der ambitioniertere Pitch gewesen — und würde heute noch warten. Der Abbruch lag beim zweiten Besuch, also lag dort auch das Argument: eine Oberfläche, eine Metrik, ein Release.
Das Übertragbare daran: Einer Roadmap fehlt es nie an Dringendem. Das hier gehörte nicht dazu — das Dashboard brach nicht zusammen, also hatte es keinen natürlichen Anspruch auf Aufmerksamkeit. Um es priorisiert zu bekommen, brauchte es Argumente mit Evidenz, die stark genug war, um gegen alles Dringende in der Warteschlange zu bestehen. Wichtiges verdient sich seinen Platz neben Dringendem nur, wenn es von etwas gestützt wird, das schwerer zu widerlegen ist als ein Bauchgefühl.