Ein Kreis für die Datenbank, eine Wolke für den Internetzugang, ein Blitz für die API-Verbindung. Mehr braucht eine Sketchnote oft nicht, um IT-Infrastruktur in einem SaaS-Meeting sichtbar zu machen, bevor die Diskussion in der nächsten Textwüste versandet.
Ich zeichne IT-Infrastruktur inzwischen lieber, als sie zu protokollieren. Das ist kein Kunstprojekt, kein Lettering-Kurs, sondern visuelle Kommunikation für Teams, die zwischen zwei Calls keine Zeit für zehn Confluence-Seiten haben. Seit gut einem Jahr sitze ich mit Stift statt nur mit Tastatur im Meeting, sobald es technisch wird.
Warum Textprotokolle die IT-Infrastruktur nicht erklären
Sprache beschreibt Systeme linear, Zeile für Zeile. IT-Infrastruktur funktioniert aber räumlich – in Schichten, mit Abhängigkeiten, die sich kreuzen. Wenn im Meeting jemand das OSI-Modell erwähnt, nicken alle. Vor Augen haben es die wenigsten, sobald es um Latenz in der Applikationsschicht geht.
Genau da liegt das Problem mit den Standard-Diagrammen aus dem Architektur-Tool: Sie sehen fertig aus. Zu fertig, um sie noch infrage zu stellen. Eine schiefe, handgezeichnete Linie dagegen wirkt wie ein Entwurf und lädt zur Korrektur ein, statt sie zu verhindern.
Welche Grundform passt zu welchem IT-Baustein?
Die Basis ist klein und bewusst reduziert. Eine Datenbank wird zum Kreis, eine externe Abhängigkeit oder ein Cloud-Service zur Wolke, eine API-Verbindung zum Blitz. Ein Load Balancer lässt sich als Trichter zeichnen, weil er genau das tut – viele Anfragen oben rein, eine Verteilung unten raus. Latenz bekommt eine kleine Stoppuhr mit einer Flamme dran, Container werden zu Rechtecken, die sich stapeln lassen.
Wer das Zeichnen für IT-Themen trainieren will, fängt am besten genau hier an, bevor Reihenfolge oder Symbol-Set überhaupt eine Rolle spielen. Wie man festlegt, was im Bild zuerst auffällt, ist ein eigenes Thema für sich – in diesem Text geht es nur um die Bausteine selbst. Ein komplettes Symbol-Set für Business-Meetings aufzubauen, würde diesen Text ohnehin sprengen; ich beschränke mich auf das, was im SaaS-Alltag am häufigsten gebraucht wird.
Sketchnotes live mitzeichnen, statt hinterher zu dokumentieren
Am wirkungsvollsten ist die Methode nicht als Nachbereitung, sondern live, während die Diskussion noch läuft. Bei einer Debatte über API-Gateways zeigte ein Kollege auf eine gezeichnete Wolke, die eine externe Abhängigkeit darstellte, und sagte nur: "Da liegt also der Flaschenhals." Mehr Klarheit hatte in dem Projekt vorher kein einziges fertiges Diagramm gebracht. Wie ich IT Prozesse mit Sketchnotes für Stakeholder im Team visualisiere, baut auf genau diesem Prinzip auf.
Damit das funktioniert, muss die Skizze schneller fertig sein als der nächste Satz im Gespräch – kein Zeichentalent nötig, nur Tempo. Wie man dieses Tempo ganz ohne Vorkenntnisse aufbaut, ist ein eigenes Kapitel für sich.
Nebenbei hält genau dieses Mitzeichnen die Konzentration in langen Online-Calls oben, weil die Hand beschäftigt bleibt, während andere längst zwischen zwei Tabs wechseln.
Was dabei bewusst verloren geht – weil niemand jedes Wort gleichzeitig hören und zeichnen kann – ist ein eigenes Thema, das mehr verdient als einen Nebensatz.
Ein Workshop-Whiteboard live zu moderieren, während man selbst mitzeichnet, ist nochmal eine andere Übung als die stille Notiz im eigenen Meeting.
Nach einer Retro hat ein Kollege die fotografierte Sketchnote-Seite ungefragt in den Teamkanal gepostet, mit dem Kommentar, das sei die erste Retro gewesen, an die er sich hinterher noch wirklich erinnert habe. Kein Feedback-Formular hätte das deutlicher gesagt.
Wo die Methode an ihre Grenzen stößt
Nicht jeder Versuch, Meetings besser festzuhalten, hat funktioniert. Bevor ich beim Zeichnen gelandet bin, habe ich eine Zeit lang Standups einfach als Audio aufgenommen, jede Session komplett. Abgehört habe ich davon genau keine einzige – die Dateien liegen bis heute unangetastet irgendwo ab.
Auch mit dem Stift geht nicht alles glatt. Einmal wollte ich einen Service Mesh skizzieren, das Ergebnis sah eher aus wie eine Packung Spaghetti, die im Topf explodiert ist, als wie ein orchestriertes System. Eine Kollegin hat nur genickt und gemeint, ich solle das lieber nochmal mit Worten erklären. Die Skizze ist seitdem nicht wieder aufgetaucht.
Ein paar Fragen klammere ich hier bewusst aus. Welches Seitenlayout sich für SaaS-Projektmeetings eignet, ist ein eigenes Thema. Tablet oder Papier als Werkzeug ist nochmal eine andere Debatte, die ich an dieser Stelle nicht aufmache. Farbe als zusätzliche Struktur-Ebene verdient mehr Platz, als ein Nebensatz hergibt. Und mit dekorativem Handlettering hat das alles ohnehin nichts zu tun – andere Baustelle, anderer Anspruch.
Wie ein privates Netzwerk aufgebaut ist, versteht man auch ohne Expertenwissen zu RFC 1918, wenn man es einmal vernünftig skizziert hat. Neben dem aufgeschlagenen Heft steht dabei oft ein Glas Wasser, das während eines langen Calls komplett kalt wird, weil zum Trinken keine Zeit bleibt.
Vom Symbol zur gemeinsamen Sprache im Team
Für technische Schulden reicht ein Rucksack, der auf der Seite immer schwerer wird. Für Skalierbarkeit ein Fundament, das Risse bekommt. Beide Bilder sagen in zwei Sekunden, was ein Absatz Text erst nach dreimaligem Lesen vermittelt.
Die Faustregel, nach der ich inzwischen entscheide, ob ein Begriff eine Zeichnung braucht: Wird er im Meeting öfter erklärt als verstanden, kommt der Stift raus. Alles andere bleibt Text. Wie ich durch visuelle Notizen den Wissenstransfer im Team verbessern konnte, hat genau diese Grenze für mich gezogen – zwischen dem, was sich in Worten klärt, und dem, was ein Bild braucht.