Der Stift ist schon in Bewegung, bevor der Satz des Stakeholders zu Ende ist. Ein Kreis für das System, ein Pfeil für die Abhängigkeit, fertig — und ich habe noch kein einziges Wort mitgeschrieben. So läuft inzwischen fast jedes Stakeholder-Interview bei mir ab: Sketchnotes statt Fließtext, visuelle Notizen statt Wortprotokoll, weil ich als Product Manager in der Discovery sonst nach der dritten Aussage den Faden verliere.
Ein Jahr mache ich das jetzt — kein Design-Hintergrund, keine Kunstschule, nur ein A5-Notizbuch und die Erkenntnis, dass meine eigenen Protokolle nach drei Tagen unlesbar waren. Genug Zeit, um ein paar Fragen zu beantworten, die mir seitdem gestellt wurden: von Kollegen, von Lesern, einmal sogar von meinem eigenen Chef, der über die Schulter schaute und fragte, ob ich gerade male statt zuzuhören.
Wo fängt visuelles Protokollieren im Stakeholder-Gespräch an?
Direkt beim ersten Satz, nicht erst danach. Sobald jemand von einem Problem erzählt, zeichne ich einen Kreis in die Mitte der Seite — das ist der Anker. Alles, was danach kommt, hängt sich mit Pfeilen oder kleinen Symbolen daran. Kein Titel, keine Überschrift, kein Datum oben rechts. Nur das Problem, mittig, und dann Platz drumherum.
Genau dieser leere Platz fühlt sich am Anfang falsch an. Man ist es gewohnt, eine Seite vollzuschreiben, jede Zeile bis zum Rand. Beim Sketchnoting lässt man bewusst Lücken — für Pfeile, die man erst später zieht, wenn der Stakeholder eine Verbindung nennt, an die man selbst nicht gedacht hätte.
Das Notizbuch selbst ist mit Absicht klein. Ein DIN A5 Block passt neben die Tastatur, auf den Konferenztisch, in die Innentasche der Jacke — größer würde ich sowieso nicht mit einer Hand halten können, während die andere den Stift führt.
Faustregel für die Größe: passt es in eine Hand, während man zuhört? Wenn nicht, ist es zu groß für ein Interview und eher was für eine Retro im Sitzen.
Der Systemwechsel, der nach drei Tagen kollabierte
Bevor ich bei Kreisen und Pfeilen gelandet bin, hab ich ein Bullet-Journal-System ausprobiert — mit eigenen Symbolen für Meeting-Typen, Farbcodes für Priorität, eine kleine Legende auf der ersten Seite. Klang nach einem soliden Plan.
Am dritten Tag ist es kollabiert. Die Legende hatte ich nicht dabei, weil sie in einem anderen Notizbuch lag. Zwei Farben sahen bei künstlichem Licht im Meetingraum plötzlich identisch aus. Und ein Symbol, das für "Blocker" stehen sollte, hab ich selbst zweimal falsch gelesen — einmal als "erledigt" interpretiert, was in einer Retro zu einer sehr verwirrten Nachfrage aus dem Team führte.
Seitdem gilt bei mir eine Regel: kein System, das eine Legende braucht, die man auswendig lernen muss. Wenn ein Symbol nicht auch ohne Erklärung verständlich ist — für mich selbst, drei Tage später — fliegt es raus.
Reicht ein Symbol, wenn drei Leute gleichzeitig reden?
Nein, dann reicht auch kein Symbol. Bei einem Interview mit dem Head of Sales über eine unklare Ursache für Kundenabwanderung hab ich mit der 5-Why-Methode gearbeitet, nur eben mit Pfeilen statt Sätzen — jede neue Ebene ein Stück weiter unten auf dem Blatt.
Sobald aber mehr als eine Person parallel redet, reicht diese eine Kaskade nicht mehr. Dann skizziere ich für jede Stimme eine eigene kleine Spalte und verbinde sie erst am Ende, wenn klar ist, wo sich die Aussagen überschneiden. Sauber sieht das nie aus. Funktional schon.
Der Test, den ich mir angewöhnt habe: Wenn ich am Ende des Gesprächs nicht in fünf Sekunden zeigen kann, wo Person A und Person B sich widersprechen, war die Notiz zu füllig statt zu klar.
Sina hat gefragt: Muss man zeichnen können?
Sina hat mir vor Kurzem per Mail geschrieben — Unternehmensberaterin, will Sketchnotes in einem Kundenprojekt einsetzen, aber ohne Zeichenhintergrund, wie sie selbst schreibt. Typisch für sie: Bevor ich überhaupt antworten konnte, kamen in derselben Mail schon drei Gegenfragen hinterher.
Meine Antwort war kurz: Nein, man muss nicht zeichnen können. Ein Kreis ist ein Kreis, egal wie krumm. Ein Pfeil zeigt eine Richtung, auch wenn die Linie zittert. Was zählt, ist, ob man später noch erkennt, was gemeint war — nicht, ob es auf einer Ausstellung hängen könnte.
Der einzige Ratschlag, den ich Sina mitgegeben habe: eine kleine, feste Anzahl an Symbolen anlegen und die immer gleich zeichnen, statt für jedes Meeting neue zu erfinden. Konsistenz schlägt Talent, gerade in einem Kundenprojekt, wo am Ende jemand anderes die Notiz lesen soll.
Farbe einsetzen, ohne sich zu verzetteln
Gisa, UX Lead im Nachbarbereich, hat neulich über meine Schulter geschaut und gefragt, warum bei mir nie zwei Farben in einer Zeile auftauchen. Bei ihr ist das anders — sie codiert ihre eigenen Notizen fast wie eine Ampel, Rot für Blocker, Gelb für offene Fragen, Grün für Entscheidungen.
Während des Interviews selbst nutze ich trotzdem nur einen Fineliner. Keine Farbe, kein Textmarker, keine Ablenkung, während jemand redet. Farbe kommt bei mir erst danach dazu, wenn ich die Notiz für mich selbst nochmal durchgehe und markiere, was tatsächlich eine Entscheidung war und was nur eine Idee.
Was ich mache, wenn genau in diesem Moment ein Tintenfleck über die halbe Zeichnung läuft, hab ich in einem eigenen Beitrag über den Umgang mit Fehlern beim Sketchnoting aufgeschrieben. Die Faustregel dahinter: durchstreichen und weiterzeichnen schlägt neue Seite, weil ein Stakeholder den Fleck sowieso meistens ignoriert.
Was beim Blättern zurück wirklich zählt
Bei der letzten Retro hab ich das Notizbuch aufgeschlagen, und alles war sofort da — kein Scrollen durch einen Slack-Thread, kein Rekonstruieren, wer wann was gesagt hat. Nur die Seite, mit allen Pfeilen und Kreisen genau da, wo ich sie hingezeichnet hatte.
Das ist der eigentliche Unterschied zu einem alten Textprotokoll. Ich hab letztens eine Notiz aus der Zeit vor den Sketchnotes gefunden, nur Fließtext, ein Begriff wie "optimierte Pipeline", der damals offenbar wichtig war. Ich habe keine Ahnung mehr, was genau gemeint war. Bei einer Zeichnung mit Mauer, Blitz und Sackgasse-Pfeil weiß ich es sofort wieder.
Wann Sketchnotes im Stakeholder-Gespräch nicht helfen
Manchmal höre ich schlechter zu, weil ich zu sehr mit dem perfekten Symbol beschäftigt bin. Das ist der eine Nachteil, den kaum ein Tutorial erwähnt — Zeichnen und wirklich zuhören konkurrieren um dieselbe Aufmerksamkeit.
Deshalb picke ich mittlerweile bewusst nur die Ankerpunkte raus, während jemand redet, und fülle den Rest in den Pausen oder direkt danach — eine Art Rapid Capture, die bei einem lauten, schnell redenden Stakeholder nötig ist, aber eben nur ein Werkzeug unter mehreren.
Für richtig komplexe Zusammenhänge greife ich manchmal auf Methoden zurück, die ich in einem Kurs zu SaaS-Geschäftsmodellen gelernt habe. Im Interview selbst bleibt es trotzdem roh: Kreise, Pfeile, kurze Schlagworte, und die Hand, die nach einer Stunde zuverlässig anfängt zu verkrampfen.
Meine Symbole sind nach einem Jahr immer noch krumm. Funktioniert trotzdem besser als jedes Protokoll, das ich vorher geschrieben habe.