Einer dieser schwülen Nachmittage letzte Woche in Hamburg. Das Team starrt auf das Whiteboard. Es ist vollgeschrieben mit Text — Bullet Points, die sich wie eine Mauer zwischen uns und unsere Nutzer schieben. Eigentlich sollten wir gerade eine Lösung für ein Problem im Checkout finden, aber wir ersticken in unstrukturierten Zitaten.
Ich stehe da, einen fast ausgetrockneten Whiteboard-Marker in der Hand. Er gibt einen quitschenden, hohen Protestlaut von sich, während ich versuche, einen Pfeil zu ziehen. Das Geräusch schneidet durch die Stille, während alle warten, dass ich endlich fertig werde. Ich merke wieder: 62 Prozent meiner Arbeitswoche verbringe ich laut Kalender in solchen Meetings. Und oft ist das Ergebnis am Ende nur ein Berg digitaler Notizen, die niemand mehr liest.
Hinweis: Dieser Beitrag enthält Affiliate-Links. Wenn du über diese Links einen Kurs kaufst, erhalte ich eine kleine Provision — für dich entstehen dabei keine Mehrkosten. Ich empfehle hier nur den Sketchnotes Kurs, den ich selbst über Monate hinweg in meinem Hamburger Büro-Alltag durchgearbeitet habe, um nicht mehr in Textwüsten unterzugehen.
Warum Text in der Discovery scheitert
Wir machen Product Discovery, um herauszufinden, was wir eigentlich bauen sollten. In der Theorie klingt das super. In der Praxis landen Feedback-Logs meistens in Jira-Tickets oder endlosen Google Docs. Ende 2025 kam ich an den Punkt, an dem ich meine eigenen Protokolle nach dem dritten Quartal nicht mehr entziffern konnte. Es war zu viel Rauschen, zu wenig Signal.
Das Problem ist die lineare Natur von Text. Kundenfeedback ist aber selten linear. Ein Nutzer beschwert sich über die Ladezeit, erwähnt dann ein Feature-Wunsch und springt zurück zu einem Missverständnis im UI. Wenn ich das als Text mitschreibe, verliere ich den Kontext. Ich habe damals aus Verzweiflung angefangen, visuell zu arbeiten. Ganz ohne Design-Hintergrund. Einfach nur, um die 'Aha-Momente' festzuhalten.
Ich erinnere mich noch an den späten letzten November, als ich zum ersten Mal versuchte, eine Customer Journey visuell darzustellen, statt sie aufzuschreiben. Es war hässlich, aber es war das erste Mal, dass wir im Team wirklich über dasselbe sprachen.
Die Methode: Container statt Prosa
Ich nutze heute den Ansatz aus dem Sketchnotes Kurs, den ich mir Anfang des Jahres erarbeitet habe. Keine Kunst, sondern Funktion. Wenn wir Kundenfeedback besprechen, zeichne ich einfache Container für Zitate. Ein Blitz steht für Pain Points. Ein Herz für Dinge, die die Nutzer lieben. Eine Glühbirne für Ideen.
Wissenschaftlich lässt sich das mit der Dual-Coding-Theorie erklären. Unser Gehirn nutzt 2 Komponenten zur Informationsverarbeitung: einen verbalen und einen visuellen Kanal. Wenn ich nur Text liefere, ist der visuelle Kanal arbeitslos. Kombiniere ich beides, bleibt das Feedback hängen. Das merke ich vor allem in der Q1-Strategiephase, als wir die Ziele für das Halbjahr festlegten. Die Sketchnotes aus den Interviews waren präsenter als jedes PDF.
Ich habe gelernt, dass es nicht darauf ankommt, wie gut ein Symbol aussieht. Einmal wollte ich eine 'Cloud-Native Architektur' zeichnen, um den Kontext eines Kundenproblems zu verdeutlichen. Es sah am Ende aus wie ein Haufen Kartoffelbrei. Das Team hat fünf Minuten gelacht. Aber — und das ist der Punkt — wir haben danach über die Skalierbarkeit gesprochen, nicht über die Formatierung der Notizen.
Oft hilft es auch, wenn man die Ergebnisse direkt in die Team-Umgebung einbindet, zum Beispiel indem man IT Prozesse mit Sketchnotes für Stakeholder visualisiert, damit jeder versteht, wo das Feedback technisch andockt.
Remote-Teams und der asynchrone Kontext
Hier wird es schwierig. Standard-Sketchnotes funktionieren oft nur, wenn man dabei ist und der Zeichner erklärt, was er gerade macht. In unserem Team arbeiten wir über verschiedene Zeitzonen hinweg. Wenn ich eine Skizze in Slack poste, muss sie ohne mich funktionieren. Das ist der Punkt, an dem viele Sketchnoter scheitern.
Damit das asynchron klappt, habe ich angefangen, klare Beschriftungen und eine logische Leserichtung einzubauen. Ich nutze keine kryptischen Symbole mehr, die nur ich verstehe. Wenn ich Feedback visualisiere, achte ich darauf, dass die Hierarchie klar ist: Das größte Problem bekommt den größten Container. Ein kleiner Tipp: Wer auf dem iPad arbeitet, sollte sich vielleicht den Digital Lettering Kurs ansehen, um die Lesbarkeit der Handschrift zu verbessern. Meine eigene Schrift war anfangs eine Katastrophe.
Letzte Woche hat sich dieser Aufwand ausgezahlt. Ein Developer, der normalerweise meine Tabellen ignoriert, zeigte plötzlich auf einen gezackten Pfeil in meiner Skizze. Er sagte: 'Wenn das der Reibungspunkt ist, schauen wir uns die falsche API an.' Dieser visuelle Brückenschlag hat uns vermutlich zwei Wochen unnötige Arbeit erspart. Er hat danach sogar ein Foto von meiner unordentlichen Skizze mit seinem Handy gemacht, statt nach dem Link zum Sitzungsprotokoll zu fragen.
Reflektion nach neun Monaten
Ich bin jetzt seit etwa neun Monaten dabei. Meine Notizen sind immer noch kein Design-Meisterwerk, aber sie sind zu einer Art 'Source of Truth' für das Team geworden. Wenn wir Product Discovery machen, geht es nicht mehr darum, wer am lautesten schreit oder wer das längste Dokument schreibt. Es geht darum, das Bild zu sehen, das sich aus den Kundenaussagen ergibt.
Manchmal merke ich im Meeting, wie die Anspannung in meinen Schultern nachlässt. Früher hatte ich das Gefühl, jedes Wort transkribieren zu müssen. Heute weiß ich: Ich muss nur die Kern-Momente einfangen. Wenn ich merke, dass die Notizen zu komplex werden, hilft mir oft ein Blick in eine Symbol-Bibliothek für Meeting-Sketchnotes, um wieder zum Wesentlichen zurückzukehren.
Visualisieren ist kein Talent, es ist eine Entscheidung gegen das Vergessen. Wer im SaaS-Bereich arbeitet, weiß, wie schnell Feedback in der nächsten Sprint-Planung untergeht. Sketchnotes sind der Anker, der die Stimme des Kunden im Raum hält. Auch wenn der Marker mal wieder quietscht.