Ein UI kann in Figma, Sketch oder XD perfekt aussehen – und im fertigen Frontend trotzdem „anders“ wirken. Der häufigste Grund ist keine schlechte Umsetzung, sondern unklare oder fehlende Spezifikationen. Gemeint sind die konkreten Angaben, die ein Design eindeutig machen: Abstände, Zustände, Verhalten bei langen Texten, Bildzuschnitte, Interaktionen oder Regeln für responsive Varianten. Sobald diese Infos fehlen, entstehen Interpretationen – und damit unnötige Schleifen.
Dieser Leitfaden zeigt, wie Spezifikationen so vorbereitet werden, dass sie im Alltag funktionieren: verständlich, knapp, testbar. Dabei geht es nicht um mehr Dokumentation, sondern um die richtigen Details an den richtigen Stellen.
Welche Fragen Spezifikationen im UI beantworten müssen
Eine gute Spezifikation beantwortet typische Umsetzungsfragen, bevor sie gestellt werden. Das spart Zeit und verhindert, dass Entscheidungen „nebenbei“ im Code fallen. Besonders wichtig: Spezifikationen beschreiben nicht nur, wie etwas aussieht, sondern auch, wie es sich verhält.
Layout: Was ist fix, was ist flexibel?
Entwickler:innen müssen wissen, welche Bereiche wachsen dürfen und welche nicht. Beispiele:
- Text kann 1–3 Zeilen umfassen: Was passiert bei 4 Zeilen?
- Buttons im Header: Dürfen sie umbrechen oder werden sie zu einem Icon?
- Listen und Cards: Werden Spalten reduziert, oder bleibt die Breite gleich und es wird horizontal gescrollt?
Wichtig ist eine klare Aussage pro Komponente: „Breite flexibel, Höhe durch Inhalt“ oder „Höhe fix, Text wird mit Auslassungspunkten gekürzt“. Eine solche Regel ist oft hilfreicher als zehn Detail-Screens.
Inhalte: Welche echten Daten sind zu erwarten?
Layouts werden oft mit idealen Inhalten gestaltet. In der Praxis kommen lange Namen, fehlende Bilder oder Sonderzeichen. Spezifikationen sollten deshalb festlegen:
- Maximale Textlängen (z. B. Produkttitel, Button-Labels) als Regel, nicht als „schöner Beispielsatz“.
- Fallbacks: Was wird angezeigt, wenn Bild/Avatar/Subtitle fehlt?
- Formatierung: Zahlen, Datumsformat, Trennzeichen (z. B. „1.234,56 €“).
Hier hilft eine simple Tabelle pro Modul: Feldname, Beispielwert, Sonderfall (leer/zu lang).
Zustände: Was passiert bei Hover, Fokus, Fehler?
Viele UIs werden nur im „Normalzustand“ spezifiziert. Im Frontend zählen jedoch die Zustände. Gerade Formulare profitieren von klaren Regeln. Wer dieses Thema vertiefen möchte, findet praxisnahe Hinweise in Formular-UX optimieren: Validierung, Fehler, Barrierefreiheit.
Mindestens sollten definiert sein:
- Hover/Pressed/Disabled
- Fokus (Tastaturbedienung)
- Fehler- und Erfolgszustände (Texte, Farben, Icons)
- Ladezustand (Spinner, Skeleton, Button „lädt…“)
Für Teams, die häufig diskutieren, was „Fokus“ genau bedeutet: Eine klare Regel ist besser als eine Farbe. Beispiel: „Fokus ist immer sichtbar, auch auf farbigen Flächen; er darf nicht ausschließlich über Farbe kommuniziert werden.“
Welche Spezifikationen am meisten Impact haben
Nicht jede Pixelangabe muss dokumentiert werden. In der Praxis gibt es ein paar Stellschrauben, die über 80% der typischen Rückfragen verhindern. Hier lohnt sich Genauigkeit.
Spacing-System: Abstände als Regeln statt Einzelwerte
Abstände wirken nur konsistent, wenn sie einem System folgen. Eine Spezifikation sollte deshalb nicht nur „16 px hier, 24 px dort“ sammeln, sondern ein kleines Regelwerk liefern:
- Welche Abstands-Stufen gibt es (z. B. S/M/L)?
- Wann wird welche Stufe verwendet (z. B. „zwischen Elementen“, „zwischen Gruppen“)?
- Wie verhalten sich Abstände bei kleinen Screens?
Wer das bereits als Designsystem pflegt, kann intern gut auf Designsystem-Abstände im UI verweisen, statt alles im Ticket zu wiederholen.
Typografie-Spezifikationen: Hier entstehen die meisten Abweichungen
Schrift wirkt im Browser schnell anders: Rendering, Zeilenumbrüche, Fallback-Fonts. Spezifikationen sollten daher mehr enthalten als „Font 16/24“:
- Schriftfamilie inkl. Fallbacks (z. B. „Inter, system-ui, sans-serif“)
- Schriftgewicht pro Stil (Regular/Medium/Bold) und wo es eingesetzt wird
- Zeilenhöhe als Verhältnis oder fester Wert (konsequent pro Stil)
- Regeln für Umbrüche: maximal Zeilen, Silbentrennung ja/nein
Eine gute Praxis ist, Textstile nicht nur zu benennen („Body M“), sondern die Verwendung zu beschreiben („Fließtext in Cards und Detailseiten“). So kann im Code leichter ein Token oder eine Klasse zugeordnet werden.
Komponenten-Verhalten: Zustandslogik statt Screens
Viele Screens zu zeichnen kostet Zeit, löst aber nicht automatisch Logik-Fragen. Oft genügt eine kurze Beschreibung:
- „Wenn Filter aktiv sind, erscheint eine Badge mit Anzahl“
- „Pagination wird ab 7 Seiten kompakt mit … dargestellt“
- „Tooltip öffnet bei Hover und Fokus, schließt bei Escape“
Das ist besonders wichtig bei Elementen, die sich wiederholen (Listen, Filterleisten, Tabellen). Statt 12 Varianten zu zeichnen, sind 6 klare Regeln meist effektiver.
Interaktionszustände: Fokus sichtbar, Klickflächen nachvollziehbar
Interaktion ist nicht nur Animation. Es geht um Rückmeldung und Bedienbarkeit. Spezifikationen sollten festlegen:
- Welche Fläche ist klickbar (nur Text/Icon oder die ganze Zeile/Card)?
- Wie sieht der Fokuszustand aus (auch auf Touch-Geräten relevant für Tastatur/Assistive Tech)?
- Welche Zustände sind erlaubt (z. B. „disabled“ nur bei inaktiven Aktionen, nicht als Workaround)?
Wenn Interaktionen bewusst eingesetzt werden sollen, hilft ein konsistenter Ansatz wie in UI-Mikrointeraktionen gestalten – vor allem für Timing, Feedback und „nicht nerven“.
So werden Spezifikationen in Layout-Tools wirklich nutzbar
Das Ziel ist nicht ein perfektes Doku-Wiki, sondern ein Übergabe-Paket, das im Alltag sofort verstanden wird. Layout-Tools bieten dafür gute Mittel – wenn sie konsequent genutzt werden.
Benennungen, die im Code wiedererkennbar sind
Wenn Layer „Rectangle 123“ heißen, kann niemand zügig prüfen, was gemeint ist. Besser sind Namen, die den Zweck ausdrücken:
- „Button / Primary / Default“ statt „Button 1“
- „Card / Product / Compact“ statt „Group 7“
- „Input / Email / Error“ statt „Textfield red“
Damit wird klar, was wiederverwendbar ist und was ein Sonderfall bleibt. Zusätzlich erleichtert es das Debugging: Ein Screenshot mit dem Namen reicht oft, um im Code die passende Komponente zu finden.
Kommentare: kurz, testbar, ohne Interpretationsspielraum
Kommentare sollten wie kleine Regeln klingen, nicht wie Wünsche. Beispiele:
- Schlecht: „Hier bitte etwas mehr Luft.“
- Besser: „Zwischen Titel und Preis: Abstand = M-Stufe des Spacing-Systems.“
- Schlecht: „Bild soll immer gut aussehen.“
- Besser: „Bild wird mittig zugeschnitten, Fokus auf Mitte; bei fehlendem Bild wird Platzhalter angezeigt.“
Wenn eine Aussage nicht überprüfbar ist, führt sie später zu Diskussionen. Prüfbarkeit ist das wichtigste Qualitätsmerkmal.
Assets richtig: SVG, Export, Qualitätsfallen
Bei Icons, Logos und Illustrationen entstehen viele Reibungen durch falsche Exporte. Klare Regeln sparen hier Zeit:
- Icons als SVG, wenn sie skalieren und einfärbbar sein sollen
- Fotos als optimierte Webformate, wenn sie großflächig eingesetzt werden
- Keine „zufälligen“ Effekte, die im SVG schwer reproduzierbar sind (z. B. komplexe Masken), ohne Absprache
Für typische Export-Fallen und saubere SVGs hilft SVG fürs Web – Export in Illustrator und Figma korrekt.
Praxis: Eine „So geht’s“-Box für saubere Übergaben
- Pro Screen eine kurze Liste: Layout-Regeln, Inhalte, Zustände.
- Pro Komponente definieren: Was ist flexibel (Breite/Höhe), was ist fix.
- Mindestens 4 Zustände dokumentieren: Default, Hover/Pressed, Fokus, Disabled oder Error.
- Textregeln festlegen: maximale Zeilen, Kürzung (Auslassungspunkte) oder Umbruch.
- Assets benennen und Export-Format festlegen (SVG/PNG/JPG/WebP je nach Einsatz).
- Ein „Edge-Case“-Beispiel ergänzen: extrem langer Name, leeres Bild, sehr viele Tags.
- Übergabe mit einer kurzen Review-Runde abschließen: 10 Minuten gemeinsamer Walkthrough sparen Tage.
Mini-Fallbeispiel: Warum „16 px“ allein nicht reicht
Eine Card-Komponente wurde mit 16 px Innenabstand gestaltet. In der Umsetzung wirkte sie „zu eng“. Der Grund: Im Design waren Titel und Text kurz, im echten Content war der Titel zweizeilig, und die Tags darunter brachen um. Der Innenabstand war korrekt, aber die vertikale Rhythmik fehlte: Es gab keine Regel, wie viel Abstand zwischen Textblöcken gelten soll, wenn sie umbrechen.
Die Lösung war nicht „mehr Padding“, sondern eine kleine Spezifikation:
- Innenabstand der Card bleibt gleich (Padding).
- Abstand zwischen inhaltlichen Gruppen folgt dem Spacing-System (z. B. S zwischen Label und Titel, M zwischen Titel und Metadaten).
- Bei Zeilenumbruch wird der Gruppenabstand nicht reduziert.
Damit war das Verhalten für lange Inhalte klar, und die Card blieb stabil – ohne dass pro Sonderfall ein neues Design nötig war.
Checkliste: Übergabe-Qualität in 5 Minuten prüfen
| Prüffrage | Woran erkennbar? |
|---|---|
| Gibt es Regeln für lange/fehlende Inhalte? | Mindestens ein Edge-Case pro Screen/Komponente ist beschrieben. |
| Sind Zustände vollständig? | Default + Fokus + Error/Disabled + Interaktion sind sichtbar oder beschrieben. |
| Sind Abstände systematisch statt zufällig? | Abstands-Stufen sind benannt, nicht nur einzelne Pixelwerte. |
| Ist klar, was klickbar ist? | Klickflächen sind beschrieben (ganze Zeile/Card oder nur Button/Link). |
| Kann man es testen? | Aussagen sind überprüfbar („max. 2 Zeilen“, „Fallback bei leerem Bild“). |
FAQ: Häufige Fragen zu Design-Spezifikationen
Wie detailliert müssen Spezifikationen sein?
So detailliert, dass keine „Designentscheidungen“ mehr beim Implementieren getroffen werden müssen. Pixelgenauigkeit ist weniger wichtig als klare Regeln für Verhalten, Zustände und Sonderfälle.
Was ist wichtiger: mehr Screens oder mehr Regeln?
Für wiederkehrende Komponenten sind Regeln meist wertvoller als viele Screens. Zusätzliche Screens helfen vor allem, wenn ein Flow komplex ist oder Zustände sonst schwer vorstellbar sind.
Wie lassen sich Spezifikationen mit einem Designsystem verbinden?
Indem Spezifikationen auf gemeinsame Bausteine verweisen: Textstile, Abstands-Stufen, Farbrollen (z. B. „Error“, „Surface“). Damit bleibt die Übergabe kurz und konsistent, und Änderungen lassen sich zentral durchführen.
Was tun, wenn Entwickler:innen trotzdem anders umsetzen?
Dann fehlt oft eine gemeinsame Definition, was „korrekt“ bedeutet. Hilfreich ist ein kurzer Walkthrough vor dem Start und eine Review nach der ersten Umsetzung. Wichtig ist dabei, über Regeln zu sprechen („Warum bricht das hier um?“) statt über Geschmack.
