Dienstag, später Nachmittag. Ich starre auf ein Protokoll auf meinem Schreibtisch, das ich vor knapp zwei Stunden selbst verfasst habe. Es geht um eine API-Migration. In meinen Notizen steht siebenmal das Wort 'Microservices' untereinander, garniert mit ein paar kryptischen Pfeilen, die irgendwie ins Leere laufen. Ich verstehe mein eigenes System nicht mehr.
Laut meinem Kalender verbringe ich 62 Prozent meiner Arbeitswoche in Meetings. Das ist viel Zeit für jemanden, der am Ende des Tages oft vor einem Haufen unleserlicher Textwüsten sitzt. Ende des letzten Jahres kam der Punkt, an dem die Verzweiflung über die eigene Ineffizienz größer wurde als die Angst vor dem weißen Blatt Papier. Ich bin Product Manager in einem Hamburger SaaS-Unternehmen, kein Designer. Aber ich musste etwas ändern.
Die Lücke zwischen IT-Architektur und Business-Stakeholdern
Das Problem in meinem Job ist oft die Übersetzung. Wenn die Developer über Latenzen und Endpoint-Struktur sprechen, nicken die Stakeholder aus dem Marketing oder Sales zwar freundlich, aber im Grunde warten sie nur darauf, dass das Wort 'Release-Datum' fällt. Textlastige Notizen oder komplizierte UML-Diagramme helfen hier wenig. Sie wirken zu technisch, zu final, zu abschreckend.
Nach dem ersten Quartal dieses Jahres wurde mir klar, dass ich eine visuelle Brücke brauche. Ich hatte die Duale Kodierung unterschätzt – die Theorie, dass unser Gehirn Informationen viel besser verarbeitet, wenn sie gleichzeitig verbal und visuell dargeboten werden. Ein linearer Text auf einem Blatt DIN A4 wird vom Gehirn nur nacheinander gescannt. Eine Skizze hingegen zeigt Hierarchien sofort.
Der Wendepunkt: Container statt Bullet-Points
Ich habe schließlich einen Sketchnotes-Kurs belegt. Nicht, weil ich plötzlich Künstler werden wollte, sondern weil ich ein System brauchte. Die wichtigste Lektion war verblüffend simpel: Alles lässt sich aus fünf Grundformen zeichnen. Punkt, Linie, Kreis, Dreieck und Quadrat. Mehr braucht es eigentlich nicht, um selbst komplexe Cloud-Infrastrukturen darzustellen.
Ich fing an, meine Notizen radikal umzustrukturieren. Statt endloser Listen nutze ich jetzt Container – einfache Kästen mit einem Schattenwurf –, um Themenblöcke voneinander zu trennen. Vor einigen Wochen habe ich zum ersten Mal ein komplettes Stakeholder-Meeting nur mit einem Fineliner bewaffnet begleitet. Die Spitzenbreite von 0.5 mm gibt mir dabei genug Präzision, ohne dass ich mich in Details verliere.
Es war anfangs ungewohnt. Man fühlt sich ein bisschen wie ein Betrüger, wenn man in einem Raum voller hochbezahlter Experten anfängt, kleine Männchen und Wolken zu malen. Aber genau hier passierte etwas Interessantes. Warum ein Sketchnotes Kurs meine Sicht auf unleserliche Meeting Notizen änderte, lag vor allem daran, dass ich plötzlich wieder aktiv zugehört habe, statt nur passiv mitzutippen.
Die API-Migration als Brücke mit Mautstelle
An einem grauen Dienstagnachmittag stand ich vor der Herausforderung, den Stakeholdern zu erklären, warum wir die API-Migration nicht einfach 'nebenbei' machen können. Die technische Beschreibung der Authentifizierungslayer sorgte für leere Blicke. Also griff ich zum Marker. Es war dieser Moment, in dem der Raum völlig still wurde.
Ich hörte nur das Quietschen des frischen Markers auf der glatten Whiteboard-Oberfläche. Ich spürte das leichte Zittern in der Hand, als ich das erste Mal vor den Senior-Developern eine Cloud auf das Whiteboard malte. Ich zeichnete die Migration als eine Brücke. Die neue API war die Fahrbahn, die Authentifizierung eine kleine Mautstelle mit einer Schranke.
Plötzlich kam Feedback. Ein Stakeholder zeigte auf die Mautstelle und fragte: 'Und was passiert, wenn da zu viele Autos gleichzeitig kommen?' Er hatte das Konzept der Rate-Limiting-Problematik verstanden, ohne dass ich das Wort einmal benutzt hatte. Die visuelle Metapher hatte die Barriere eingerissen.
Warum Perfektion der Feind der Kommunikation ist
Hier kommt der Punkt, den ich erst spät gelernt habe: Perfektion schadet der Akzeptanz. Wenn ich eine Sketchnote zu sauber und ästhetisch perfekt vorbereite, traut sich niemand mehr, Kritik zu üben. Es sieht dann aus wie ein fertiges Kunstwerk. Unsaubere, skizzenhafte Zeichnungen hingegen signalisieren den Stakeholdern Offenheit. Es ist ein Entwurf. Ein Arbeitsdokument.
Wenn die Linien etwas krumm sind, fühlen sich die Kollegen eingeladen, den Stift selbst in die Hand zu nehmen. Diese psychologische Komponente ist im SaaS-Umfeld Gold wert. Wir arbeiten agil, alles ist im Fluss. Ein 'perfektes' Diagramm wirkt wie ein in Stein gemeißeltes Gesetz, während eine schnelle Skizze ein Gesprächsangebot ist.
Natürlich geht auch mal was schief. Ich habe einmal versucht, eine Datenbank als Zylinder darzustellen, aber es sah am Ende eher aus wie ein Mülleimer. Ein Developer fragte trocken, ob wir unsere Daten jetzt direkt entsorgen. Wir haben gelacht, aber die Metapher blieb hängen: Wir mussten die Datenqualität aufräumen. Selbst ein gescheitertes Symbol kann also einen Zweck erfüllen.
Ein System für die 62 Prozent
Visuelle Kommunikation ist kein Talent, das man hat oder nicht hat. Es ist ein Werkzeugkasten. Für mich ist es mittlerweile der Weg, meine 62 Prozent Meeting-Zeit nicht nur abzusitzen, sondern effizient zu nutzen. Ich erkenne Zusammenhänge schneller, weil ich sie räumlich auf dem Papier anordne. Ich nutze oft Action Items in Sketchnotes für bessere Übersicht nach Meetings, damit ich nach drei Tagen noch weiß, was eigentlich die nächste Aufgabe war.
Wenn ich heute in ein Meeting gehe, habe ich meinen Block dabei. Keine Tastatur, kein Klappern. Nur das Geräusch des Stifts auf dem Papier. Es hilft mir, fokussiert zu bleiben. Und wenn mich heute jemand fragt, wie dieser eine IT-Prozess funktioniert, male ich ihm meistens eine kleine Brücke. Mit oder ohne Mautstelle.
Es geht nicht darum, dass es schön aussieht. Es geht darum, dass es verstanden wird. Und wenn ich dafür ein paar krumme Wolken zeichnen muss, dann ist das ein Preis, den ich für echte Klarheit im Team gerne zahle.