Ein schwüler Nachmittag im Juli. Ich sitze vor einem 40-seitigen Research-Bericht und weiß eigentlich schon beim Scrollen, dass mein Team nur die Executive Summary überfliegen wird. Wir machen danach genau die gleichen Annahmen wie vorher. 62 Prozent meiner Arbeitswoche verbringe ich laut Kalender in Meetings, und oft fühlt es sich so an, als würden wir nur Worte stapeln, ohne dass etwas hängen bleibt.
Ende 2025 habe ich aus purer Verzweiflung angefangen, meine Notizen visuell zu strukturieren. Nicht, weil ich zeichnen kann – ich habe null Vorkenntnisse –, sondern weil ich meine eigenen Protokolle nicht mehr lesen konnte. In der Discovery-Phase Anfang Juni wurde mir klar: Wenn ich die Schmerzen unserer Nutzer nicht sichtbar mache, bleiben sie abstrakte Tickets im Backlog.
Warum Hochglanz-Dashboards oft lügen
Wir neigen dazu, Research-Ergebnisse in hübsche Balkendiagramme und polierte Slides zu gießen. Das Problem dabei: Diese Ästhetik glättet die Kanten. Die rohe Frustration eines Nutzers, der unser Interface nicht versteht, verschwindet hinter einem Prozentwert. Ich habe die Erfahrung gemacht, dass ungeschönte Skizzen die Dringlichkeit viel besser vermitteln. Eine krakelige Zeichnung eines unglücklichen Nutzers wirkt im Stakeholder-Review Wunder.
Mitte Juli, nach zehn intensiven User Interviews, saß ich an der Auswertung. Wir halten uns oft an den Standard der Nielsen Norman Group, dass fünf Nutzer meist 85 Prozent der Usability-Probleme aufdecken. Ich hatte also genug Material. Statt das nächste Deck zu bauen, griff ich zu einem einfachen Blatt Papier – Standardmaß, 210mm x 297mm. Ich entschied mich, die drei größten Pain Points in Icons zu übersetzen: ein gebrochenes Herz, eine tickende Uhr und ein Labyrinth.
Es ist dieser Moment, in dem man Stakeholder Interviews visuell protokolliert, anstatt nur mitzuschreiben, der den Unterschied macht. Man fängt an, Muster zu sehen, die in reinem Text untergehen.
Das Experiment im Refinement Meeting
Ende August stand das Quarterly Planning an. Ich brachte kein 20-Folien-Deck mit. Ich hatte nur dieses eine A4-Blatt dabei. Als ich an der Reihe war, klebte ich es an das Whiteboard. Ich spürte ein leichtes Zittern in der Hand, als ich mein handgezeichnetes Labyrinth-Icon direkt neben die High-Fidelity-Mockups pinnte. Es sah irgendwie fehl am Platz aus zwischen all den perfekten Pixeln.
Ich nahm einen frischen Marker. Das quietschende Geräusch auf dem Whiteboard war das einzige Geräusch im Raum. Alle schwiegen. Ich beobachtete, wie die komplexe User Journey, über die wir seit Wochen diskutierten, zu einer einfachen, verworrenen Linie wurde. Ich zeichnete das Labyrinth nach. Die Stille hielt an, bis unser Lead Engineer plötzlich auf das Labyrinth deutete.
Er sagte: "Okay, jetzt sehe ich es auch. Der Checkout-Flow ist kein Prozess, es ist ein Irrgarten." Diese Erkenntnis hatten 40 Seiten Text in zwei Monaten nicht ausgelöst. Visuelle Notizen zwingen uns zur Reduktion auf das Wesentliche. Es geht nicht um Kunst, sondern um Klarheit. Wer sich mit der Dual Coding Theory beschäftigt, versteht schnell, warum das funktioniert: Wir verarbeiten visuelle und verbale Informationen über verschiedene Kanäle. Kombinieren wir sie, bleibt die Information hängen.
Struktur schlägt Talent
Beim Sketchnoting im PM-Alltag gilt die 80/20-Regel: 80 Prozent des Wertes kommen aus der Struktur und der Bedeutung, nur 20 Prozent aus der künstlerischen Ausführung. Mein Labyrinth war eigentlich nur ein Haufen wirrer Striche. Aber es war ein Symbol für ein Problem, das wir vorher ignoriert hatten. Manchmal hilft es auch, wenn man die Software Architektur visuell darstellt, um zu verstehen, warum der Nutzer im Labyrinth landet.
Research zu visualisieren bedeutet, das Problem so sichtbar zu machen, dass es unmöglich wird, es zu ignorieren. Es ist unangenehm, ein Blatt Papier mit einem fetten Fehlersymbol vor sich liegen zu haben, während man über neue Features diskutiert. Es ist ein Korrektiv gegen den Optimismus-Bias im Produktmanagement.
Ich merke immer wieder, dass diese simplen Zeichnungen die Kommunikation im Team verändern. Wir reden weniger aneinander vorbei. Früher habe ich mich oft gefragt, warum meine Protokolle niemand liest. Heute weiß ich: Sie waren zu lang, zu trocken, zu unsichtbar. Inzwischen nutze ich ähnliche Methoden auch, wenn ich Projektübergaben visuell gestalte, damit nach dem Meeting nicht die üblichen Rückfragen kommen, die wir eigentlich schon geklärt hatten.
Man muss kein Designer sein, um User Research aufzubereiten. Man muss nur den Mut haben, die polierten Dashboards mal beiseite zu lassen und die Wahrheit so krakelig aufzuschreiben, wie sie sich für den Nutzer anfühlt. Mein Sketchnotes-Tagebuch hilft mir dabei, dranzubleiben – auch wenn mein Herz-Icon manchmal eher wie eine Kartoffel aussieht. Solange das Team versteht, dass der Nutzer leidet, hat die Kartoffel ihren Job erledigt.