Aus verstreutem Methodenwissen wird ein Atlas
Irgendwann merkte ich, dass ich nicht zu wenig Methoden kannte. Ich hatte eher das gegenteilige Problem. Über die Jahre waren überall kleine Methodenspuren entstanden: in Notizen, Bookmarks, Artikeln, PDFs, Workshop-Unterlagen, Produktideen, Architekturkontexten und irgendwo im Kopf. Manche Methoden hatte ich selbst genutzt. Andere hatte ich einmal gesehen, interessant gefunden und später wieder verloren.
Das war der Moment, in dem Methodatlas für mich spannend wurde. Vor mir lag ein ziemlich reiches, verstreutes Material. Ich musste es aus den Ecken holen, sortieren und so strukturieren, dass es im Arbeitsmoment wieder auftaucht.
Der Atlas begann nicht mit einem Feature. Er begann mit dem Gefühl: Da ist schon viel Wissen, aber es ist noch nicht greifbar.
Aus dieser Beobachtung entstand die erste Idee: ein zentraler Ort, an dem Methoden wieder aktivierbar werden. Der Atlas sollte als Arbeitsfläche funktionieren. Wenn ich nur noch eine grobe Erinnerung habe, soll er genug Anhaltspunkte bieten: Zweck, Form, Kontext, Output, Grenzen, Alternativen, verwandte Methoden und visuelle Hinweise.
Aus Sammlung wurde Material
Am Anfang fühlte sich das noch wie Aufräumen an. Ich sammelte Methoden, die ich kannte, gelesen hatte oder regelmäßig irgendwo wiederfand. Manche kamen aus Product Discovery, andere aus UX, Strategie, Architektur, Delivery, Business oder Operations. Einige waren sehr konkrete Workshop-Methoden. Andere waren Frameworks, Denkmodelle, Analyseformen oder Entscheidungspraktiken.
Dann passierte etwas Schönes: Die Liste wurde schnell groß genug, dass sie sich wie Material anfühlte. Aus zehn Methoden wurden fünfzig. Dann hundert. Dann zweihundert. Plötzlich sah ich Muster zwischen den Einträgen. Manche Methoden waren eigentlich Varianten derselben Denkbewegung. Manche wirkten ähnlich, lösten aber unterschiedliche Arbeitssituationen. Manche waren bekannt, aber schwer sauber abzugrenzen. Andere waren kleine, unterschätzte Werkzeuge, die im richtigen Moment unglaublich nützlich sein können.
Ab einer bestimmten Größe wird eine Sammlung interessant, weil sie ihre innere Struktur zeigt.
Bei 283 Methoden ging es für mich nicht mehr um Vollständigkeit. Die wäre ohnehin eine Illusion. Interessanter war die Frage, welches Datenmodell dieses Material tragen kann.
- Welche Informationen braucht ein Eintrag, damit er mehr ist als ein Name?
- Was muss ich wissen, um eine Methode wiederzuerkennen, einzuordnen, zu vergleichen und später weiterzuentwickeln?
Das Datenmodell wurde zur eigentlichen Arbeit
Der naheliegende erste Schritt waren Kategorien. Product, UX, Strategie, Architektur, Engineering, Delivery, Operations, Business und Growth geben eine erste Orientierung. Sie helfen, den Katalog zu scannen und eine Methode fachlich einzuordnen.
Aber je mehr Einträge dazukamen, desto klarer wurde: Die Kategorie ist nur eine Schicht. Eine Methode kann aus Product Discovery kommen und trotzdem in Strategiearbeit helfen. Eine Architekturmethode kann eine Produktentscheidung klären. Ein Workshop-Format kann in einem Team genau richtig sein und in einem anderen zu groß wirken.
Der eigentliche Durchbruch war die Methodenform. Canvas, Matrix, Flow, Workshop-Methode, Mapping, Scorecard, Framework, Checkliste, Entscheidungsmodell. Diese Formen sagen viel über die praktische Nutzung. Ein Canvas lädt zum Ausfüllen ein. Eine Matrix zwingt zu Unterscheidungen. Ein Flow führt durch Schritte. Eine Scorecard macht Kriterien sichtbar. Plötzlich bekam der Katalog eine zweite Ordnung, die sich viel näher an Arbeit anfühlte.
Mit Kategorien und Formen wurde aus der Liste langsam ein Atlas.
Danach kamen weitere Felder dazu: Zweck, Einsatzkontext, Output, Grenzen, Tags, verwandte Methoden und Alternativen. Das klingt trocken, war beim Bauen aber genau der spannende Teil. Jeder neue Eintrag war ein kleiner Test:
- Reicht das Modell?
- Fehlt eine Dimension?
- Wird die Methode dadurch klarer oder nur ausführlicher?
Je mehr Methoden ich einpflegte, desto stärker wurde sichtbar, welche Struktur wirklich trägt.
Quellen öffnen die zweite Ebene
Methodatlas erklärt Methoden bewusst knapp. Ein Eintrag soll Orientierung geben, eine Methode einordnen und den nächsten Schritt erleichtern. Er kann im aktuellen Zustand keine vollständige Anleitung, kein Lehrbuchkapitel und keine tiefe Anwendungserklärung ersetzen.
Deshalb sind Quellen wichtig. Sie sind die zweite Ebene hinter dem kurzen Eintrag. Wer eine Methode im Atlas wiederfindet, soll von dort aus zu ausführlicheren Erklärungen, Praxisbeispielen, Templates, Anwendungshinweisen oder Originalkontexten weitergehen können.
Der Atlas soll eine Methode auffindbar machen. Die Quellen sollen helfen, sie wirklich zu erarbeiten.
Das macht die Kuration langsamer, aber auch besser. Ein Link ist nur dann hilfreich, wenn er mehr leistet als der kurze Atlas-Eintrag selbst. Gute Quellen vertiefen, zeigen Varianten, erklären Grenzen oder machen den praktischen Einsatz greifbarer. Dadurch kann Methodatlas kompakt bleiben und trotzdem einen Weg in die Tiefe öffnen.
Beziehungen waren der Moment, in dem es klickte
Der nächste Schritt waren Beziehungen. Und da wurde es für mich richtig interessant. Sobald eine Methode Alternativen, Nachbarn und sinnvolle Anschlussstellen bekommt, hört sie auf, ein isolierter Lexikoneintrag zu sein. Sie bekommt eine Position im Raum.
Eine Methode kann eine Entscheidung vorbereiten, braucht aber vielleicht vorher Problemklärung. Eine andere erzeugt Optionen, braucht danach aber Priorisierung. Eine Mapping-Methode macht ein System sichtbar, führt aber noch nicht automatisch zu Handlung. Solche Beziehungen machen sichtbar, was vor, neben oder nach einer Methode liegen kann.
In dem Moment wurde der Atlas räumlich: Methoden lagen untereinander, nebeneinander, voreinander und nacheinander.
Das ist für mich der eigentliche Charme des Projekts. Der Katalog ist die Grundlage. Die Beziehungen sind der Schritt in Richtung Navigation. Wenn Methodatlas später mit Kontextfragen startet, kann das System einzelne Methoden und plausible Wege durch eine Arbeitssituation sichtbar machen.
Visuals machten die Methoden lebendig
Der zweite große Aha-Moment waren die Visuals. Text kann beschreiben, was eine Methode tut. Aber viele Methoden haben eine sichtbare Denkform. Eine Matrix sieht anders aus als ein Flow. Ein Canvas erzeugt andere Erwartungen als ein Systemmodell. Eine Timeline führt anders durch Denken als eine Scorecard.
Als ich anfing, diese Formen als kleine SVG-Orientierungen zu bauen, wurde der Atlas plötzlich viel greifbarer. Eine Methode bekam Text und Silhouette. Man sieht schneller, ob sie Felder, Schritte, Achsen, Rollen, Entscheidungen, Beziehungen oder Sequenzen nutzt. Die Visuals wurden zu einer Abkürzung zum Verstehen.
Die Visuals waren der Punkt, an dem sich Methodatlas zum ersten Mal wirklich wie ein Atlas anfühlte.
Für Methodatlas wurde daraus ein eigenes Arbeitsfeld. Die Visuals sollen ruhig, systematisch und vergleichbar sein. Sie zeigen die Form der Methode und helfen beim Wiedererkennen. Für mich steckt darin viel von der Freude an diesem Projekt: Man baut Datenfelder und kleine Karten für Denkbewegungen.
Was der Atlas heute ist
Die aktuelle Version ist bewusst einfach. Methodatlas basiert auf strukturierten Daten. Die Web-App macht Methoden suchbar, filterbar, vergleichbar und visuell scanbar. Aus vielen verstreuten Notizen, Links, Erinnerungen und Methodenfragmenten ist eine erste zusammenhängende Oberfläche geworden.
Der wichtigste Fortschritt liegt für mich in der Struktur. 283 Methoden sind nicht nur eine Zahl. Sie sind ein Testfeld für das Modell dahinter:
- Tragen die Kategorien?
- Funktionieren die Formen?
- Werden Beziehungen sichtbar?
- Helfen Visuals beim schnellen Begreifen?
- Wo fehlen vertiefende Quellen?
- Welche Einträge sind zu grob?
- Welche Methoden brauchen bessere Grenzen?
Was ich als Nächstes lernen will
Methodatlas ist für mich ein Arbeitswerkzeug und ein Lernsystem zugleich. Mit jedem Eintrag wird klarer, welche Informationen wirklich helfen und welche nur Vollständigkeit simulieren. Mit jeder visuellen Orientierung wird sichtbarer, wie unterschiedlich Methoden tatsächlich funktionieren. Und mit jeder Beziehung im Katalog wird die Frage konkreter, wie ein System aus Kontext eine sinnvolle Methodenauswahl ableiten kann.
Dieser Artikel ist der zweite Teil einer Serie über Methodenauswahl, strukturiertes Methodenwissen und Decision Support. Im ersten Teil ging es um das Problem der Methodenauswahl. Hier ging es um den Bau des Atlas selbst: aus verstreutem Material, einem Datenmodell, Quellen, Beziehungen und Visuals. Im nächsten Teil geht es darum, warum KI bei Methodenarbeit starke Erklärungen liefern kann, aber für gute Empfehlungen strukturiertes Wissen braucht.
Ressource
Die aktuelle Work-in-Progress-Version von Methodatlas findest du hier: Methodatlas öffnen