Das Problem, das es löst
Zwischen „der Fachbereich weiß, was er sehen will" und „ein fertiger Bericht existiert" liegt traditionell ein verlustbehafteter Übersetzungsprozess: Notizen, Screenshots, Zuruf, E-Mails, ein paar PowerPoint-Kästen. Jede Station verliert Information, und am Ende baut jemand irgendetwas, das dann in mehreren Runden zurechtgerückt wird.
Das Mockup-Tool schiebt genau in diese Lücke einen formalen, versionierbaren Vertrag ein. Es erzeugt keine hübschen Bilder zum Vorzeigen — es erzeugt eine Single Source of Truth, die zugleich für Menschen lesbar und für einen KI-Agenten präzise abarbeitbar ist. Der Kern-Trick: Das verbindliche Artefakt ist strukturiertes Markdown, nicht ein Bild.
Die drei Bausteine
Das Tool ist bewusst als kleines, abhängigkeitsarmes System gebaut — kein Backend, kein Build, keine Installation.
| Baustein | Rolle |
|---|---|
| Vorlage | Das Schema. Definiert die Abschnitte, die einen Bericht fachlich vollständig beschreiben. |
| Editor | Interaktiver Drag-and-Drop-Editor im Browser. Klickt das Mockup zusammen und exportiert/importiert das Markdown. |
| Renderer | Rendert das Markdown zu einer maßstabsgetreuen 1280×720-Vorschau. Läuft ohne zusätzliche Abhängigkeiten. |
Alle drei sprechen dasselbe Markdown-Format — Round-trip-getestet. Man kann im Editor bauen, exportieren, das Markdown von Hand nachschärfen, wieder importieren oder direkt rendern. Der gemeinsame Nenner ist immer die Markdown-Datei.
Das Herzstück: Markdown als Vertrag
Ein Mockup ist eine Markdown-Datei mit Kopf-Metadaten und mehreren nummerierten Abschnitten, die den Bericht fachlich vollständig beschreiben. Ein typischer Ausschnitt aus dem Abschnitt „Seiten & Visuals":
### Seite 1: Überblick
| ID | Visual-Typ (Intent) | Position (Zone / Spalten / Reihe) | Dimension(en) | Kennzahl(en) | Filter/Sortierung | Interaktionen |
|----|---------------------|-----------------------------------|---------------|--------------|-------------------|---------------|
| V1 | KPI-Card | Inhalt / 1–3 / R1 | – | Gesamtkosten | – | Standard |
| V5 | Balkendiagramm | Inhalt / 1–6 / R2 | Achse: Region | Gesamtkosten | Sort: absteigend | Standard |Entscheidend ist die Trennung zweier Verbindlichkeitsgrade:
- Verbindlich sind die fachlichen Aussagen — welche Visuals, welche Dimensionen, welche Kennzahlen, welche Filter.
- Näherung ist die Position. Sie wird als grobes Raster angegeben, nicht in Pixeln. Der Agent optimiert die Feinausrichtung selbst.
Das ist die zentrale Designentscheidung: Der Fachbereich soll über Inhalt entscheiden, nicht über Pixel-Koordinaten. Layout-Handwerk bleibt beim Werkzeug.
Das 12×7-Grid: der Übersetzungslayer
Positionen werden im Mockup als Rasterangabe notiert — z. B. Inhalt / 1–6 / R2
bedeutet „Spalten 1 bis 6, Reihe 2". Dahinter steht ein verbindliches
12×7-Grid mit einer exakten, deterministischen Pixel-Übersetzung. Sowohl die
Vorschau als auch der Agent nutzen dieselbe Umrechnung:
x = 24 + (Spalte - 1) * 104
width = 104 * Spaltenspanne - 16
y = 204 + (Reihe - 1) * 72
height = 72 * Reihenspanne - 16Die 104 = 88 px Zellbreite + 16 px Gutter; die 72 = 56 px Zellhöhe + 16 px
Gutter. Der Parser ist dabei bewusst tolerant: Er normalisiert die
verschiedenen Bindestrich-Zeichen (–, —, −), strippt Präfixe wie R oder
Zonennamen und clippt Werte in den gültigen Bereich, statt bei Tippfehlern hart
zu scheitern. Nicht interpretierbare Positionen erzeugen keinen stillen Fehler,
sondern einen rot markierten Fehlerkasten in der Vorschau — das macht Lücken
im Termin sofort sichtbar.
Wichtig ist die Zonentrennung: Das Grid liegt vollständig in der Inhaltszone. Header (Logo, Berichtstitel, Seiten-Navigation), Filter-/ Selektionszone und Footer sind feste Rahmenelemente der Corporate-Vorlage und werden nicht vom Fachbereich positioniert.
Was das Tool an Berichts-Semantik abbildet
Hier wird es technisch interessant, denn das Mockup ist deutlich mehr als eine Kästchen-Skizze. Es modelliert echte Berichts-Konzepte, damit der Agent nicht raten muss:
Visual-Typen als Intent. Der Editor kennt eine feste Typliste (KPI-Card, Card, Balken-, Säulen-, Linien-, Flächen-, Kreis-/Donut-Diagramm, Tabelle, Matrix, Karte, Streudiagramm, Slicer, Textbox). Diese werden intern in fünf Kategorien geclustert (KPI, Diagramm, Tabelle/Matrix, Slicer, Text), die je eine eigene Beispielgrafik und Akzentfarbe bekommen. „Intent" heißt: Der Fachbereich sagt „Balken", der Agent wählt den konkreten Visualtyp.
Kennzahlen fachlich statt technisch. Neue Kennzahlen werden in Prosa beschrieben („Anteil korrektiver Maßnahmen an Gesamtkosten") mit optionaler Format- und Formel-Idee. Die Formel ist ausdrücklich optional — der Agent leitet sie ab. Der Fachbereich muss keine Formelsprache können.
Seiten-Typen. Jede Seite kann als Normal, Drill Through oder Quickinfo/Tooltip markiert werden, plus ein Ausgeblendet-Flag — exakt das gängige Berichts-Modell. Drill-Through-Seiten tragen ihre Drilldown-Felder mit; ausgeblendete Seiten verschwinden aus der Navigation, wie im echten Bericht.
Visual-Interaktionen als Matrix. Paarweise Interaktionen (Quelle → Ziel) werden mit den Modi Filtern / Hervorheben / Keine kodiert. So lässt sich vorab festlegen, dass ein bestimmtes Visual andere nicht cross-filtert — ein Detail, das sonst regelmäßig erst nach Auslieferung nachgefordert wird.
Slicer-Geltungsbereich. Jeder globale Filter trägt, ob er auf alle Seiten oder nur eine bestimmte Seite wirkt.
Quickinfo-Verknüpfungen. Tooltip-Seiten werden den Visuals zugeordnet, die sie beim Hover anzeigen sollen.
Diese Konzepte werden im Editor über einen Inspector gepflegt und beim Export sauber in die entsprechenden Markdown-Abschnitte serialisiert, sodass die Vorschau und der Agent sie wiederfinden.
Die Vorschau ist kein Screenshot — sie ist ein Renderer
Das ist der Punkt, der oft missverstanden wird. Der Renderer parst das Markdown zu einem Objektmodell (Seiten, Visuals, Geometrien, Tooltip-Verknüpfungen) und rendert daraus deterministisch die 1280×720- Vorschau: Header-Chrome, das eingezeichnete Grid, jedes Visual als beschrifteter Kasten mit ID, Typ, Dimensionen und Kennzahlen, plus einer nicht-interaktiven Beispielgrafik je Typ in den Corporate-Theme-Farben.
Der Nutzen: Text und Bild bleiben immer synchron, weil das Bild bei jedem Lauf frisch aus dem Text abgeleitet wird. Es gibt keine „veraltete Skizze"- Klasse von Fehlern. Nach jeder Änderung am Markdown einmal neu rendern — fertig. Und weil keine externen Abhängigkeiten nötig sind, läuft das auf jedem Rechner ohne vorherige Installation.
Der Round-trip und die Übergabe an den Agenten
Der End-to-End-Fluss:
Editor (visuell bauen)
└─ Export ──────────────► Mockup-Markdown ◄── Single Source of Truth
│
Renderer ──────┤ (visuelle Kontrolle im Termin)
│
Import ◄───────┘ (weiterbearbeiten)
│
▼
KI-Agent (Intake / Spezifikation)Bei der Übergabe liest der Orchestrator das Mockup im Intake-/Spezifikations- Schritt und leitet daraus drei Dinge ab:
- Klärungsfragen aus dem Abschnitt „Offene Punkte / Annahmen",
- einen Plan — ein Task je Seite bzw. Visual,
- Abnahmekriterien aus dem entsprechenden Abschnitt.
Die eigentliche Umsetzung geht dann an den ausführenden Bericht-Agenten, der die Grid-Angaben über exakt dieselbe Umrechnung in Pixel-Koordinaten übersetzt, die auch die Vorschau nutzt. Das Mockup ist damit kein unverbindlicher Wunschzettel, sondern speist direkt die Abnahmekriterien der Bau-Pipeline — Anforderung und Prüfung stammen aus derselben Quelle.
Ein angenehmer Nebeneffekt der Markdown-Basis: Versions-Diffs machen Anforderungsänderungen sichtbar. Wenn sich zwischen zwei Terminen etwas ändert, sieht man exakt was — eine Kennzahl mehr, ein Filter anders, eine Seite zusätzlich.
Zwei häufige Fragen
„Gibt das Mockup-Tool nur Screenshots zurück?"
Nein — und das ist konzeptionell der wichtigste Punkt. Das verbindliche Ergebnis ist eine strukturierte Markdown-Datei, also ein maschinenlesbarer, versionierbarer Bauplan. Diese Datei enthält alles Fachliche: Seiten, Visualtypen, Dimensionen, Kennzahlen (inkl. fachlicher Definitionen), Filter, Slicer-Geltungsbereiche, Seiten-Typen wie Drill-Through und Tooltip, Visual-Interaktionen und Abnahmekriterien.
Die Vorschau ist kein Screenshot, sondern eine live aus dem Markdown gerenderte Ansicht — sie dient nur der visuellen Kontrolle im Termin und ist jederzeit reproduzierbar. Ein optionales Skizzen-Bild aus dem Termin kann man ergänzend beilegen, aber es ist nur schmückendes Beiwerk, nie die Grundlage. Der KI-Agent konsumiert das Markdown, nicht ein Bild. Ein Bild allein wäre für die automatisierte Weiterverarbeitung wertlos; die Stärke des Tools liegt gerade darin, die Anforderung strukturiert statt pixelig festzuhalten.
„Soll der Fachbereich das Tool selbst ausfüllen?"
Nein. Das Tool ist als moderiertes Werkzeug gedacht, nicht als Self-Service für den Fachbereich. Ein Spezialist — ein Data Analyst oder Business Analyst — füllt es gemeinsam mit dem Fachbereich im Anforderungstermin aus und baut die Wireframes auf, typischerweise per Screen-Share.
Das ist auch am Design ablesbar und bewusst so gebaut:
- Der Editor ist ein kollaborativer Termin-Baukasten („im Termin gemeinsam bauen"), kein Formular zum Alleinausfüllen. Der Fachbereich klickt die Seite visuell zusammen und sieht sofort eine realistische Vorschau — er muss weder Markdown tippen noch das Raster verstehen.
- Die Aufgabenteilung entspricht genau den beiden Verbindlichkeitsgraden: Der Fachbereich liefert das Was (Kernfragen, Kennzahlen, Visuals, Interaktionen) — das ist verbindlich. Der Analyst übersetzt das sauber ins Schema, achtet auf Konsistenz, pflegt die technischen Felder (Spalten-/ Kennzahl-Namen, Formel-Ideen, Grid-Positionen) und hält die offenen Punkte fest.
- Konzepte wie das 12×7-Grid, Drill-Through-Felder, die Interaktions-Matrix oder Formel-Ideen sind fachliches Handwerkszeug, das ein Analyst beherrscht — es dem Fachbereich allein zu überlassen, würde genau die Übersetzungsverluste zurückholen, die das Tool eliminieren soll.
Kurz: Der Fachbereich bringt die Fachlichkeit, der Analyst moderiert und formalisiert, und beide gemeinsam produzieren im Termin ein abgestimmtes Mockup, das anschließend als sauberer Vertrag an den KI-Agenten geht.
