Drei Grundlayouts reichen für praktisch jedes IT-Architektur-Meeting im SaaS-Alltag. Das ist die kürzeste Antwort auf die Frage, die mir am häufigsten gestellt wird, wenn Kolleginnen und Kollegen über meine Schulter aufs Notizbuch schauen: Welches Sketchnotes-Layout passt eigentlich zu welchem Meeting?
Die Antwort hat weniger mit Zeichentalent zu tun als mit der Struktur des Problems, das gerade auf dem Tisch liegt. Hier kommen die Fragen, die mir zu visuellen Notizen und Sketchnotes-Layout-Vorlagen für komplexe IT-Projekte im SaaS-Bereich am häufigsten gestellt werden – von Product Managern, UX Leads und ein paar Skeptikern aus der Entwicklungsabteilung, die zuerst die Augen verdreht haben.
Welches Sketchnotes-Layout passt zu welcher Meeting-Situation?
SaaS-Architekturen bestehen aus Microservices, CI/CD-Pipelines und lose gekoppelten Systemen, die gleichzeitig existieren, nicht nacheinander. Ein klassisches Protokoll – erstens, zweitens, drittens – bildet das schlicht nicht ab. Deshalb sortiere ich Informationen nach der Form des Problems: Prozesse bekommen einen Pfad, Systeme bekommen einen Hub, und alles, was während eines chaotischen Sprints entsteht, bekommt zusätzlich ein Raster als Sicherheitsnetz.
Kognitive Entlastung ist das eigentliche Ziel, nicht Ästhetik. Wenn ich eine Schnittstelle zeichne, während ein Entwickler darüber spricht, muss ich sie später nicht mühsam aus dem Gedächtnis rekonstruieren. Genau das ist der Kern der Layout-Wahl: Die Form des Notizblatts folgt der Form des Gesprächs, nicht umgekehrt.
Das Pfad-Layout zeigt Lücken, die ein Protokoll übersieht
Für lineare Abläufe – einen User-Flow, ein Onboarding, eine Fehlerkette – zeichne ich eine dicke, geschwungene Linie über ein quergelegtes Blatt und hänge die einzelnen Touchpoints daran auf. Wenn wir über User Stories visuell darstellen für mehr Klarheit im Product Backlog sprechen, macht genau dieser Pfad sichtbar, wo der Nutzer abbiegt und wo der Prozess abbricht.
In einem Onboarding-Refinement kreiste die Diskussion einmal minutenlang um ein neues Feature, ohne dass jemand den eigentlichen Bruch im Ablauf benannte. Der Fineliner fand die Lücke schneller als das Gespräch: ein fehlender Validierungsschritt, mitten im Pfad. Der Lead Dev sah kurz hin und sagte nur, da fehle was. Kein Textprotokoll hätte das in der gleichen Zeit sichtbar gemacht.
Wann lohnt sich das Hub-and-Spoke-Layout für Systemarchitekturen?
Sobald ein Gespräch technischer wird – Microservices, Datenbanken, wer mit wem über welche Schnittstelle spricht – wechsle ich zum Hub-and-Spoke-Layout. In der Mitte steht der Kern, meistens eine zentrale Komponente oder ein Service, von dem Strahlen zu den umliegenden Systemen laufen. Tabellen habe ich dafür aufgegeben; sie zwingen jede Beziehung in eine Zelle, und lose gekoppelte SaaS-Architekturen halten sich nicht an Zellen.
Farbe kommt hier ins Spiel, aber sparsam. Farben in Sketchnotes richtig nutzen für bessere Struktur im Meeting heißt bei mir: ein Stift für Legacy-Systeme, ein zweiter für neue Services, fertig. Für Prioritäten setze ich inzwischen auch ein paar Posca-Punkte dazu – unter dem kalten Neonlicht im Großraumbüro liegen sie manchmal fast matt auf dem Papier, fast wie kleine Monde, bevor jemand das Blatt schon wieder zuklappt.
Ein Raster hilft, sobald mehrere Hubs auf dieselbe Seite müssen – ein unsichtbares Gitter, an dem sich die Kreise ausrichten, damit sie nicht ineinanderlaufen. Ohne dieses Raster wird jede komplexere Cloud-Infrastruktur schnell zu einem Knäuel aus Linien, das am Ende niemand mehr entziffert – auch ich nicht, und ich habe es gezeichnet.
Papier gegen Tablet: Geschwindigkeit im Meeting
Analog gewinnt bei mir im Live-Meeting fast immer – Papier reagiert ohne Ladezeit, ohne Akku, ohne App-Wechsel mitten im Gespräch. Digitale Werkzeuge auf dem Tablet haben andere Stärken, etwa wenn eine Sketchnote später überarbeitet oder verschickt werden muss, aber das ist eine eigene Abwägung mit eigenen Kompromissen. Tempo entscheidet in der Sitzung, nicht Schönheit: lieber ein grobes Symbol in Sekunden als ein sauberes Icon, für das ich das Gespräch verpasse.
Muss ich mich an eine feste Vorlage halten?
Nein, und genau das ist mein umstrittenster Take in dieser Sache. Wer sich zu sehr an eine Vorlage klammert, konzentriert sich auf die Form und nicht auf den Inhalt. SaaS-Projekte sind explorativ, sie springen, und ein Layout muss das aushalten können.
Ein Nachbar von mir braut im Keller sein eigenes IPA, streng nach Rezept, Zutat für Zutat abgewogen, bei einem Sketchnotes-Layout würde diese Präzision nach hinten losgehen. Wenn ich mir vorher ein perfektes Raster auf das Blatt zeichne, traue ich mich später nicht mehr, eine neue Idee quer darüberzumalen. Das Layout ist das Skelett, nicht das Ergebnis.
Struktur schlägt Kunstfertigkeit, auch außerhalb der drei Grundlayouts. Wer 5 einfache Sketchnotes Rahmen für mehr Struktur in Besprechungen kennt, kommt oft schon mit wenigen Kästen und Pfeilen aus, ohne dass dafür ein eigenes Icon-Vokabular nötig wird – das ist noch mal ein anderes Thema für sich.
Auch beim Thema Handlettering bin ich stur: Ich sehe oft Leute, die versuchen, kalligrafische Perfektion in ihre Meeting-Notizen zu bringen, und das kostet im PM-Alltag nur Zeit. Den Unterschied zwischen Handlettering und Sketchnotes für schnelle Notizen zu kennen, spart Nerven. Wir brauchen keine schönen Buchstaben. Wir brauchen Pfeile, die in die richtige Richtung zeigen.
Was vor den Sketchnotes bei mir nicht funktioniert hat
Bevor ich auf Sketchnotes umgestiegen bin, habe ich Standups aufgenommen, in der Hoffnung, Details später noch einmal nachhören zu können. Die Audiodateien lagen tagelang ungehört auf der Festplatte – niemand hört sich ein komplettes Standup noch mal an, auch ich nicht. Das Problem war nie das Erinnern an sich, sondern die Form, in der ich mir Dinge gemerkt habe.
Im Sprint-Review hält eine Designerin dann plötzlich inne, zückt ihr Handy und fragt, ob sie die Sketchnote-Seite fotografieren darf, weil die Abhängigkeiten dort klarer aussehen als im Ticket-System. Genau an solchen Momenten merke ich, dass die Zeitersparnis nicht nur bei mir liegt – andere lesen die Seite schneller als jede Doku, die ich vorher geschrieben habe.
Ein Layout reicht nicht für den ganzen SaaS-Stack
Fokus während eines Online-Meetings ist ein eigenes Problem, das ein Layout allein nicht löst, wie ich meine Aufmerksamkeit beim Zeichnen hochhalte, ist eine andere Frage als welche Linien ich ziehe. Genauso ist aktives Zuhören beim Skizzieren eine eigene Fertigkeit, die man separat trainiert und die nicht automatisch mitgeliefert wird, nur weil ein Stift in der Hand liegt.
Für Stakeholder-Runden zeichne ich Abläufe oft anders als für ein internes Architektur-Meeting, weil die Fragen andere sind – das ist wieder eine eigene Notation für sich. Und sobald ich nicht mehr nur für mich selbst notiere, sondern einen Workshop am Whiteboard moderiere, ändert sich noch mal die ganze Logik des Zeichnens live vor Publikum.
Am Ende bleibt bei mir dieselbe Faustregel für jedes SaaS-Meeting: erst die Form des Problems anschauen, dann erst den Stift ansetzen. Manchmal ist das eine Linie. Manchmal ein Kreis mit zu vielen Strahlen. Und manchmal, mitten im Refinement, reicht ein Kasten mit einem Pfeil drauf, und das Meeting geht einfach weiter.