Ein Onboarding-Dokument mit vierzig Seiten Fließtext hat bei uns genau eine Gegenseite: eine Sketchnote mit sieben Kästchen, vier Pfeilen und keinem vollständigen Satz. Die Kästchen-Version wird gelesen. Das vierzigseitige Original wird verlinkt und vergessen.
Dahinter steckt kein Zufall, sondern SaaS-Produktmanagement im Meeting-Alltag: 62 Prozent der Woche laut Kalender, kein Design-Hintergrund. Was folgt, ist keine Anekdotensammlung, sondern eine Gebrauchsanleitung — wie man aus einzelnen Sketchnote-Bausteinen eine Onboarding-Strategie baut, die Produktwissen im Team wirklich ankommen lässt und Team-Effizienz nicht nur behauptet, sondern einlöst. Visuelle Kommunikation ist dabei kein Stilmittel, sondern die einzige Methode, die bei dieser Meeting-Dichte noch skaliert.
Kurz die Antwort vorweg, der Rest ist nur die Begründung: Ein Onboarding-Paket aus drei bis vier Sketchnote-Seiten plus Verweisen ins Wiki schlägt jedes vierzigseitige Dokument — vorausgesetzt, Reihenfolge, Lücken und Pflegeaufwand sind bewusst geplant, nicht zufällig entstanden.
Warum Textwüsten jede Onboarding-Strategie ausbremsen
Bevor Sketchnotes bei mir ankamen, stand ein anderer Versuch: ein Bullet-Journal-System mit eigenen Symbolen und Farbcodes für jede Aufgabenart. Kollabiert am dritten Tag — zu viele Regeln für ein System, das ich mir selbst erst wieder erklären musste, bevor ich es überhaupt benutzen konnte. Die Lektion daraus ist die, die jede Onboarding-Strategie braucht: Ein System, das der Ersteller selbst nicht ohne Nachdenken lesen kann, wird kein neuer Kollege lesen können.
Unser Gehirn verarbeitet Bilder um ein Vielfaches schneller als Fließtext — während ein Absatz noch gelesen wird, hat das Auge eine Skizze längst erfasst. Das beschreibt die Lernpsychologie unter dem Stichwort Picture Superiority Effect: Nach drei Tagen bleiben von reinem Text rund 10 Prozent im Kopf, mit einem Bild dabei sind es etwa 65 Prozent. Wissenstransfer als eigenes Thema hat mehr Tiefe, als hier Platz ist — für die Onboarding-Praxis zählt nur die Konsequenz: Jede Seite ohne Bild ist eine Seite, die beim dritten Rückfrage-Thread wieder auftaucht.
Abstraktionsebene zuerst, Details später
Jede Sketchnote-Seite im Onboarding-Paket beantwortet genau eine Frage auf genau einer Abstraktionsebene — Architekturüberblick oder Code-Detail, nie beides gleichzeitig. Die Größe der Elemente übernimmt dabei die Arbeit, für die ein Fließtext Fettdruck oder Überschriften braucht: Was groß gezeichnet ist, ist Kernprodukt, was klein am Rand steht, ist Randnotiz. Diese visuelle Hierarchie ist ein eigenes Handwerk für sich, das über reines Onboarding hinausgeht — brauchbar ist sie zum Beispiel auch, wenn man Technical Debt visualisieren will, um zu zeigen, wo das Team Abkürzungen genommen hat.
Die Regel, die ich für neue Kollegen anwende: maximal drei Abstraktionsebenen pro Onboarding-Paket, nie mehr. Eine Seite für das große Bild, eine für die Service-Grenzen, eine für den Bereich, in dem die Person als Erstes arbeitet. Alles darüber hinaus steht im Wiki, verlinkt, aber nicht vorgezeichnet.
Ein Icon-Vokabular fürs Onboarding-Paket, nicht fürs ganze Unternehmen
Ein eigenes, vollständiges Icon-Vokabular für ein ganzes Unternehmen aufzubauen ist ein Projekt für sich — dazu gehört mehr, als in ein Onboarding-Paket passt. Für den Einstieg reichen acht bis zehn wiederkehrende Symbole, gebunden an das Domänenmodell des Produkts: ein Symbol für den Nutzer, eines für den Service, eines für den externen Aufruf. Keine kompletten Figuren für Stakeholder, keine Handlettering-Übung — der Unterschied zwischen Handlettering und Sketchnoting ist hier entscheidend: Es geht um Tempo und Wiedererkennung, nicht um Schönschrift.
Getestet wird das Vokabular nicht durch Zustimmung, sondern durch Nachfrage: Ich bitte neue Kollegen, mir anhand der Symbole zu erklären, was ein Pfeil zwischen zwei Services bedeutet. Wenn die Erklärung stimmt, bleibt das Symbol im Paket. Wenn nicht, fliegt es raus, bevor es sich im nächsten Onboarding wiederholt.
Wie viele Pfeile verträgt eine Onboarding-Seite?
Flow-Notation — Pfeile, die zeigen, ob ein Aufruf synchron blockiert oder asynchron weiterläuft — ist das Werkzeug für Abhängigkeiten zwischen Services. Die Grenze, die ich mir selbst setze: maximal ein Nebensatz als Label pro Pfeil. Alles, was eine zweite Zeile Text braucht, bekommt eine eigene Teilskizze statt eines überladenen Labels.
Nebeneinander funktioniert dabei besser als nacheinander: Zwei Versionen eines Prozesses — vorher, nachher, oder aktuelle Architektur gegen Zielarchitektur — nebeneinander auf einer Seite zeigen den Unterschied schneller, als zwei einzelne Diagramme es je könnten. Diese räumliche Gegenüberstellung ist bei Migrationen im SaaS-Produktmanagement eines der nützlichsten Werkzeuge im gesamten Onboarding-Paket, auch wenn sie nur einmal pro Dokument vorkommt.
Layout nach Dokumenttyp wählen
Ein Onboarding-Paket braucht ein anderes Layout als eine live mitgezeichnete Meeting-Notiz, und wer beides gleich aufbaut, merkt das spätestens beim zweiten Durchlesen. Live-Notizen folgen dem Gespräch; ihr Layout entsteht im Moment, ungeplant, mit Fehlern, die man in Echtzeit korrigiert. Ein Onboarding-Paket entsteht danach, aus der Distanz, mit Zeit für Spalten, Pfeile, die tatsächlich zum Ziel führen, und einer Reihenfolge, die ein neuer Kollege ohne Vorwissen lesen kann.
Welches Werkzeug dabei in der Hand liegt, ist zweitrangig — Papier, Tablet, Whiteboard, jedes hat eigene Einschränkungen, die das Layout mitbestimmen. Für die Live-Erfassung eines Standups reicht mir ein A5-Notizbuch; sobald daraus ein Onboarding-Dokument wird, zeichne ich die Seite auf dem Tablet neu, weil Ebenen und Korrekturen dort schneller gehen als auf Papier.
Farbe als Signal, nicht als Dekoration
Farbe bekommt in meinen Onboarding-Seiten genau eine Aufgabe: Status markieren, nicht schön aussehen. Rot für Risiko oder offene Fragen, Blau für Kernprodukt, Grau für Randnotizen — das war's, mehr Farben verwässern die Botschaft, bevor sie überhaupt ankommt. Eine vollständige Farbsystematik für Meetings ist ein eigenes Thema; für ein Onboarding-Paket reichen drei Bedeutungen, die man sich ohne Legende merken kann.
Digital oder Papier — wovon hängt die Wahl ab?
Digitale und analoge Werkzeuge lösen im Onboarding unterschiedliche Probleme, nicht dasselbe Problem auf zwei Arten. Ein ausgedrucktes Blatt liegt auf dem Tisch im Fokus-Raum, beide Hände frei, Finger auf dem Pfeil, während man über eine Abhängigkeit spricht. Eine digitale Version lässt sich dagegen ins Wiki einbetten, durchsuchen und bei einer Architekturänderung in Minuten aktualisieren, ohne dass man die Seite neu zeichnet.
Am Kiefernholz-Schreibtisch in der Eimsbütteler Altbauwohnung sitzt der zweite Monitor links, das A5-Notizbuch liegt griffbereit neben der Maus, und über dem Bildschirm stapeln sich im Regal mehr angefangene Notizbücher, als ich zugeben möchte. Direktes Sonnenlicht kommt durchs Hoffenster ohnehin nie an, nur ein gleichmäßiges Grau, das zum Zeichnen angeblich ideal ist und sich trotzdem jeden Winter zäh anfühlt.
In einem Stehmeeting dagegen merkt man den Unterschied zwischen beiden Werkzeugen körperlich: Das Tablet wird auf dem Oberschenkel langsam warm, während die Besprechung weiterläuft — ein Zeichen, dass man es zu lange in der Hand hält, nicht dass die Skizze fertig ist.
Wo visuelle Onboarding-Unterlagen eine Grenze brauchen
Echte Kundennamen, echte Nutzerdaten oder interne Rollout-Termine gehören nicht auf eine Sketchnote-Seite, die im Onboarding-Ordner landet und Monate später noch von jemand Drittem geöffnet wird. Diese Grenze ist nicht optional, sie ist der Grund, warum in jeder Skizze mit Platzhaltern gearbeitet wird — 'Kunde A', 'Service X' — statt mit echten Bezeichnungen, selbst wenn das Gespräch im Meeting mit echten Namen lief.
Fehler auf der Seite dürfen stehen bleiben, durchgestrichen statt radiert — das zeigt dem neuen Kollegen, dass die Skizze ein Arbeitsstand ist und keine fertige Spezifikation. Diese Fehlertoleranz gehört zum Format, nicht zur Nachlässigkeit.
Zuhören ist die eigentliche Arbeit beim Onboarding
Selektives Zuhören entscheidet darüber, was überhaupt auf die Seite kommt — wer jedes Wort mitschreiben will, zeichnet am Ende nichts. Die Aufmerksamkeit bleibt an einem einzigen Anker hängen, meist der Frage, die die neue Person gerade wirklich hat, nicht an allem, was im Raum gesagt wird. Live moderieren und live zeichnen ist dabei dieselbe Fähigkeit wie bei einem Workshop am Whiteboard, nur dass hier eine einzelne Person statt einer Gruppe im Raum sitzt.
Gisa Pranger, UX Lead zwei Schreibtische weiter, hat bei einem Sprint-Review genau das vorgeführt: Der Designer wollte die Sketchnote-Seite mit dem Handy abfotografieren, noch bevor das Review zu Ende war — nicht die Folien, nicht das Ticket, die Seite mit den sieben Kästchen. Gisa bringt seit unseren Freitagsmittagen regelmäßig Muster aus dem Design-Review-Prozess in ihre eigenen Besprechungsnotizen, und an diesem Nachmittag hat sie als Erste gesehen, dass die Notiz selbst zur Dokumentation geworden war, nicht nur ihre Vorstufe.
Vom Einzelblatt zum Team-Wissen
Pattern-Clustering macht aus einzelnen Onboarding-Rückmeldungen ein verbessertes Paket: Wenn drei neue Kollegen hintereinander an derselben Stelle dieselbe Rückfrage stellen, ist das kein Zufall, sondern ein Hinweis, dass diese Seite nachgezeichnet werden muss. Wissenstransfer ist als Thema eine eigene Untersuchung wert — für die Team-Effizienz reicht hier die kurze Version: Eine Seite, die dreimal dieselbe Frage auslöst, ist noch keine fertige Seite.
Bewusst gelassene Lücken verstärken diesen Effekt noch: ein Fragezeichen statt eines fertigen Pfeils an der Stelle, an der der neue Kollege selbst im Code nachsehen soll, macht aus einem passiven Leser einen aktiven Gestalter der eigenen Einarbeitung. Genau das mache ich auch, wenn ich an anderer Stelle Product Release Notes visuell aufbereiten will, um den Fokus im Team zu halten — Reduktion auf das, was wirklich fehlt, nicht auf alles, was gesagt wurde.
Sina Gottwald, Unternehmensberaterin, hat mir nach einem der Wochenbeiträge geschrieben, dass sie denselben Clustering-Ansatz in Kundenworkshops testet, ganz ohne Zeichenhintergrund — und dass es regelmäßig schiefgeht, bevor es passt. Das meldet sie auch so zurück, Rückschlag für Rückschlag, ohne den Ansatz deshalb fallen zu lassen.
Ein Onboarding-Paket, das diese Bausteine bewusst kombiniert statt sie zufällig zu stapeln, ersetzt keine Dokumentation — es ist der Index, der zeigt, wo im Wiki man überhaupt suchen muss. Mehr verlangt visuelle Kommunikation hier nicht von sich.