Später Nachmittag im Büro. Meine Augen brennen. Ich starre auf zwölf Seiten Fließtext-Protokoll einer API-Dokumentation, die ich selbst vor zwei Tagen verfasst habe. Das Problem: Ich verstehe sie nicht mehr. Es sind Worte über Worte, die versuchen, eine nicht-lineare Software-Architektur in eine lineare Textform zu pressen. Ein hoffnungsloses Unterfangen.
Ende des dritten Quartals 2025 war der Punkt erreicht, an dem ich wusste: Wenn ich so weitermache, verliere ich den Überblick über unser Kernprodukt. Mein Kalender zeigt mir schwarz auf weiß, dass ich 62 Prozent meiner Arbeitswoche in Meetings verbringe. Davon sind mindestens die Hälfte technische Deep Dives oder Stakeholder-Alibis. Ich bin kein Designer. Ich habe keine Ahnung von Proportionen. Aber ich habe angefangen zu zeichnen, weil mein Gehirn den SaaS-Dschungel sonst nicht mehr sortiert bekommt.
Warum SaaS-Strukturen Listen hassen
In einem Hamburger SaaS-Unternehmen zu arbeiten bedeutet, sich mit Microservices, CI/CD-Pipelines und lose gekoppelten Systemen herumzuschlagen. Diese Dinge existieren nicht nacheinander. Sie existieren gleichzeitig, nebeneinander und interagieren ständig. Ein klassisches Protokoll — erstens, zweitens, drittens — bildet das schlicht nicht ab.
Ich habe als visueller Analphabet angefangen. Mein Sketchnotes-Tagebuch war anfangs eher eine Sammlung von Hieroglyphen, die nur ich (und manchmal nicht mal ich) entziffern konnte. Aber nach etwa sechs Monaten Übung habe ich gemerkt, dass es bestimmte Muster gibt. Layouts, die immer wiederkehren, wenn man über IT-Projekte spricht. Es geht dabei nicht um Ästhetik. Es geht um kognitive Entlastung.
Wissenschaftlich lässt sich das wohl mit der Dual-Coding-Theorie erklären. Information bleibt besser hängen, wenn sie sowohl verbal als auch bildlich kodiert wird. Für mich bedeutet das schlicht: Wenn ich die API-Schnittstelle zeichne, während der Entwickler darüber spricht, muss ich sie später nicht mühsam aus meinem Kurzzeitgedächtnis rekonstruieren.
Das Pfad-Layout für User Stories
Das erste Layout, das für mich im Sprint-Alltag funktioniert hat, ist das Pfad-Layout. Ich nutze dafür meistens das Standard-Papierformat A4, also 210 x 297 mm, quergelegt. Ein weißes Blatt, das am Anfang des Meetings noch völlig unschuldig aussieht.
Ich zeichne eine dicke, geschwungene Linie von links oben nach rechts unten. Das ist der Weg des Users durch unser Produkt. Entlang dieses Pfades platziere ich die einzelnen Touchpoints. Wenn wir über User Stories visuell darstellen für mehr Klarheit im Product Backlog sprechen, hilft dieser Pfad, die Abhängigkeiten zu sehen. Wo biegt der User ab? Wo bricht der Prozess ab?
Ein grauer Dienstagnachmittag im März war so ein Moment. Wir diskutierten über ein neues Onboarding-Feature. Die Diskussion drehte sich im Kreis. Ich zeichnete den Pfad mit meinem 0.5 mm Fineliner. Das kratzende Geräusch auf dem festen Papier war das einzige Geräusch im Raum, als ich plötzlich eine Lücke im Pfad markierte. Ein fehlender Validierungsschritt. Die Stille im Raum hielt an, bis der Lead Dev sagte: "Stimmt, da fehlt was." Kein Textdokument hätte diesen Fehler so schnell sichtbar gemacht.
Das Hub-and-Spoke Layout für Systemarchitekturen
Wenn es technischer wird, wechsle ich zum Hub-and-Spoke Layout. In der Mitte steht der Kern — zum Beispiel unsere Datenbank oder ein zentraler Microservice. Von dort aus gehen Strahlen zu den umliegenden Systemen. Das ist besonders effektiv für SaaS-Architekturen, die auf lose gekoppelten Diensten basieren.
Früher habe ich versucht, das alles in Tabellen zu fassen. Wer spricht mit wem über welche Schnittstelle? Das Ergebnis war ein kognitiver Albtraum. Jetzt zeichne ich Kreise und Blitze für die Verbindungen. Es sieht aus wie eine Sonne mit sehr unordentlichen Strahlen, aber es funktioniert.
Ich erinnere mich an einen Moment vor ein paar Wochen während eines Sprints. Ich wollte eine komplexe Cloud-Infrastruktur zeichnen. Ich fing einfach an, ohne Plan. Am Ende sah es aus wie ein Haufen Spaghetti. Ich hatte die Skalierbarkeit vergessen und die Zeichnung wurde so chaotisch, dass ich sie wegwerfen musste. Das war der Moment, in dem ich lernte, das Raster-Layout zu nutzen — eine Art unsichtbares Gitter, an dem ich meine Hubs ausrichte, damit sie nicht ineinanderlaufen.
Manchmal hilft es auch, Farben in Sketchnotes richtig nutzen für bessere Struktur im Meeting zu integrieren. Ein roter Fineliner für die Legacy-Systeme, ein grüner für die neuen Services. Mehr braucht es nicht. Keine Kunst, nur Klarheit.
Der Senior Developer und das Gekritzel
Eines der schönsten Erlebnisse hatte ich vor kurzem. Ein Senior Developer, der normalerweise wenig für Management-Methoden übrig hat, stoppte mich im Flur. Er hatte im Refinement über meine Schulter auf mein Notizbuch geschaut. Er fragte, ob er ein Foto von meinem "Gekritzel" machen könne. Er meinte, meine Skizze zeige die Abhängigkeiten der Microservices besser als unser aktuelles Jira-Board.
Das war die Bestätigung, die ich brauchte. Mein Ziel ist nicht, ein Künstler zu werden. Ich will nur meinen Job machen, ohne am Ende des Tages das Gefühl zu haben, mein Kopf bestünde aus unformatiertem Quelltext. Wenn man 5 einfache Sketchnotes Rahmen für mehr Struktur in Besprechungen kennt, reicht das oft schon aus, um komplexe Themen zu bändigen.
Warum starre Vorlagen kontraproduktiv sind
Hier kommt mein persönlicher Take, der vielleicht gegen die gängige Lehrmeinung verstößt: Zu strukturierte Vorlagen sind in der agilen Softwareentwicklung Gift. Wer sich zu sehr an eine Vorlage klammert, konzentriert sich auf die Form und nicht auf den Inhalt.
SaaS-Projekte sind chaotisch. Sie sind explorativ. Ein Layout muss atmen können. Wenn ich mir vorher ein perfektes Raster auf das A4-Blatt zeichne, traue ich mich später nicht, eine neue Idee quer drüber zu malen. Das visuelle Denken soll den Prozess unterstützen, nicht einengen. Das Layout ist nur das Skelett. Das Fleisch — die eigentliche Erkenntnis — entsteht im Moment des Zeichnens.
Ich sehe oft Leute, die versuchen, Handlettering-Perfektion in ihre Notizen zu bringen. Ich halte das für Zeitverschwendung im PM-Alltag. Den Unterschied zwischen Handlettering und Sketchnotes für schnelle Notizen zu verstehen, ist essenziell. Wir brauchen keine schönen Buchstaben. Wir brauchen Pfeile, die in die richtige Richtung zeigen.
Nach nun fast acht Monaten mit diesem Experiment kann ich sagen: Mein 62-prozentiger Meeting-Anteil fühlt sich weniger nach Zeitverschwendung an. Ich produziere jetzt Ergebnisse, die ich auch drei Wochen später noch verstehe. Und wenn ich mal wieder ein Cloud-Diagramm wie Spaghetti zeichne, dann ist das eben so. Dann nehme ich ein neues Blatt und fange von vorne an. Der 0.5 mm Fineliner ist geduldig.