62 Prozent meiner Arbeitswoche verschwinden laut Kalender in Meetings. Diese Zahl allein erklärt schon, warum ich irgendwann aufgehört habe, komplexe SaaS-Modelle in Textform zu erklären, und warum visuelle Notizen für mich zur Produktivitätsfrage geworden sind. Zwei Werkzeuge stehen sich seitdem gegenüber: die Tabelle und die Sketchnote. Nur eins davon hat bei uns im Haus je einen Stakeholder ohne Rückfrage überzeugt.
Textlastige Erklärungen von Software as a Service Modellen scheitern regelmäßig an derselben Stelle: Kontingente, API-Limits, hybride Abrechnung, alles korrekt aufgeschrieben, trotzdem starren die Leute im Raum auf ihre Laptops. Sketchnotes lösen das nicht, weil sie hübscher sind. Sie lösen es, weil eine Skizze eine andere Art von Aufmerksamkeit erzwingt als eine dritte Bulletpoint-Ebene in Confluence.
Kurzer Zwischenstopp, weil das an dieser Stelle fair ist: Dieser Text enthält Affiliate-Links, über die ich bei einem Kauf eine Provision bekomme, ohne dass für dich etwas teurer wird. Verlinkt sind nur Kurse, die ich selbst im Arbeitsalltag über Monate getestet habe.
Tabelle gegen Skizze: Wo Text bei SaaS-Komplexität verliert
Eine Excel-Tabelle mit Churn-Zahlen ist präzise. Präzise heißt aber nicht verständlich, vor allem nicht in einem Raum, in dem die Hälfte der Stakeholder keine Statistiker sind. Sketchnotes verschieben die Arbeit vom Leser zum Zeichner — ich muss vorher entscheiden, was wichtig ist, was einen Rahmen bekommt und was nur Beiwerk bleibt. Diese Vorentscheidung, eine Art visuelle Hierarchie, ist der eigentliche Unterschied zu einer Tabelle, die einfach alles gleich gewichtet nebeneinanderstellt.
Produktivität entsteht dabei nicht durch mehr Fleiß, sondern durch weniger Rückfragen. Genau das war mein Maßstab, als ich einen Sketchnotes Kurs gebucht habe — nicht um schöner zu malen, sondern um ein Symbol-Vokabular zu lernen, das ein CFO genauso liest wie ein Senior Dev. Ein Trichter, ein Eimer, ein Blitz für Systemfehler: einmal gelernt, muss ich sie nicht in jedem Meeting neu erfinden.
Meinen ersten brauchbaren Fineliner habe ich mir übrigens von Matthias Sobolewski geliehen, meinem Nachbarn, der ebenfalls remote arbeitet. Meiner war eingetrocknet, seiner hat den Rest des Nachmittags gerettet. Mitzeichnen statt nachträglich zu dokumentieren geht ohnehin nur mit einem Stift, der nicht mitten im Satz aussetzt.
Warum ein Bild im Kopf länger hält als eine Zeile Text
Die Dual-Coding-Theorie liefert den wissenschaftlichen Unterbau dafür, warum das funktioniert: Informationen, die verbal und bildlich gleichzeitig ankommen, bleiben besser hängen als reiner Text. Im Meeting heißt das konkret — ich rede über eine Ratio, während ich eine kippende Waage skizziere, und beides zusammen bleibt hängen, wo eine Zahl allein durchrutscht.
Online-Meetings sind dabei die härtere Prüfung. Ein Bildschirm voller Kacheln zieht Aufmerksamkeit in alle Richtungen, und Mitzeichnen wird zum Anker, an dem der Kopf hängen bleibt, während um einen herum drei Leute stumm geschaltet ins Leere starren. Zeichnen zwingt außerdem zu einer Art selektivem Zuhören: Man kann nicht jedes Wort mitschreiben, also filtert man zwangsläufig nach dem, was wirklich Struktur hat.
Für technische Hürden greife ich oft auf einfache Symbole für Softwareentwicklung zurück — ein Schloss für Security-Requirements, eine Brücke für eine API-Anbindung. Das versteht der Marketing-Lead genauso wie der Senior Dev, ganz ohne Fachvokabular dazwischen.
Der Trichter: Wenn es um Kundenakquise geht
Wachstumsthemen bekommen bei mir fast immer denselben Trichter — oben breit, unten schmal, mit Beschriftungen für jede Stufe, an der Leads verloren gehen. Farbe hilft hier mehr, als man denkt: Ein Rot an der Stelle, wo die meisten Leads abspringen, sagt in einer halben Sekunde, wohin das Budget als Nächstes fließen sollte. Das Layout wähle ich bewusst nach Publikum — ein Trichter für ein IT-Projekt-Review sieht bei mir anders aus als einer für ein reines Sales-Meeting, weil die Stakeholder unterschiedliche Details brauchen.
Ein Trichter erklärt Bewegung von oben nach unten. Er erklärt keine Rückkopplung, keine Abhängigkeit zwischen zwei Systemen, kein Verhältnis. Dafür braucht es ein anderes Bild.
Kündigungen brauchen ein anderes Bild als Wachstum
An einem Vormittag im Budget-Meeting hatte ich eine fertige Tabelle zur Churn-Rate vorbereitet und merkte mitten im Satz, wie die Aufmerksamkeit im Raum kippte. Notebook zu, Stift raus, ein Eimer mit Löchern im Boden. Oben Wasser, das reinläuft — neue Kunden. Unten Tropfen, die rausfallen — Kündigungen. Daneben die Ratio zwischen Kundenwert und Akquisekosten, die bei uns intern als Zielgröße gilt.
Der Stakeholder zeigte auf die Skizze und sagte den Satz, auf den ich seitdem in jedem Budget-Meeting hoffe: Jetzt sehe er, wie Onboarding und Kündigungsrate zusammenhängen. Maximilian Dürr, ein Junior PM bei einem anderen SaaS-Unternehmen, mit dem ich mich seither ab und zu austausche, bringt in solchen Runden gern Benchmarks aus anderen Firmen mit — die Zahl allein hätte trotzdem nie gereicht, ohne das Bild vom leckenden Eimer daneben.
Fehler passieren dabei ständig, gerade live vor Publikum. Ein falsch platzierter Pfeil oder ein Symbol, das zweimal etwas anderes bedeutet, muss im Moment korrigiert werden, nicht nachträglich in Ruhe, am Whiteboard ist das etwas anderes als am Bildschirm mit Rückgängig-Taste. Das trockene Kreischen der Markerspitze, weil die Klimaanlage im Raum seit einer Weile eher symbolisch läuft, gehört für mich mittlerweile fest zu solchen Momenten dazu.
Trichter oder Eimer: Die Entscheidung, die zählt
Ein Trichter gehört auf den Tisch, wenn die Frage lautet: Wo verlieren wir Leads, und an welcher Stufe lohnt sich Investition am meisten. Ein Eimer mit Löchern gehört auf den Tisch, wenn die Frage lautet: Warum reicht Wachstum allein nicht, wenn hinten genauso viel rausläuft wie vorne reinkommt. Wer beide Bilder verwechselt, verliert genau die Klarheit, die eine Sketchnote eigentlich bringen sollte.
Für IT-Prozesse mit mehreren Abteilungen reicht keins von beiden allein — da braucht es eine Notation mit Pfeilen zwischen den Stakeholdern, die zeigt, wer worauf wartet. In Workshops, die ich moderiere, zeichne ich das meist live am Whiteboard mit, weil eine fertige Folie die Diskussion im Raum eher abwürgt als anregt. Produktfeature-Priorisierung ist wieder ein eigener Fall: Da geht es um einen räumlichen Vergleich, zwei Achsen, vier Quadranten, keine Trichter oder Eimer in Sicht.
Software-Architektur braucht Charakter, keine Deko
Software-Architekten wollen keine bunten Bildchen, sie wollen ein Diagramm mit Substanz. Wer lernt, Software Architektur visuell darzustellen, muss vor allem eins beherrschen: konsistente Pfeile, konsistente Symbole, lesbare Schrift. Genau hier trennt sich Sketchnoting vom Handlettering — es geht nicht um schöne Buchstaben, sondern um Informationsarchitektur, die auch später im Ordner noch denselben Sachverhalt zeigt.
Wer lieber auf dem iPad arbeitet, findet in einem Digital Lettering Kurs brauchbare Grundlagen für Procreate, Ebenen und Export, nur eben zugeschnitten auf Handschrift und Deko, nicht auf funktionale Business-Diagramme, und ohne die Tipps zum Handaufbau, die eine Sketchnotes-Praxis auf Papier mitbringt. Digital gegen Papier ist am Ende eine Frage des Workflows: Papier verzeiht schneller, digital lässt sich sauberer archivieren und teilen.
Was am Ende zählt: Wissenstransfer statt Aktenordner
Der eigentliche Gewinn kommt nicht im einzelnen Meeting, sondern dann, wenn jemand anders meine Notizen liest, ohne mich fragen zu müssen, was gemeint war. Genau das ist Wissenstransfer im eigentlichen Sinn: eine Skizze, die auch ohne den Zeichner im Raum funktioniert. Wenn du an dem Punkt bist, an dem deine eigenen Protokolle für dich selbst wie eine Fremdsprache aussehen, lohnt sich ein Blick auf den Sketchnotes Kurs, über den ich hier schreibe. Er ist kein Zeichenkurs. Er ist ein Kurs für Leute, die aufgehört haben, Kartoffeln zu zeichnen, und angefangen haben, Systeme zu zeichnen.