„Kannst du das Admin Tool mal schön machen?“ – die Frage klingt harmlos. Was danach passiert, ist meistens dasselbe: Jemand legt ein Layout an, das aus dem Landingpage Baukasten stammt. Großzügige Abstände, ein Logo Balken oben, viel Weißraum, ein zentraler Button. Sieht gut aus im Screenshot. Nach zwei Wochen im echten Einsatz hasst es jeder im Team.
Der Grund ist simpel. Ein Shop wird ein paar Minuten benutzt. Ein Developer Tool wird sechs Stunden am Tag benutzt. Das sind zwei völlig verschiedene Disziplinen, und die Muster aus der einen funktionieren in der anderen nicht.
Vibe Coding Schulung: in zwei Stunden zur deployten Landing Page
Remote, ohne US Abo, mit OpenCode und lokalen Modellen. Ihr baut live mit, statt zuzuschauen.
- Astro Projekt von der leeren Mappe bis zum Deployment
- OpenCode im Terminal, lokale Modelle über Ollama
- Daten bleiben im eigenen Netz, kein Abo bei US Anbietern
- Danach laufende Begleitung statt Zertifikat und tschüss
1. Es gibt keinen Happy Path
Im Shop ist der Weg klar: suchen, filtern, in den Warenkorb, zahlen. Darauf optimiert ihr, und alles andere ist Randfall.
In einem Werkzeug gibt es diesen Weg nicht. Der eine springt zwanzigmal am Tag zwischen Log und Detailansicht. Die nächste öffnet nur den Export und sonst nie etwas. Was in der Analyse wie ein exotischer Randfall aussieht, ist für ein Drittel der Nutzer der Hauptweg. Wer ein Tool auf einen einzigen gedachten Ablauf hin baut, macht es für alle anderen langsam.
Praktische Konsequenz: Zählt nicht Klickpfade, sondern Wechsel. Jeder Wechsel zwischen zwei Bereichen, der öfter als ein paar Mal pro Stunde passiert, gehört auf denselben Bildschirm.
2. Das Layout folgt der eigentlichen Arbeit
Es gibt zwei Sorten von Tools. In der einen passiert die Arbeit an einer Stelle: der Editor, die Karte, der Graph. Dann bekommt diese Fläche den Löwenanteil, und alles andere ordnet sich unter. In der anderen verteilt sich die Arbeit gleichmäßig auf zwei oder drei Bereiche, etwa Anfrage und Antwort. Dann darf keiner davon dominieren.
Der häufigste Fehler ist die Mischung: Eine riesige Kopfzeile mit Logo, darunter drei gleich große Kacheln, und die Fläche, an der wirklich gearbeitet wird, hat 40 Prozent Höhe. Der Logo Balken ist übrigens fast immer verzichtbar. Niemand vergisst, in welchem Programm er gerade steckt.
3. Eine Aufgabe, ein Panel
Wenn für eine kleine Änderung drei Fenster nötig sind, ist das Design falsch. Alles, was zu einer Aufgabe gehört, gehört in denselben Bereich. Das gilt auch für Kleinkram, den man beim Entwerfen gern übersieht: Statuszeilen, Warnungen, sekundäre Aktionen. Die passen sauber in eine Fußzeile am unteren Rand des Panels, wo sie erreichbar sind, ohne die Oberfläche vollzustellen.
Bei Auswahlelementen lohnt eine simple Regel: bis drei Optionen sichtbar nebeneinander als Schalter, ab vier ein Dropdown. Jedes aufgeklappte Menü kostet einen Klick und eine halbe Sekunde Aufmerksamkeit. Mal zweihundert am Tag ist das kein Detail mehr.
4. Nichts verdecken, was gerade geändert wird
Der Klassiker: Ein Dialog legt sich über genau die Stelle, deren Wert man einstellen will. Man schiebt den Regler, sieht nichts, schließt den Dialog, das Ergebnis passt nicht, und das Spiel beginnt von vorn.
Einstellungen gehören neben die Ansicht, nicht darüber. Wenn ein Overlay unvermeidbar ist, merkt es sich Scrollposition und aktiven Tab. Sonst sucht der Nutzer bei jedem Anlauf dieselbe Zeile neu.
5. Einstellbarkeit ist kein Luxus
Bei Software, die täglich stundenlang läuft, summiert sich jede Winzigkeit. Panels in der Breite ziehen, unwichtige schließen, wichtige anheften, mehrere Dateien nebeneinander offen halten – das sind keine Nice to haves, sondern der Unterschied zwischen einem Werkzeug und einer Zumutung.
Ein eigenes Tab System nachzubauen ist allerdings deutlich aufwendiger, als es aussieht. Eine vertikale Liste mit angehefteten Einträgen bringt neunzig Prozent des Nutzens für einen Bruchteil des Aufwands. Und wenn ihr im Browser lauft: Lasst zu, dass Einträge in einem neuen Tab geöffnet werden. Der Browser kann das bereits.
6. Euer Tool ist nie das einzige Fenster
Interne Werkzeuge laufen selten im Vollbild. Sie stehen schmal neben der IDE, unten als Konsole, oder in der Ecke wie ein Taschenrechner. Testet die Oberfläche deshalb bei 600 Pixel Breite und bei geringer Höhe, auch wenn niemand das Tool je auf dem Handy öffnet.
Dazu gehören zwei Kleinigkeiten, die überraschend viel ausmachen: Scrollbalken bewusst gestalten, weil in einem Panel Layout sehr viele davon sichtbar sind. Und Fehlermeldungen als vollwertigen Inhalt behandeln, nicht als roten Streifen mit Codenummer. Wer den Fehler nicht versteht, wechselt ins Log, und schon ist der Kontext weg.
Warum das 2026 wieder wichtig wird
KI Agents bauen Oberflächen in Sekunden. Nur haben sie Millionen Landingpages und Shops gesehen und vergleichsweise wenige gute Werkzeuge. Ohne klare Vorgabe kommt genau das raus, was oben beschrieben ist: Hero Bereich, Logo Balken, drei Kacheln, viel Luft. Für ein internes Tool ist das die falsche Vorlage.
Deshalb gehören diese Regeln in die Projektregeln, bevor der erste Prompt läuft. Genau wie Testabdeckung und Ordnerstruktur. Wie so ein Setup aussieht, steht bei den Vibe Coding Best Practices und im Überblick zu Vibe Coding. Wer Oberflächen zusätzlich barrierefrei aufstellen will, findet den Einstieg im barrierefreien Webdesign.
Der Praxistest
Setzt euch neben jemanden, der euer Tool täglich benutzt, und schaut zwanzig Minuten zu. Ohne zu reden. Jede Stelle, an der die Person zweimal dasselbe Fenster öffnet, jede Stelle, an der sie scrollt um etwas wiederzufinden, ist eine Aufgabe für die nächste Iteration. Das ist unbequemer als jeder Design Review und liefert mehr.
Interne Tools mit KI bauen, ohne Shop Layout
In der NCA Vibe Coding Schulung lernt ihr, wie ihr Agents klare Regeln gebt und aus einer leeren Mappe eine deployte Anwendung macht. Termine auf Anfrage, kostenloses Kennenlernen vorab, danach transparente Minuten Abrechnung.
