Vier Spalten hatte meine Meeting-Vorlage in Google Docs — Thema, Entscheidung, Owner, nächster Schritt. Sauber gedacht, für einen Produktmanager, der seine Selbstorganisation ernst nimmt. Nach dem dritten Meeting konnte ich die Tabelle selbst nicht mehr lesen. Seitdem geht es bei mir um eine andere Frage: nicht wie man schön zeichnet, sondern wie man mit visuellen Notizen schnell genug wird, um im Meeting mitzuhalten — Sketchnotes statt Tabellenkalkulation.
Bevor ich bei Sketchnotes gelandet bin, habe ich es mit reiner Struktur versucht. Die Tabelle klang vernünftig, am Bildschirm betrachtet. Am Ende hatte ich ein Dokument, durch das ich mehr scrollen musste, als ich je wieder gelesen habe — zu viele Zeilen, zu viele Sonderfälle, die in keine Spalte passten.
Warum ist die Tabelle nach dem dritten Meeting kollabiert?
Zwei Ansätze stehen sich hier gegenüber, und beide klingen zunächst vernünftig. Der eine versucht, alles zu erfassen. Jede Wortmeldung bekommt eine Zeile, jede Entscheidung ein Feld. Vollständig, ja — nur kommt man während eines schnellen Stakeholder-Reviews nicht hinterher, eine Tabelle zu pflegen. Man tippt, während der nächste Punkt schon läuft.
Der andere Ansatz verzichtet bewusst auf Vollständigkeit. Skizze statt Protokoll, reduzierte Symbole statt ganzer Sätze — mehr Struktur bleibt in Echtzeit eigentlich nicht drin. Tempo entsteht dabei nicht durch schnellere Hände, sondern durch einen härteren Filter: Wer weniger festhält, kommt mit.
Klingt simpel. Ist es halt nicht, wenn man in der Bürowelt gelernt hat, dass ein gutes Protokoll vollständig sein muss.
Ein Blick ins Heft ersetzt jedes Scrollen
Die Tabelle liegt archiviert irgendwo auf dem Firmenlaufwerk. Das Notizbuch liegt griffbereit neben der Maus, der zweite Monitor links zeigt inzwischen etwas anderes als alte Protokoll-Versionen. Schlage ich es zur letzten Retro auf, ist die ganze Woche sofort sichtbar. Keine Bildlaufleiste, kein Suchfeld, kein Rätselraten, wo das nochmal stand — nur eine Doppelseite, auf der die Kernpunkte nebeneinanderstehen.
Genau darum geht es bei diesem Vergleich — nicht um Ästhetik oder Talent, sondern um Zugriffsgeschwindigkeit auf die eigene Vergangenheit, um Meeting-Effizienz im buchstäblichen Sinn. Eine Tabelle zwingt einen, sich zu erinnern, wonach man sucht, bevor man es findet. Eine Doppelseite zeigt es einfach.
Wie man auf so einer Seite überhaupt eine sichtbare Hierarchie zwischen wichtig und nebensächlich herstellt, welches Icon-Vokabular sich für ein SaaS-Team einspielt (dazu sammle ich Beispiele in einer Referenz: Symbol-Bibliothek für Meeting-Sketchnotes) und wie viel Farbe eine Seite verträgt, ohne unleserlich zu werden — eigene Baustellen, die an dieser Stelle nicht aufgemacht werden.
Sina vergleicht Sketchnotes mit Post-its
Vor ein paar Wochen hat mir eine Leserin geschrieben, drei lange Absätze, fünf Emojis. Sina Gottwald, Unternehmensberaterin, kein Zeichenhintergrund, will Sketchnotes im Kundenprojekt einsetzen. Ihre erste Frage: ob das nicht dasselbe sei wie eine Wand voller Post-its, nur mit mehr Aufwand.
Ist es nicht, und die Antwort zeigt den Kern des Vergleichs ganz gut. Post-its sind modular — jeder Gedanke ein eigener Zettel, verschiebbar, aber ohne Verbindung zueinander. Eine Sketchnote-Seite zwingt zur Reihenfolge und zu Beziehungen: Was führt wozu, was hängt woran. Für ein einzelnes Brainstorming reichen Post-its. Für ein Protokoll, das man später noch verstehen will, reicht die Wand meistens nicht.
Ob man das lieber digital auf dem Tablet oder analog auf Papier übt, ist wieder eine andere Rechnung mit eigenen Kompromissen. Genauso, wie man Rapid-Capture ganz ohne Zeichentalent Schritt für Schritt aufbaut, welche Layout-Vorlage sich für IT- oder SaaS-Projekte eignet, oder wo Hand-Lettering aufhört und Sketchnoting anfängt — Fragen für einen anderen Text.
Wo Gisa recht behält
Meine Kollegin Gisa Pranger, UX Lead im Nachbarbereich, zweifelt grundsätzlich laut an jedem Tool, bevor sie ihm eine Chance gibt. Bei der Tabelle hatte sie recht — sie hat schon nach dem zweiten Meeting gefragt, wer das später noch lesen will. Beim Notizbuch zweifelt sie inzwischen weniger, auch wenn sie letzte Woche über eine Schnittstellen-Skizze von mir geschaut und gefragt hat, ob das ein Buchstabe oder ein Stecker sein soll. Es war ein Stecker.
Genauso bleiben andere Situationen außen vor: wie man in Online-Meetings mit einer Kamera im Gesicht die Konzentration hält, wie man IT-Prozesse für Stakeholder verständlich macht, oder wie man als Moderator live am Whiteboard mitzeichnet, während zwanzig Leute zuschauen. Jede davon verlangt eine andere Antwort als ein stilles Sprint-Planning.
Unabhängig vom System bleibt eine Frage praktisch: was mit dem passiert, was aus dem Meeting rauskommt. Dafür lohnt es sich, Action Items in Sketchnotes für bessere Übersicht nach Meetings zu markieren — ein einfaches Quadrat am Rand, das sich später abhaken lässt, egal ob die Seite davor Tabelle oder Skizze war.
Tabelle oder Skizze — wann sich was lohnt
Am Ende bleibt eine einfache Faustregel übrig. Wer ein Meeting protokolliert, das später jemand durchsuchen oder in ein System übertragen muss — Compliance-Runden, formale Freigaben, Verträge — kommt an einer strukturierten Tabelle kaum vorbei, so langsam sie im Moment auch ist. Wer dagegen im Meeting selbst mitdenken will, ohne den Anschluss zu verlieren, fährt mit der reduzierten Skizze besser, gerade wenn das Tempo hoch ist wie in einem Standup oder einer hitzigen Retro.
Beides gleichzeitig zu versuchen, war mein eigentlicher Fehler mit der Tabelle. Ich wollte Vollständigkeit und Tempo in einem Dokument, und am Ende hatte ich keins von beidem. Zwei Werkzeuge für zwei Situationen — das klingt banaler, als es sich anfühlt, bevor man es akzeptiert.