Ein Protokoll wird abgehakt, eine Sketchnote wird angeschaut — noch drei Tage später. Genau daran hängt für mich die Frage, wie Wissenstransfer im Team wirklich funktioniert. Ich bin Product Manager in einem Hamburger SaaS-Unternehmen und sitze laut Kalender in mehr Meetings als an eigentlicher Arbeit.
Kurz vorweg, weil es dazugehört: Dieser Artikel enthält Affiliate-Links. Kaufst du darüber einen Kurs, bekomme ich eine Provision, für dich ändert sich am Preis nichts. Ich schreibe hier nur über Kurse, die ich selbst im echten Arbeitsalltag getestet habe.
Zwei Systeme, ein Problem: Wissenstransfer im Team
Verantwortlich bin ich dabei für die Brücke zwischen Stakeholdern und Entwicklung. Wenn das, was in einem Call besprochen wird, nicht bei denen ankommt, die nicht dabei waren, war die halbe Diskussion umsonst. Zwei Systeme habe ich dafür ernsthaft ausprobiert: ein reines Text-System, in dem jede Entscheidung dokumentiert wird, und eine visuelle Variante, die auf Symbolen und Pfeilen statt auf Sätzen aufbaut.
Über einen Sketchnotes Kurs bin ich in die zweite Variante eingestiegen, aus Verzweiflung an meiner eigenen Textwüste, nicht aus Ambition. Zeichnen konnte ich vorher nicht, der letzte bewusste Kontakt zu einem Stift außerhalb einer Unterschrift lag im Kunstunterricht. Genau das war der Punkt: Es geht nicht um Talent, sondern um ein System aus wenigen, klaren Symbolen.
Das Linear-Ticket für jede Entscheidung ist gescheitert
Bevor ich bei Sketchnotes gelandet bin, hat unser Team etwas anderes versucht: für jede Entscheidung ein eigenes Linear-Ticket. Die Idee klang sauber — jede Entscheidung nachvollziehbar, verlinkt, durchsuchbar. In der Praxis ist das Gegenteil passiert. Nach ein paar Sprints wusste niemand mehr, welche der hunderten Tickets eine echte Entscheidung dokumentierten und welche einfach nur Aufgaben waren. Die Suche nach 'warum haben wir das eigentlich so gemacht' endete regelmäßig in einer Liste von zwanzig Tickets mit fast identischen Titeln.
Ein Beispiel, das mir noch gut im Kopf ist: eine komplexe Programmierschnittstelle (API), die drei Legacy-Systeme verbinden sollte. Vorher hätte das Thema in einem weiteren Linear-Ticket geendet, mit einer langen Beschreibung, die kurz darauf schon wieder unklar gewesen wäre. Stattdessen habe ich während des Calls Boxen und dicke Pfeile für die beteiligten Microservices gezeichnet, das Blatt abfotografiert und in den Slack-Kanal geworfen. In den Sekunden, bevor mein Lead-Entwickler geantwortet hat, war im Konferenzraum nur das Rauschen der Klimaanlage zu hören. Dann kam: 'Warte kurz, nicht weiterblättern — das ergibt gerade mehr Sinn als das Ticket, aus dem ich seit einer halben Stunde nicht schlau werde.'
Was eine Sketchnote kann, was ein Protokoll nicht kann
Nicht jede Sketchnote gelingt, das gehört dazu. Eine 'Cloud-Native Architecture', die ich einmal darstellen wollte, sah am Ende aus wie ein Haufen Weintrauben. Die Folge waren zehn Minuten Diskussion über Obst statt über Server-Infrastruktur. Trotzdem ist genau das ein Grund, warum das System als Wissenstransfer-Werkzeug funktioniert: Man merkt sofort, wenn ein Symbol nicht trägt, weil die Reaktion der Runde direkt kommt. Bei einem Text-Ticket merkt das oft niemand, bis eine ganz andere Frage später wieder auftaucht.
Ein Grund dafür liegt in der visuellen Hierarchie einer Seite: was groß und eingerahmt steht, wird als wichtig gelesen, ganz ohne dass es jemand erklären muss. Ein zweiter Grund ist das Tempo: Sketchnotes leben vom schnellen Festhalten, während ein Gedanke noch frisch ist, nicht vom nachträglichen Ausformulieren. Dazu kommt ein festes Set an Symbolen, das sich über Meetings hinweg wiederholt, sodass niemand jedes Mal neu entschlüsseln muss, was ein Kreis mit Blitz bedeutet.
Welches Layout ich für eine Seite wähle, hängt vom Meeting ab — ein Sprint-Planning braucht eine andere Aufteilung als ein Architektur-Gespräch. Farbe setze ich sparsam ein, meistens nur, um eine Kategorie von einer anderen zu trennen, nicht als Dekoration. In Online-Meetings hält mich das Zeichnen zusätzlich bei der Sache, weil die Aufmerksamkeit an der Hand hängt und nicht am zweiten Bildschirm. Und weil ich mitzeichne, höre ich automatisch selektiver zu — ich filtere die eine Entscheidung aus zehn Minuten Diskussion heraus, statt alles mitzuschreiben.
Für Stakeholder, die den technischen Prozess nicht im Detail kennen, reicht oft ein einfacher Pfeil-Fluss von einem Schritt zum nächsten, um zu zeigen, wo ein Projekt gerade hängt.
Wie stabil das im Kopf bleibt, habe ich neulich gemerkt, als ich ein altes Notizbuch aufgeschlagen habe. Der dicke Pfeil zwischen zwei Boxen war sofort wieder klar, keine Sekunde Nachdenken nötig, obwohl mir der Kontext komplett entfallen war. Bei einem alten Ticket mit dem Titel 'Entscheidung Q3 — siehe Kommentare' hätte ich das nicht geschafft.
Grenzen ziehen: Wo die Sketchnote im Team-Alltag aufhört
Bei Pair-Programming-Sessions funktioniert das System schlechter. Gleichzeitig tief im Code zu stecken und eine saubere Übersicht zu zeichnen geht nicht. Ich setze inzwischen nur rudimentäre Ankerpunkte während der Session und zeichne die eigentliche Seite danach in wenigen Minuten fertig. Wer sich vor dem ersten Strich im Meeting scheut, kommt an der Angst vor dem Zeichnen im Meeting und die Blockade zu überwinden ohnehin nicht vorbei — bei mir war das am Anfang genauso. Danach wird es vor allem eine Frage von System statt Talent: Wer wichtige Informationen in Meetings schneller filtern mit einfachen Sketchnotes will, braucht in erster Linie eine klare Auswahl an Symbolen, keine Zeichenkurse für Feinschliff.
Mein Nachbar Matthias, der in der Logistik arbeitet und Sketchnotes für überflüssigen Kram hält, hat mich neulich im Treppenhaus gefragt, ob ich immer noch mit Filzstiften in Meetings sitze. Ich habe ihm erklärt, dass es dabei nicht um schöne Buchstaben geht — Handlettering und Sketchnoting sind zwei unterschiedliche Baustellen, das eine zielt auf Ästhetik, das andere auf Tempo in einem Meeting. Und dass ich damit auch keinen Workshop live an einem Whiteboard moderiere, sondern einfach nur für mich selbst und mein Team mitschreibe.
Text oder Bild: Die Wahl nach Situation
Maximilian, ein Junior PM, den ich über einen LinkedIn-Kommentar kennengelernt habe, wollte kürzlich eine genaue Zahl von mir: wie viele Rückfragen das im Schnitt erspart. Eine Zahl konnte ich ihm nicht liefern, nur dass es spürbar weniger geworden sind, seit Entscheidungen als Bild und nicht nur als Text existieren.
Für lückenlose Nachvollziehbarkeit, Audits oder Freigaben, die später jemand wörtlich zitieren muss, bleibt ein Text-Protokoll unverzichtbar. Eine Sketchnote ersetzt kein Dokument dieser Art. Für den schnellen Wiedereinstieg nach einer Auszeit, für Leute, die nie im Meeting waren, oder für alles, was mit Abhängigkeiten und Architektur zu tun hat, gewinnt bei mir inzwischen fast immer das Bild.
Wer selbst einsteigen will, kommt über den Sketchnotes Kurs am direktesten zum Punkt — Papier und ein Stift reichen für den Start völlig aus. Wer irgendwann lieber digital arbeitet, für den ist der Digital Lettering Kurs der naheliegende nächste Schritt, auch wenn sich das Zeichnen auf dem iPad am Anfang komplett anders anfühlt als auf Papier.
Am Ende bleibt bei mir kein Design-Anspruch übrig, nur die Frage, ob eine Information beim Team ankommt oder irgendwo zwischen Kaffeeklatsch und Ticket-Board verloren geht. Ein Protokoll beantwortet das nicht zuverlässig. Eine Sketchnote — meistens schon.