Du öffnest eine Website.

Oben befindet sich ein Menü.

Darunter ein Suchfeld.

Neben einem Text steht ein Button.

Produkte erscheinen als Karten.

Ein Formular besitzt Eingabefelder, Checkboxen und eine Schaltfläche zum Absenden.

All diese sichtbaren und bedienbaren Elemente bilden zusammen das User Interface, kurz UI.

UI Design beschäftigt sich damit, wie diese Oberfläche gestaltet ist.

Vereinfacht:

Nutzer
↓
Benutzeroberfläche
↓
digitales System

Das Interface ist die Schicht, über die ein Mensch mit einer Website, App oder Software kommuniziert.

Er klickt nicht direkt auf eine Datenbank.

Er verändert nicht unmittelbar Serverwerte.

Er benutzt Buttons, Felder, Menüs und andere Oberflächenelemente.

Genau diese Ebene gestaltet UI Design.

UI bedeutet User Interface

User Interface lässt sich mit Benutzeroberfläche übersetzen.

Dazu gehören beispielsweise:

Buttons

Links

Navigation

Suchfelder

Formulare

Checkboxen

Dropdowns

Tabs

Cards

Dialogfenster

Benachrichtigungen

Icons

UI Design entscheidet unter anderem:

Wie sehen diese Elemente aus?

Wie unterscheiden sie sich voneinander?

Welches Element ist besonders wichtig?

Wie sieht ein Button aus, wenn er gedrückt wird?

Wie wird ein Fehler angezeigt?

Wie erkennt man ein deaktiviertes Feld?

UI Design ist damit wesentlich mehr als die Wahl schöner Farben.

Was ist der Unterschied zwischen UI und UX?

Im vorherigen Artikel zu UX Design haben wir User Experience als gesamtes Nutzungserlebnis betrachtet.

UI ist enger.

Ein hilfreiches Modell lautet:

UX
↓
gesamte Nutzungserfahrung

UI
↓
sicht- und bedienbare Oberfläche

Beispiel:

Du möchtest einen Flug buchen.

Zur UX gehören:

Wie einfach findest du einen Flug?

Sind Preise transparent?

Kannst du deine Buchung ändern?

Verstehst du die Gepäckregeln?

Funktioniert die Zahlung?

Zum UI gehören dagegen konkrete Elemente wie:

Datumsauswahl,

Preiskarten,

Buttons,

Formularfelder,

Navigation,

Checkboxen.

Gute UI ist kein Ersatz für gute UX

Ein Checkout kann fantastisch aussehen.

Jedes Eingabefeld perfekt gestaltet.

Farben harmonisch.

Animationen elegant.

Wenn trotzdem 28 unnötige Pflichtfelder ausgefüllt werden müssen, ist der Vorgang schlecht.

UI kann also hervorragend sein, während die UX schlecht bleibt.

Umgekehrt kann ein funktional guter Ablauf durch schlechtes UI unnötig schwer verständlich werden.

Deshalb gehören beide Ebenen zusammen:

UX
→ Was soll für den Nutzer funktionieren?

UI
→ Wie wird diese Funktion sichtbar und bedienbar?

UI Design übersetzt Funktionen in sichtbare Elemente

Angenommen, eine Anwendung besitzt technisch die Funktion:

Datei löschen.

Diese Funktion braucht eine Oberfläche.

Vielleicht einen Button:

[ Datei löschen ]

Nun entstehen sofort weitere Designfragen:

Soll der Button rot sein?

Soll er genauso stark aussehen wie „Speichern“?

Braucht es ein Papierkorb-Icon?

Was passiert nach dem Klick?

Erscheint eine Sicherheitsabfrage?

Wie sieht diese aus?

UI Design macht aus einer abstrakten Softwarefunktion eine verständliche Interaktion.

Interfaces bestehen aus Komponenten

Komplexe Oberflächen werden normalerweise nicht Element für Element vollkommen neu gestaltet.

Stattdessen entstehen wiederverwendbare Komponenten.

Zum Beispiel:

Button

Textfeld

Card

Modal

Alert

Navigation Item

Aus solchen Bausteinen entstehen ganze Seiten.

Das erinnert an Lego:

Komponenten
↓
Bereiche
↓
Seiten
↓
gesamte Anwendung

Je konsistenter diese Komponenten gestaltet sind, desto leichter lässt sich die Oberfläche verstehen.

Warum Konsistenz im UI so wichtig ist

Angenommen, ein blauer Button bedeutet auf Seite eins:

Speichern.

Auf Seite zwei bedeutet derselbe blaue Button:

Abbrechen.

Auf Seite drei:

Löschen.

Der Nutzer muss bei jeder Seite neu lernen, was die Gestaltung bedeutet.

Ein gutes UI-System versucht dagegen:

gleiche Funktion
→ ähnliche Darstellung

und:

unterschiedliche Bedeutung
→ erkennbare Unterscheidung

Das reduziert Lernaufwand.

Ein Button ist nicht einfach ein farbiges Rechteck

Ein Button besitzt eine Bedeutung.

Er fordert eine Aktion aus.

Zum Beispiel:

[ Speichern ]

[ Kaufen ]

[ Nachricht senden ]

Damit der Nutzer dies versteht, muss der Button als interaktives Element erkennbar sein.

Das geschieht durch eine Kombination aus:

Form,

Farbe,

Kontrast,

Beschriftung,

Position,

Reaktion auf Interaktion.

Primary und Secondary Actions

Nicht jede Aktion ist gleich wichtig.

Angenommen, ein Formular besitzt:

Speichern

und:

Abbrechen

Wenn beide Buttons gleich stark gestaltet sind, muss der Nutzer stärker nachdenken.

Besser kann sein:

[ SPEICHERN ]    Abbrechen

Die Hauptaktion erhält mehr visuelles Gewicht.

Man spricht häufig von:

Primary Action

und:

Secondary Action.

Eine Primary Action ist die wichtigste Handlung

Beispielsweise:

Checkout:

[ Jetzt kaufen ]

Registrierung:

[ Konto erstellen ]

Kontaktformular:

[ Nachricht senden ]

Diese Aktion darf stärker hervortreten.

Secondary Actions treten zurück

Zum Beispiel:

Zurück

Später

Abbrechen

Sie bleiben auffindbar, konkurrieren aber nicht unnötig mit der Hauptaktion.

Nicht jeder Bildschirm braucht fünf Primary Buttons

Wenn gleichzeitig sichtbar sind:

JETZT KAUFEN

JETZT TESTEN

NEWSLETTER

KONTAKT

DOWNLOAD

sind faktisch wieder alle gleich wichtig.

Die visuelle Priorisierung bricht zusammen.

Eine Oberfläche sollte möglichst klar machen:

Was ist hier die wahrscheinlich wichtigste nächste Aktion?

Destructive Actions brauchen besondere Behandlung

Manche Aktionen sind potenziell gefährlich.

Zum Beispiel:

Konto löschen

Datei endgültig entfernen

Datenbank zurücksetzen

Sie sollten nicht versehentlich genauso aussehen wie:

Speichern

Eine unterschiedliche Darstellung hilft.

Häufig wird dafür Rot verwendet.

Wichtiger als die konkrete Farbe ist jedoch die klare Unterscheidung.

Kritische Aktionen dürfen zurückhaltender positioniert sein

Beispielsweise:

[ Speichern ]

Abbrechen

Konto löschen

„Konto löschen“ muss verfügbar sein.

Es muss aber nicht die visuell dominanteste Aktion der Seite sein.

Buttonbeschriftungen sollten die Handlung erklären

Schwach:

OK

Weiter

Ja

Besser:

Änderungen speichern

Zur Zahlung

Datei endgültig löschen

Der Button selbst kann damit bereits erklären, was passieren wird.

Icons können Texte ergänzen

Zum Beispiel:

🗑 Löschen

Das Icon unterstützt die Bedeutung.

Es sollte aber nicht automatisch den Text ersetzen.

Denn nicht jedes Symbol ist für jeden Menschen eindeutig.

Ein Icon ohne Beschriftung kann missverständlich sein

Beispiel:

⋮

Bedeutet das:

Weitere Optionen?

Menü?

Sortierung?

Manche Interfacekonventionen sind verbreitet.

Andere weniger.

Bei wichtigen Funktionen kann eine Textbeschriftung die Verständlichkeit deutlich verbessern.

Bekannte Icons sind trotzdem nützlich

Zum Beispiel:

Lupe:

Suche

Papierkorb:

Löschen

Zahnrad:

Einstellungen

Doch auch bei bekannten Symbolen hängt Verständlichkeit vom Kontext ab.

Icons brauchen einen konsistenten Stil

Ein Interface verwendet:

ein gefülltes schwarzes Symbol,

daneben ein dünnes Outline-Icon,

daneben ein farbiges Emoji.

Das wirkt schnell zusammengestückelt.

Ein Icon-System sollte möglichst ähnliche Eigenschaften besitzen:

Linienstärke

Größe

Formensprache

Ausrichtung

Größe beeinflusst Bedeutung

Ein riesiger Button zieht mehr Aufmerksamkeit auf sich als ein kleiner Textlink.

Das ist gewollt, wenn der Button wichtiger ist.

Problematisch wird es, wenn ein unwichtiger Button aufgrund seiner Gestaltung das gesamte Interface dominiert.

UI und visuelle Hierarchie hängen deshalb eng zusammen.

Interaktive Elemente brauchen Zustände

Ein Button existiert nicht nur in einem einzigen Zustand.

Er kann beispielsweise sein:

Default

Hover

Focus

Active

Disabled

Loading

Ein gutes UI definiert diese Zustände bewusst.

Was ist der Default State?

Der normale Ruhezustand.

Beispiel:

[ Speichern ]

Noch keine Interaktion.

Was ist Hover?

Auf Geräten mit Maus kann der Nutzer den Zeiger über das Element bewegen.

Der Button könnte sich leicht verändern.

Zum Beispiel:

etwas dunkler werden.

Das signalisiert:

Dieses Element reagiert.

Hover darf keine essentielle Information enthalten

Auf Touchscreens existiert der klassische Hover nicht.

Wenn eine Funktion nur sichtbar wird, sobald eine Maus darüber fährt, kann sie mobil unzugänglich sein.

Was ist Active?

Der Button wird gerade gedrückt.

Eine leichte visuelle Veränderung kann zeigen:

Interaktion erkannt

Das gibt unmittelbares Feedback.

Was ist Focus?

Focus ist besonders für Tastaturbedienung wichtig.

Wenn ein Nutzer mit Tab durch eine Seite navigiert, muss sichtbar sein, welches Element aktuell fokussiert ist.

Zum Beispiel:

┌───────────────────┐
│    Speichern      │
└───────────────────┘
      Fokus

Ohne sichtbaren Fokus ist Tastaturnavigation kaum sinnvoll nutzbar.

Focus und Hover sind nicht dasselbe

Hover:

Maus befindet sich darüber

Focus:

Element ist aktuell für Eingabe ausgewählt

Beide Zustände können gleichzeitig oder getrennt auftreten.

Das Interface sollte sie nicht gedankenlos gleichsetzen.

Was bedeutet Disabled?

Manchmal ist eine Aktion gerade nicht verfügbar.

Zum Beispiel:

[ Speichern ]

ist deaktiviert, weil keine Änderung vorgenommen wurde.

Oder:

[ Weiter ]

ist nicht möglich, weil eine Pflichtangabe fehlt.

Deaktivierte Buttons sollten als deaktiviert erkennbar sein

Aber sie sollten nicht so unsichtbar werden, dass Nutzer überhaupt nicht verstehen:

Welche Aktion wäre später verfügbar?

Sehr heller grauer Text auf kaum sichtbarem Hintergrund kann problematisch sein.

Disabled kann außerdem UX-Probleme erzeugen

Ein Nutzer sieht:

[ Weiter ]

aber der Button funktioniert nicht.

Warum?

Wenn die Ursache nicht klar ist, entsteht Frust.

Besser kann sein:

fehlendes Feld markieren

oder:

kurze Erklärung anzeigen.

Loading State

Ein Nutzer klickt:

[ Bericht erstellen ]

Die Berechnung dauert.

Der Button sollte nun vielleicht anzeigen:

[ Wird erstellt ... ]

und weitere Klicks verhindern.

So entstehen nicht versehentlich fünf identische Jobs.

Ein Spinner ist eine UI-Komponente

Zum Beispiel:

◌ Wird gespeichert ...

Er zeigt:

Das System arbeitet.

Wie bereits im UX-Artikel beschrieben, ersetzt ein Ladeindikator aber keine vernünftige Performance.

Buttons brauchen ausreichende Klickflächen

Besonders auf Touchgeräten.

Ein winziger Button:

x

kann mit Maus funktionieren.

Mit Daumen aber schwer zu treffen sein.

Die sichtbare Grafik kann klein bleiben, während die tatsächlich klickbare Fläche größer ist.

Abstand zwischen Buttons verhindert Fehlbedienung

Gefährlich:

[ Speichern ][ Löschen ]

wenn beide winzig nebeneinander liegen.

Mehr Raum:

[ Speichern ]     [ Löschen ]

reduziert das Risiko versehentlicher Aktionen.

Formulare sind eines der wichtigsten UI-Systeme

Fast jede Website besitzt Formulare.

Zum Beispiel:

Login,

Suche,

Kontakt,

Checkout,

Registrierung,

Filter,

Einstellungen.

Ein Formular besteht aus mehreren Komponenten.

Label
↓
Eingabefeld
↓
Hilfetext
↓
Fehlermeldung

Alle vier sollten zusammenarbeiten.

Labels sollten sichtbar sein

Beispiel:

E-Mail-Adresse

[_____________________]

Der Nutzer weiß, was erwartet wird.

Placeholder sind kein vollwertiger Ersatz für Labels

Man sieht häufig:

[ E-Mail-Adresse ]

Der Hinweis befindet sich im Feld.

Sobald der Nutzer schreibt, verschwindet er.

Dann kann bei mehreren Feldern unklar werden:

Was gehörte hier eigentlich hinein?

Ein dauerhaft sichtbares Label ist häufig robuster.

Placeholder können Beispiele liefern

Zum Beispiel:

Telefonnummer

[ +43 660 1234567 ]

Das Label erklärt:

Was?

Der Placeholder zeigt:

Wie ungefähr?

Das sind unterschiedliche Funktionen.

Pflichtfelder sollten nachvollziehbar sein

Ein Nutzer sollte nicht erst nach dem Absenden feststellen:

Sieben Felder waren zwingend erforderlich.

Pflichtangaben können vorher deutlich gekennzeichnet werden.

Noch besser: nur wirklich notwendige Felder verlangen

Das ist allerdings bereits stärker eine UX- als reine UI-Entscheidung.

UI kann schlechte Prozessentscheidungen nur begrenzt retten.

Hilfetexte sollten dort stehen, wo sie benötigt werden

Beispiel Passwort:

Passwort

[_____________________]

Mindestens 12 Zeichen.

Der Nutzer kennt die Regel bereits vor dem Fehler.

Fehlermeldungen sollten nahe am Problem erscheinen

Schlecht:

Ganz oben:

Das Formular enthält einen Fehler.

Bei 25 Feldern.

Besser:

direkt beim betroffenen Feld.

E-Mail-Adresse

[ reinhard@ ]

Bitte gib eine vollständige E-Mail-Adresse ein.

Fehlerfarbe allein genügt nicht

Nur:

roter Rahmen

kann für manche Nutzer schwer erkennbar sein.

Zusätzlich:

Icon,

Text,

klare Meldung

verbessern Verständlichkeit.

Erfolgreiche Eingabe muss nicht überall mit Grün bestätigt werden

Bei einem langen Formular kann eine dauernde Reihe grüner Häkchen unnötig visuelles Rauschen erzeugen.

Feedback sollte nützlich sein.

Nicht dekorativ inflationär.

Checkbox und Radio Button haben unterschiedliche Aufgaben

Checkbox:

☐ Newsletter erhalten

bedeutet:

Option ein- oder ausschalten.

Mehrere Checkboxen können gleichzeitig aktiviert sein.

Radio Buttons:

○ Standard
● Express
○ Abholung

werden verwendet, wenn genau eine Option einer Gruppe gewählt wird.

UI-Komponenten sollten ihrer Bedeutung entsprechen

Drei gegenseitig ausschließende Optionen als Checkboxen zu gestalten, kann Nutzer verwirren.

Die visuelle Komponente sollte die zugrunde liegende Logik widerspiegeln.

Dropdowns sind nützlich, aber nicht immer optimal

Ein Dropdown spart Platz.

Land
[ Österreich ▾ ]

Bei sehr wenigen Optionen können sichtbare Auswahlmöglichkeiten schneller sein.

Zum Beispiel:

○ Privat
○ Unternehmen

statt eines Dropdowns mit zwei Einträgen.

Viele Dropdownoptionen brauchen möglicherweise Suche

Bei:

200 Ländern

kann ein durchsuchbares Auswahlfeld komfortabler sein.

Aber damit entsteht wieder eine komplexere Komponente.

UI Design sollte Komplexität nicht unnötig erhöhen

Wenn drei normale Links reichen, braucht man nicht:

ein animiertes Mega-Dropdown mit Unterfiltern.

Das Interface sollte zur Aufgabe passen.

Was ist eine Card?

Cards beziehungsweise Karten gruppieren zusammengehörige Informationen in einem visuellen Container.

Zum Beispiel:

┌──────────────────────┐
│ Bild                 │
│                      │
│ Artikelüberschrift   │
│ kurze Beschreibung   │
│                      │
│ Mehr erfahren        │
└──────────────────────┘

Cards sind besonders auf:

Startseiten,

Übersichtsseiten,

Produktlisten,

Dashboards

verbreitet.

Cards sollten echte Gruppen bilden

Ein häufiger Fehler:

Jeder Text bekommt automatisch einen Rahmen.

Dann entstehen:

Box in Box in Box

Die Oberfläche wird schwer und kleinteilig.

Ein Container sollte einen nachvollziehbaren Gruppierungsgrund besitzen.

Nicht jede Card braucht Schatten

Schatten können Ebenen andeuten.

Aber wenn jede Box einen starken Schatten besitzt:

wirkt die Seite schnell unruhig.

Andere Möglichkeiten der Gruppierung sind:

Abstand,

Hintergrundfarbe,

Rahmen,

Ausrichtung.

Ganze Card klickbar oder nur Link?

Beides kann funktionieren.

Wenn die gesamte Karte klickbar ist, sollte dies visuell verständlich und technisch sauber umgesetzt sein.

Besonders wichtig ist:

keine widersprüchlichen verschachtelten Interaktionen.

Beispiel:

Card klickbar,

darin zusätzlich drei andere Buttons.

Das kann Bedienung komplizieren.

Cards sollten nicht unnötig identische Höhe erzwingen

In einem Raster kann ein einheitliches Erscheinungsbild schön sein.

Aber riesige Leerflächen nur deshalb, weil eine Überschrift kürzer ist als die daneben, können ebenfalls unnatürlich wirken.

Layoutregeln sollten flexibel bleiben.

Was sind Tabs?

Tabs wechseln zwischen zusammengehörigen Inhaltsbereichen.

Zum Beispiel:

[ Beschreibung ] [ Technik ] [ Bewertungen ]

Sie können Platz sparen und verwandte Inhalte gruppieren.

Tabs verstecken Informationen

Das kann gut sein.

Aber auch problematisch.

Wenn ein wichtiger Inhalt in einem Tab verborgen ist, bemerkt ein Nutzer ihn möglicherweise nicht.

Tabs sollten deshalb nicht verwendet werden, nur weil eine Seite sonst „zu lang“ wirkt.

Akkordeons funktionieren ähnlich

▸ Versand
▸ Rückgabe
▸ Zahlungsmethoden

Ein Klick öffnet den Inhalt.

Akkordeons eignen sich gut für optionale Details.

Sie sind weniger geeignet, wenn sämtliche Inhalte für fast jeden Nutzer wichtig sind.

UI Design entscheidet Sichtbarkeit

Eine wesentliche Frage lautet immer:

Was muss sichtbar sein?

und:

Was darf zunächst verborgen sein?

Das ist eng mit dem UX-Prinzip der Progressive Disclosure verbunden.

Dialogfenster und Modals

Ein Modal legt sich über den aktuellen Inhalt.

Zum Beispiel:

┌──────────────────────────┐
│ Datei löschen?           │
│                          │
│ Diese Aktion kann nicht  │
│ rückgängig gemacht werden│
│                          │
│ Abbrechen   Löschen      │
└──────────────────────────┘

Modals eignen sich für:

kurze fokussierte Entscheidungen.

Modals unterbrechen den Nutzer bewusst

Das kann bei einer kritischen Entscheidung sinnvoll sein.

Aber wenn jede kleine Aktion ein Modal öffnet:

wird die Bedienung anstrengend.

Ein Modal braucht einen klaren Ausweg

Zum Beispiel:

Abbrechen

oder:

Schließen-Schaltfläche.

Bei vielen Dialogen funktioniert auch:

Escape.

Der Nutzer sollte nicht im Interface gefangen sein.

Kritische Bestätigungen sollten konkret sein

Schwach:

Sind Sie sicher?

Sicher wobei?

Besser:

Möchtest du „Jahresbericht 2025.pdf“ endgültig löschen?

Damit ist klar, welche Konsequenz bestätigt wird.

Nicht jede Löschaktion braucht ein Modal

Wenn eine Aktion problemlos rückgängig gemacht werden kann, kann ein besseres Muster sein:

Datei gelöscht.

[ Rückgängig ]

Das reduziert Unterbrechungen.

Undo kann besser sein als ständige Bestätigung

Vergleiche:

Löschen
↓
Sind Sie sicher?
↓
Ja

mit:

Löschen
↓
gelöscht
↓
Rückgängig möglich

Bei risikoarmen, reversiblen Aktionen kann das zweite Modell flüssiger sein.

Tooltips

Tooltips zeigen kurze Zusatzinformationen.

Zum Beispiel:

ⓘ

beim Darüberfahren oder Fokussieren:

Diese Einstellung beeinflusst nur neue Projekte.

Tooltips eignen sich für ergänzende Informationen.

Wichtige Regeln gehören nicht ausschließlich in Tooltips

Wenn eine Information notwendig ist, um eine Aktion richtig zu verstehen:

sollte sie sichtbar sein.

Ein versteckter Tooltip ist dafür häufig zu schwach.

Benachrichtigungen und Alerts

Ein UI muss unterschiedliche Nachrichten darstellen können.

Zum Beispiel:

Information

Erfolg

Warnung

Fehler

Diese Zustände sollten unterscheidbar sein.

Farbe allein reicht auch hier nicht

Zum Beispiel:

✓ Erfolgreich gespeichert

⚠ Speicherplatz fast voll

✕ Datei konnte nicht hochgeladen werden

Symbol plus Text reduziert Abhängigkeit von Farbe.

Alerts sollten hilfreich formuliert sein

Schlecht:

Fehler.

Besser:

Die Datei ist größer als 20 MB. Bitte wähle eine kleinere Datei.

Die Meldung erklärt:

Problem

und:

nächsten Schritt.

Toast Notifications

Kurze Meldungen können vorübergehend am Rand erscheinen.

Zum Beispiel:

Gespeichert.

Sie eignen sich für Informationen, die keine weitere Aktion erfordern.

Kritische Fehler sollten nicht einfach verschwinden

Wenn eine wichtige Aktion fehlgeschlagen ist, sollte die Meldung lange genug sichtbar bleiben oder dauerhaft erscheinen, bis sie bearbeitet wurde.

Eine Toastmeldung, die nach zwei Sekunden verschwindet, kann dafür ungeeignet sein.

Navigation ist ebenfalls UI

Navigation besteht nicht nur aus Informationsarchitektur.

Sie muss auch visuell dargestellt werden.

Beispiel Desktop:

CASIOPEYA    Wissen    Magazin    Über uns    Suche

Mobile:

CASIOPEYA                         ☰

UI Design bestimmt:

Größe,

Abstände,

aktive Zustände,

Dropdowns,

Mobile-Menü.

Aktuelle Position sollte sichtbar sein

Wenn Nutzer sich unter:

Wissen → Design & Medien

befinden, kann der entsprechende Navigationspunkt hervorgehoben werden.

Das unterstützt Orientierung.

Aktiver Zustand muss nicht übertrieben sein

Zum Beispiel:

leichte Unterstreichung,

Farbänderung,

stärkeres Gewicht.

Die Navigation soll Orientierung geben, nicht den Seiteninhalt überstrahlen.

Links sollten als Links erkennbar sein

Vor allem im Fließtext.

Wenn Links exakt wie normaler Text aussehen, müssen Nutzer raten.

Mögliche Signale:

Farbe

Unterstreichung

Hover/Focus

Die konkrete Gestaltung hängt vom Designsystem ab.

Unterstreichung besitzt einen großen Vorteil

Sie funktioniert unabhängig von Farbwahrnehmung als zweites Signal.

Deshalb kann sie besonders bei Textlinks sinnvoll sein.

UI braucht visuelle Hierarchie

Ein Interface hat normalerweise verschiedene Ebenen.

Zum Beispiel:

Seitentitel
↓
Abschnittsüberschrift
↓
Komponente
↓
Hilfetext

Diese sollten visuell unterscheidbar sein.

Dafür nutzt UI Design:

Größe,

Gewicht,

Abstand,

Kontrast,

Farbe.

Typografie ist UI-Infrastruktur

Man kann beispielsweise definieren:

Heading XL

Heading L

Heading M

Body

Small

Caption

Diese Textstile werden im gesamten Interface wiederverwendet.

Das ist systematischer als:

jede Überschrift individuell in Pixeln zu formatieren.

Gleiches gilt für Farben

Nicht überall direkt:

#2467E8

eintragen.

Sondern vielleicht:

color-primary

color-danger

color-text-muted

color-background

Damit kommen wir zu Design Tokens.

Was sind Design Tokens?

Design Tokens sind benannte Designwerte.

Zum Beispiel:

color-primary

könnte intern bedeuten:

#245EA8

Oder:

spacing-medium

bedeutet:

16 px

Das Entscheidende ist:

Komponenten verwenden die Bedeutung, nicht überall den konkreten Rohwert.

Beispiel ohne Tokens

Button A:

background: #245EA8

Button B:

background: #245FA9

Button C:

background: #235DA8

Nach einiger Zeit existieren zehn fast identische Blautöne.

Mit Token

Alle nutzen:

color-primary

Wenn die Markenfarbe geändert wird:

color-primary
→ neuer Wert

Viele Komponenten ändern sich gemeinsam.

Typische Token-Kategorien

Zum Beispiel:

Colors

Typography

Spacing

Radius

Shadow

Border

Breakpoints

Ein System könnte etwa besitzen:

spacing-xs
spacing-s
spacing-m
spacing-l
spacing-xl

Tokens schaffen eine gemeinsame Sprache

Designer sagt:

spacing-m

Entwickler weiß:

welcher Wert gemeint ist.

Statt:

Mach da ungefähr ein bisschen mehr Abstand.

Das erleichtert Zusammenarbeit.

Semantische Tokens sind besonders hilfreich

Statt nur:

blue-500

kann man zusätzlich verwenden:

action-primary

Denn vielleicht ist die Primärfarbe später gar nicht mehr Blau.

Die Funktion bleibt.

Ein Designsystem geht über Tokens hinaus

Design Tokens definieren Werte.

Ein Designsystem definiert zusätzlich:

Komponenten,

Regeln,

Varianten,

Verwendung.

Design Tokens
↓
Komponenten
↓
Patterns
↓
Seiten

Beispiel Button-Komponente

Button
├── Primary
├── Secondary
├── Danger
└── Ghost

Dazu Zustände:

Default
Hover
Focus
Active
Disabled
Loading

Das ist bereits ein kleines UI-System.

Warum Designsysteme wertvoll sind

Ohne Designsystem:

Seite 1 besitzt einen Button mit 6 Pixel Radius.

Seite 2 mit 12 Pixel.

Seite 3 komplett rund.

Seite 4 ohne Radius.

Irgendwann wirkt die Website zusammengewürfelt.

Mit System:

Button
→ definierte Varianten

Die Entscheidung muss nicht jedes Mal neu getroffen werden.

Ein Designsystem reduziert auch Entwicklungsaufwand

Ein Entwickler benötigt einen Bestätigungsdialog.

Statt ihn neu zu bauen:

<ConfirmDialog>

wird eine vorhandene Komponente verwendet.

Das spart:

Entwicklungszeit,

Testaufwand,

Fehlerquellen.

Designsystem bedeutet nicht visuelle Eintönigkeit

Ein System kann viele Varianten besitzen.

Zum Beispiel:

Card
├── Artikel
├── Produkt
├── Person
└── Statistik

Alle teilen gemeinsame Grundregeln.

Trotzdem sehen sie nicht identisch aus.

Varianten brauchen einen Grund

Nicht:

Button Style 1
Button Style 2
Button Style 3
Button Style 4
Button Style 5

nur weil fünf Varianten schön aussehen.

Besser:

Primary
Secondary
Danger

Jede Variante besitzt eine Bedeutung.

Bedeutung ist wichtiger als Dekoration

Ein Designsystem sollte nicht hauptsächlich eine Sammlung ästhetischer Optionen sein.

Es sollte eine Sprache für Interfaces bilden.

Was sind Patterns?

Mehrere Komponenten können zu wiederkehrenden Interaktionsmustern zusammengesetzt werden.

Zum Beispiel:

Suchfeld
+
Filter
+
Ergebnisliste

oder:

Formular
+
Validierung
+
Submit
+
Bestätigung

Solche Patterns lösen wiederkehrende UX-Probleme.

Designsysteme dokumentieren idealerweise auch Verwendung

Zum Beispiel:

Primary Button verwenden für:

wichtigste Handlung einer Ansicht.

Nicht verwenden für:

jede Navigation oder unwichtige Nebenaktion.

Damit verhindert man, dass Komponenten formal korrekt, aber semantisch falsch eingesetzt werden.

Spacing ist ein wesentlicher UI-Baustein

Abstände zeigen Beziehungen.

Zum Beispiel:

Label
4–8 Einheiten Abstand
Eingabefeld

und deutlich mehr Abstand zum nächsten Formularblock.

Dadurch entstehen erkennbare Gruppen.

Ein Spacing-System verhindert Zufallswerte

Zum Beispiel:

4
8
16
24
32
48
64

Die exakte Skala kann anders aussehen.

Wichtig ist ein begrenztes Set wiederverwendbarer Abstände.

Zu viele unterschiedliche Abstände machen Interfaces unruhig

Wenn einmal:

17 Pixel

und dann:

21 Pixel

und später:

27 Pixel

verwendet werden, entsteht selten ein sichtbarer Vorteil.

Ein systematischer Rhythmus wirkt meist ruhiger.

Border Radius ist ebenfalls ein Token

Eine Marke kann beispielsweise eher:

kantig

oder:

weich

wirken.

Wenn:

Button,

Card,

Input,

Modal

völlig unterschiedliche Rundungen besitzen, wirkt das System uneinheitlich.

Trotzdem brauchen nicht alle Elemente exakt denselben Radius

Kleine Komponenten können beispielsweise anders reagieren als große Karten.

Das System sollte diese Unterschiede bewusst definieren.

Schatten erzeugen visuelle Ebenen

Ein Dialog über der Seite:

Vordergrund

kann durch Schatten stärker vom Hintergrund getrennt werden.

Aber Schatten sollten nicht inflationär eingesetzt werden.

Zu viele Schatten erzeugen eine „schwebende“ Oberfläche

Wenn:

Buttons,

Cards,

Inputs,

Navigation,

Bilder

alle starken Schatten besitzen, verliert die Tiefenwirkung ihre Bedeutung.

Rahmen können eine ruhigere Alternative sein

Eine dünne Kontur oder Hintergrunddifferenz kann Elemente genauso gut trennen.

Gestaltung hängt von der gewünschten visuellen Sprache ab.

UI und Farbe

Farben sollten im Interface nicht zufällig verteilt werden.

Typische Rollen:

Primary

Secondary

Background

Surface

Text

Muted

Success

Warning

Danger

Dadurch bekommt Farbe Bedeutung.

Statusfarben brauchen konsistente Semantik

Wenn Rot einmal:

Fehler

und ein anderes Mal:

normale Hauptaktion

bedeutet, kann das verwirren.

Ein Interface profitiert von wiederkehrenden Bedeutungen.

Kontrast bleibt entscheidend

Ein ästhetisch dezenter Button, dessen Text kaum lesbar ist, erfüllt seine Funktion nicht.

UI Design muss Lesbarkeit und Bedienbarkeit berücksichtigen.

Dark Mode verlangt eigene Tokens

Nicht einfach:

weiß
↔
schwarz

umkehren.

Ein sauberes System kann beispielsweise definieren:

surface-primary

und dafür im hellen sowie dunklen Modus unterschiedliche Werte hinterlegen.

Die Komponente selbst bleibt unverändert.

Tokens erleichtern Themenwechsel

UI-Komponente
↓
semantische Tokens
↓
Light Theme / Dark Theme

Das ist wesentlich robuster als Farben direkt in jeder Komponente zu speichern.

Typografie sollte ebenfalls tokenisiert werden

Zum Beispiel:

font-body

font-heading

text-xs

text-sm

text-base

text-lg

text-xl

oder stärker semantisch:

heading-page

heading-section

body-default

body-small

label

Semantische Typografie ist besonders wartbar

Wenn später alle H2 etwas kleiner werden sollen:

ein Token.

Nicht:

150 einzelne CSS-Regeln.

Responsive UI verändert Komponenten

Responsive Design betrifft nicht nur das Seitenlayout.

Auch einzelne Komponenten können sich verändern.

Desktop:

[ Filter ] [ Sortierung ] [ Suche ]

Mobil:

[ Filter & Sortierung ]
[ Suche                 ]

Die gleiche Funktion erhält eine andere Darstellung.

Eine Tabelle ist ein gutes Beispiel

Desktop:

Name | Datum | Status | Größe | Aktion

Auf Smartphone passt das möglicherweise nicht.

Optionen:

horizontal scrollen,

weniger Spalten,

Card-Darstellung,

Details aufklappen.

UI Design muss dafür ein alternatives Muster finden.

Responsive bedeutet nicht einfach kleiner

Das ist eine der wichtigsten Regeln.

Desktop-Komponente
↓
verkleinern

reicht häufig nicht.

Besser:

Desktop-Komponente
↓
Prioritäten prüfen
↓
mobile Variante

Das behandeln wir im nächsten Artikel über Responsive Webdesign ausführlicher.

Touch und Maus sind unterschiedliche Eingaben

Desktop:

präziser Mauszeiger.

Mobil:

Finger.

Darum brauchen Touchziele mehr Fläche.

Ein kleines Icon kann visuell unverändert bleiben, aber eine größere interaktive Fläche erhalten.

Tastatur ist eine dritte Eingabeform

Ein gutes UI berücksichtigt:

Maus

Touch

Tastatur

und je nach Anwendung weitere Hilfstechnologien.

Fokusreihenfolge sollte logisch sein

Beim Drücken von Tab sollte der Fokus ungefähr der visuellen beziehungsweise semantischen Reihenfolge folgen.

Nicht:

Navigation
↓
Footer
↓
Formular
↓
Logo

weil Elemente technisch in seltsamer Reihenfolge eingebaut wurden.

UI Design und Barrierefreiheit gehören zusammen

Beispiele:

sichtbare Fokuszustände,

ausreichender Kontrast,

verständlich beschriftete Formulare,

ausreichende Touchflächen,

Information nicht nur über Farbe,

klar erkennbare Links.

Diese Dinge verbessern häufig gleichzeitig die allgemeine Bedienbarkeit.

Ein Button braucht auch einen zugänglichen Namen

Ein Iconbutton zeigt nur:

🗑

Visuell versteht vielleicht jemand:

Papierkorb.

Ein Screenreader braucht trotzdem eine zugängliche Bezeichnung wie:

Datei löschen

UI ist deshalb nicht ausschließlich das Sichtbare.

Die semantische technische Umsetzung gehört mit dazu.

HTML-Elemente transportieren Bedeutung

Ein echter Button:

<button>Speichern</button>

ist technisch etwas anderes als:

<div>Speichern</div>

mit einem Klickhandler.

Der echte Button bringt bereits viele erwartete Interaktionseigenschaften mit.

Gutes UI Design sollte semantische Webtechnik unterstützen, nicht gegen sie arbeiten.

Links und Buttons haben unterschiedliche Bedeutungen

Ein Link:

führt zu einem anderen Ort

Ein Button:

führt eine Aktion aus

Diese Unterscheidung kann auch in der technischen Umsetzung sinnvoll bleiben.

Ein Link sollte nicht wie ein Button aussehen müssen

Manche wichtige Navigation kann bewusst als Button gestaltet werden.

Aber wenn jede Textnavigation wie ein großer Call-to-Action aussieht:

verschwindet die Hierarchie.

UI Design ist immer kontextabhängig

Ein Button in einem Blogartikel braucht andere Priorität als:

„Jetzt bezahlen“

im Checkout.

Ein Interface sollte nicht nur Komponenten besitzen.

Es braucht Regeln, wann welche Komponente verwendet wird.

Was ist eine Component Library?

Eine Component Library stellt wiederverwendbare Interface-Komponenten bereit.

Zum Beispiel:

Button

Input

Select

Checkbox

Card

Modal

Alert

Sie kann innerhalb eines Projekts selbst entwickelt werden oder auf bestehende Frameworks aufbauen.

Komponentenbibliothek und Designsystem sind nicht exakt dasselbe

Eine Component Library liefert:

Bausteine.

Ein Designsystem beinhaltet zusätzlich:

Designprinzipien,

Tokens,

Regeln,

Dokumentation,

Verwendungsmuster.

Vereinfacht:

Component Library
⊂
Designsystem

Ein Designsystem kann Markenwerte übersetzen

Zum Beispiel:

Marke soll wirken:

klar

ruhig

kompetent

zugänglich

Das kann sich im UI zeigen durch:

viel Weißraum,

überschaubare Farbpalette,

klare Typografie,

wenige dekorative Effekte,

verständliche Komponenten.

Markenwerte allein ergeben noch kein UI

„Modern“ ist keine ausreichende Komponentenspezifikation.

Man muss diese Idee übersetzen in konkrete Designentscheidungen.

UI Design arbeitet häufig mit Hierarchien

Zum Beispiel bei Buttons:

Primary
↓
Secondary
↓
Tertiary

Bei Text:

Page Title
↓
Section Title
↓
Body
↓
Caption

Bei Flächen:

Page Background
↓
Surface
↓
Elevated Surface

Diese Ebenen erleichtern Orientierung.

Zu viele Hierarchiestufen erschweren das System

Wenn es gibt:

Primary
Primary Strong
Primary Soft
Primary Alt
Primary Compact
Primary Emphasized

wird die Auswahl selbst wieder kompliziert.

Ein gutes Designsystem beginnt meist mit wenigen klaren Varianten.

Erst erweitern, wenn echte Anforderungen entstehen

Das gleiche Prinzip gilt wie bei Software:

kleine klare Basis
↓
echtes Problem
↓
gezielte Erweiterung

Nicht:

alle denkbaren Varianten vorsorglich bauen.

UI Design beginnt oft mit Wireframes

Im Webdesign-Artikel haben wir Wireframes als strukturelle Entwürfe kennengelernt.

Bei UI Design folgt danach eine detailliertere Ausgestaltung.

Wireframe
↓
Komponenten auswählen
↓
visuelle Styles
↓
Zustände
↓
High-Fidelity UI

High-Fidelity bedeutet näher am finalen Produkt

Nun werden beispielsweise definiert:

Farben,

Typografie,

Icons,

Spacing,

Komponenten,

Bilder.

Aber auch dann bleibt es häufig zunächst ein Design beziehungsweise Prototyp.

Prototypen zeigen Interaktion

Ein statischer Entwurf zeigt:

wie etwas aussieht.

Ein Prototyp kann zeigen:

was nach einem Klick passiert.

Zum Beispiel:

Button
↓
Dialog öffnet
↓
Bestätigung
↓
Statusmeldung

Das ist besonders für UI-Zustände wichtig.

Designer sollten nicht nur Happy Paths gestalten

Der perfekte Standardfall:

alle Daten vorhanden,

keine Fehler,

schnelle Verbindung.

Die reale Anwendung kennt aber:

Loading

Empty

Error

Offline

No Permission

Disabled

Long Content

Diese Zustände brauchen ebenfalls UI.

Der Empty State

Neue Anwendung.

Noch keine Projekte.

Schwach:

Keine Projekte.

Besser:

Du hast noch kein Projekt erstellt.

[ Erstes Projekt erstellen ]

Der Zustand erklärt sich selbst und bietet eine Aktion.

Der Error State

Schwach:

Fehler 503.

Besser:

Die Daten konnten gerade nicht geladen werden.

[ Erneut versuchen ]

Technische Details können zusätzlich für Administratoren verfügbar sein.

No Permission

Nicht einfach:

Fehler.

Sondern:

Du hast keine Berechtigung, diese Einstellungen zu ändern.

Wende dich an einen Administrator.

Auch das ist UI Design.

Long Content

Ein Card-Design mit:

Kurzer Titel

sieht gut aus.

Was passiert bei:

Ein außergewöhnlich langer Artikelname über lokale KI-Infrastruktur und automatisierte Verarbeitung

?

Komponenten müssen reale Inhalte aushalten.

Internationalisierung verschärft das

Ein deutscher Buttontext kann länger sein als ein englischer.

Save

gegen:

Änderungen speichern

Wenn eine Komponente nur exakt für „Save“ gebaut wurde, bricht sie möglicherweise in anderen Sprachen.

Flexible Komponenten sind besser als pixelgenaue Attrappen

Ein Button sollte sich an seine Beschriftung anpassen.

Eine Card an unterschiedliche Textlängen.

Ein Dialog an unterschiedliche Inhalte.

UI Design für echte Software braucht Flexibilität.

UI und Performance

Auch Oberflächenkomponenten können Performance beeinflussen.

Zum Beispiel:

riesige Iconbibliotheken,

komplexe Animationen,

große JavaScript-Komponenten,

unnötige Slider.

Ein guter UI-Entwurf sollte technisch sinnvoll umsetzbar sein.

Animationen im UI können nützlich sein

Zum Beispiel:

Menü öffnet sich.

Dialog erscheint.

Element wird verschoben.

Eine kurze Animation kann den Zusammenhang zwischen Zuständen erklären.

Motion sollte Ursache und Wirkung zeigen

Element hier
↓
Aktion
↓
Element bewegt sich dorthin

Der Nutzer versteht besser:

Was ist passiert?

Zu viel Motion kostet Aufmerksamkeit

Wenn jeder Button hüpft und jede Card einfliegt:

wird Bewegung zum Selbstzweck.

Besonders bei produktiven Anwendungen kann das störend sein.

Reduced Motion sollte berücksichtigt werden

Manche Nutzer möchten oder benötigen weniger Bewegung.

Oberflächen können Systemeinstellungen berücksichtigen und nicht essentielle Animationen reduzieren.

Mikrointeraktionen

Kleine Reaktionen können ein Interface hochwertig wirken lassen.

Zum Beispiel:

Checkbox animiert leicht.

Button reagiert auf Klick.

Upload zeigt Fortschritt.

Diese Details können Feedback verbessern.

Mikrointeraktion darf Funktion nicht verschleiern

Ein wunderschöner animierter Toggle, dessen Zustand kaum erkennbar ist, ist trotzdem schlecht.

Verständlichkeit kommt zuerst.

Toggle Switches

Ein Switch eignet sich gut für direkte binäre Zustände.

Zum Beispiel:

E-Mail-Benachrichtigungen   ON

Ein Klick verändert den Zustand unmittelbar.

Switch ist nicht immer Ersatz für Checkbox

Bei einer Checkbox kann die Änderung beispielsweise erst nach:

Speichern

wirksam werden.

Ein Switch suggeriert häufig:

sofortige Zustandsänderung

Die Interaktion sollte zur tatsächlichen Systemlogik passen.

Status sollte niemals nur durch Position schwer erkennbar sein

Ein Switch braucht klaren Kontrast zwischen:

An

und:

Aus.

Vielleicht zusätzlich Text.

Aktiv

Inaktiv

je nach Kontext.

Tabellen sind UI-Komponenten für strukturierte Daten

Eine gute Tabelle braucht:

klare Spaltenüberschriften,

Ausrichtung,

Lesbarkeit,

Sortierbarkeit,

eventuell Filter.

Nicht jede Datensammlung braucht allerdings eine Tabelle.

Zahlen profitieren von Ausrichtung

Zum Beispiel:

  12,50 €
 135,00 €
1.240,99 €

Rechtsbündige beziehungsweise sinnvoll ausgerichtete Zahlen lassen sich leichter vergleichen.

Aktionen in Tabellen sollten nicht dominieren

Wenn jede Zeile fünf riesige Buttons besitzt:

wird die Tabelle schnell unübersichtlich.

Manche seltenen Aktionen können in ein:

⋮ Mehr

-Menü wandern.

Wichtige Aktionen bleiben sichtbar.

Tabellen auf Mobilgeräten sind anspruchsvoll

Das ist ein perfekter Übergang zu Responsive Design.

Eine Tabelle, die auf Desktop ausgezeichnet funktioniert, kann auf einem 360-Pixel-Display unbrauchbar werden.

Deshalb muss UI auf unterschiedliche Geräte reagieren.

UI Design und Content Design

Auch Texte innerhalb der Oberfläche gehören zur Gestaltung.

Zum Beispiel:

Konto erfolgreich erstellt.

ist UI-Inhalt.

Genauso:

Passwort vergessen?

Datei auswählen

Keine Ergebnisse gefunden.

UI und Microcopy sollten gemeinsam entwickelt werden.

Ein schön gestalteter Button mit schlechtem Text bleibt schlecht

[ Fortfahren ]

kann weniger verständlich sein als:

[ Bestellung prüfen ]

Design besteht aus Form und Sprache.

UI sollte möglichst wenig Erklärung benötigen

Wenn unter jedem Button ein Absatz stehen muss, der erklärt, was er tut:

ist vielleicht die Komponente oder Beschriftung nicht klar genug.

Eine gute Oberfläche kommuniziert viel durch:

Position,

Beschriftung,

Konvention,

Hierarchie.

Trotzdem darf Hilfe verfügbar sein

Komplexe Fachsoftware kann erklärungsbedürftige Optionen besitzen.

Dann sind:

Hilfetexte,

Dokumentation,

kontextuelle Hinweise

sinnvoll.

UI muss nicht sämtliche Fachkomplexität unsichtbar machen.

Progressive Disclosure hilft bei Expertenfunktionen

Standardansicht:

Modell
Temperatur
Maximale Länge

darunter:

[ Erweiterte Einstellungen ]

Dort vielleicht:

weitere technische Parameter.

Das reduziert visuelle Last für normale Nutzer.

Anfänger und Experten können unterschiedliche Bedürfnisse haben

Eine gute Oberfläche kann beide bedienen.

Beispiel:

Schnellmodus

und:

Erweiterte Optionen

Aber nur, wenn beide Modi sinnvoll strukturiert sind.

UI für KI-Systeme hat besondere Anforderungen

Ein KI-System arbeitet häufig probabilistisch.

Das bedeutet:

Ein Button wie:

[ Artikel generieren ]

liefert nicht immer identische Ergebnisse.

Die Oberfläche sollte diesen Charakter berücksichtigen.

KI-Ausgaben brauchen Zustände

Zum Beispiel:

queued

generating

completed

needs_review

failed

Diese technischen Zustände müssen in verständliche UI übersetzt werden.

Beispiel

Backend:

needs_review

UI:

Prüfung erforderlich

mit Erklärung:

Die erzeugte Antwort konnte nicht vollständig validiert werden.

KI braucht Versionierung im Interface

Wenn ein Nutzer einen Text überarbeiten lässt:

Original.

Version 2.

Version 3.

Eine Oberfläche sollte nicht einfach den bisherigen Text überschreiben.

Besser:

Version 1
Version 2
Version 3

oder zumindest:

Rückgängig

KI braucht verständliche Kontrolle

Zum Beispiel Bildgenerierung:

Stil: Editorial
Format: 16:9
Varianten: 4

Der Nutzer muss nicht alle technischen Modellparameter sehen.

Aber relevante fachliche Einstellungen sollten nachvollziehbar sein.

Technische Komplexität kann hinter Presets verschwinden

Statt:

CFG 4.5
Sampler XYZ
Steps 28
LoRA Weight 0.73

könnte ein normaler Nutzer wählen:

Stil: Redaktionell

Die technischen Parameter liegen im Preset.

Experten können eventuell zusätzliche Einstellungen öffnen.

Gute UI abstrahiert, ohne Kontrolle zu verlieren

Das ist ein starkes Prinzip.

einfache Oberfläche
↓
fachlich relevante Entscheidungen
↓
technische Komplexität im Hintergrund

Nicht:

alle technischen Parameter
↓
jeder Nutzer muss alles verstehen

Ein n8n-Workflow braucht ebenfalls UI, sobald Menschen eingreifen

Beispiel:

Automatische Contentproduktion.

Statusübersicht könnte zeigen:

Artikel                 Status
────────────────────────────────
Caching                 Freigegeben
DNS                     Prüfung nötig
Webhooks                Wird erstellt
API                     Fehler

Die technische Workflowlogik läuft im Hintergrund.

UI macht sie für Menschen verständlich.

Farben können Status unterstützen

Zum Beispiel:

Freigegeben

grün.

Prüfung nötig

orange.

Fehler

rot.

Aber zusätzlich sollte der Status ausgeschrieben sein.

Ein Dashboard ist eine besondere UI

Es zeigt häufig viele Informationen gleichzeitig.

Die Herausforderung lautet:

Was muss der Nutzer sofort sehen?

Nicht:

Wie viele Diagramme passen auf einen Bildschirm?

Gute Dashboards priorisieren Entscheidungen

Zum Beispiel:

3 Fehler
7 Aufgaben benötigen Prüfung
142 Jobs erfolgreich

Der Nutzer erkennt zuerst:

Wo muss ich handeln?

Vanity Metrics sollten nicht dominieren

Ein riesiges Diagramm:

4.582.192 verarbeitete Tokens

ist vielleicht beeindruckend.

Aber wenn der Administrator eigentlich wissen muss:

2 Workflows sind ausgefallen

ist die Priorität falsch.

UI Design folgt dem Nutzerziel

Wie bei UX beginnt auch UI nicht mit:

Welche Card sieht schön aus?

Sondern:

Welche Information beziehungsweise Handlung muss hier verständlich werden?

UI kann getestet werden

Fragen:

Erkennen Nutzer den Primary Button?

Verstehen sie Icons?

Finden sie Filter?

Erkennen sie Fehler?

Wissen sie, ob etwas gespeichert wurde?

Diese Dinge lassen sich in Usability-Tests beobachten.

Preference Test und Usability Test sind unterschiedlich

Preference Test:

Welche Variante gefällt dir besser?

Usability Test:

Mit welcher Variante kannst du die Aufgabe besser erledigen?

Beides kann nützlich sein.

Aber es beantwortet unterschiedliche Fragen.

Hübscher ist nicht automatisch besser bedienbar

Eine minimalistische Oberfläche kann bei einer Umfrage bevorzugt werden.

Wenn wichtige Funktionen dadurch schwerer auffindbar sind, kann sie praktisch schlechter funktionieren.

UI Design braucht reale Inhalte

Ein Card-Design nur mit:

Titel
Lorem ipsum

ist gefährlich.

Echte Inhalte zeigen:

lange Überschriften,

fehlende Bilder,

unterschiedliche Metadaten.

Komponenten müssen diese Realität bewältigen.

UI braucht Grenzfälle

Zum Beispiel:

Was passiert bei:

0 Ergebnisse

1 Ergebnis

10.000 Ergebnisse

?

Ein gutes Design sollte nicht nur für den hübschen Screenshot funktionieren.

Design und Entwicklung sollten zusammenarbeiten

Ein Designer entwirft ein extrem komplexes Auswahlmenü.

Der Entwickler erkennt:

Das Verhalten ist technisch aufwendig und accessibility-kritisch.

Früher Austausch kann eine bessere Lösung erzeugen.

UI Design ist kein isolierter Übergabeprozess.

Design Handoff

Beim Übergang zur Entwicklung sollten nicht nur Screenshots übergeben werden.

Sinnvoll sind Informationen über:

Komponenten

Zustände

Abstände

Tokens

Responsive Verhalten

Interaktionen

Ein statischer Screenshot beantwortet viele dieser Fragen nicht.

Designsystem erleichtert Handoff

Wenn beide Seiten wissen:

Button / Primary / Large

ist wesentlich klarer, was umgesetzt werden soll.

Das Designsystem wird zur gemeinsamen Sprache.

WordPress und UI Design

Auch WordPress-Seiten profitieren von Komponentenlogik.

Zum Beispiel:

Button

Hinweisbox

Card

Artikelteaser

Call-to-Action

Accordion

Diese sollten möglichst zentral im Theme beziehungsweise Blocksystem definiert werden.

Einzelne Artikel sollten Komponenten nicht frei erfinden

Sonst entsteht:

Artikel A:

blaue Hinweisbox.

Artikel B:

gelbe.

Artikel C:

grüne mit anderem Radius.

Nach einigen Monaten besitzt jede Seite ihre eigene UI.

Block Styles können Regeln festlegen

Zum Beispiel:

Hinweis / Info

Hinweis / Tipp

Hinweis / Warnung

Der Redakteur wählt die Bedeutung.

Das Designsystem entscheidet über das Aussehen.

Das ist besser als freie Farbauswahl

Nicht:

Welche Farbe möchte ich heute?

Sondern:

Welche Funktion besitzt diese Box?

Das ist semantisches UI Design.

UI und Themes

Ein gutes WordPress-Theme liefert idealerweise:

globale Typografie,

Farbpalette,

Buttonstyles,

Spacing,

Templates.

Wer jede Seite anschließend individuell überschreibt, verliert viele Vorteile des Systems.

Custom CSS sollte nicht das normale Designwerkzeug sein

Natürlich wird CSS benötigt.

Aber wenn für jeden neuen Artikel:

Sonder-CSS

geschrieben werden muss, ist das Designsystem möglicherweise unvollständig.

Komponenten sollten zentral verbessert werden können

Angenommen:

Buttons sind auf Mobilgeräten zu klein.

Mit zentraler Komponente:

Button
↓
einmal ändern
↓
gesamte Website verbessert

Ohne System:

hundert Seiten einzeln bearbeiten.

UI Design ist deshalb auch Wartbarkeitsdesign

Eine Oberfläche muss nicht nur heute gut aussehen.

Sie sollte:

erweiterbar,

konsistent,

pflegbar

bleiben.

Was du dir über UI Design merken solltest

UI Design gestaltet die sicht- und bedienbare Oberfläche eines digitalen Produkts.

Das Grundmodell lautet:

Nutzer
↓
Interface
↓
System

Zum User Interface gehören unter anderem:

Buttons

Formulare

Navigation

Cards

Tabs

Dialoge

Icons

Alerts

Tabellen

Der wichtigste Unterschied zu UX Design lautet:

UX
→ gesamtes Nutzungserlebnis

UI
→ konkrete Benutzeroberfläche

Beide gehören zusammen.

UX kann beispielsweise entscheiden:

Der Nutzer muss seinen Einkauf möglichst einfach abschließen können.

UI übersetzt dies in:

Formular

Buttons

Schrittnavigation

Fehlermeldungen

Bestätigungen

Ein gutes UI besitzt eine klare visuelle Hierarchie.

Nicht jede Aktion ist gleich wichtig.

Deshalb gibt es beispielsweise:

Primary Action
↓
Secondary Action
↓
Tertiary Action

Kritische Aktionen wie:

Konto löschen

dürfen sich deutlich von normalen Aktionen unterscheiden.

Buttons und andere interaktive Komponenten besitzen außerdem mehrere Zustände:

Default

Hover

Focus

Active

Disabled

Loading

Diese Zustände sollten bewusst gestaltet werden.

Besonders Focus ist für Tastaturbedienung wichtig.

Ein Interface sollte niemals ausschließlich für die Maus entworfen werden.

Formulare brauchen klare Strukturen:

Label
↓
Input
↓
Hilfetext
↓
Fehlermeldung

Placeholder sollten ein dauerhaft sichtbares Label nicht automatisch ersetzen.

Fehler sollten möglichst direkt dort erklärt werden, wo sie auftreten.

Auch hier gilt:

roter Rahmen
≠
ausreichende Erklärung

Ein hilfreicher Text ist meist wertvoller.

Komponenten wie:

Cards,

Tabs,

Akkordeons,

Modals

sollten nur verwendet werden, wenn sie tatsächlich eine Informations- oder Interaktionsaufgabe lösen.

Nicht jedes Element braucht:

Rahmen,

Schatten,

Animation.

Gutes UI reduziert visuelles Rauschen.

Ein besonders wichtiger Baustein ist das Designsystem.

Design Tokens
↓
Komponenten
↓
Patterns
↓
Seiten

Design Tokens können beispielsweise definieren:

Farben

Abstände

Typografie

Radien

Schatten

Statt einen konkreten Wert überall einzeln zu verwenden:

#245EA8

kann das System mit einer semantischen Bezeichnung arbeiten:

color-primary

Wird die Markenfarbe geändert, kann der Wert zentral angepasst werden.

Dasselbe gilt für Abstände:

spacing-s
spacing-m
spacing-l

und Textstile:

heading-page
heading-section
body-default
label

Ein Designsystem reduziert damit sowohl visuelle Inkonsistenz als auch Entwicklungsaufwand.

Komponenten sollten allerdings nicht nur dekorative Varianten besitzen.

Besser:

Primary Button
→ wichtigste Aktion

Secondary Button
→ alternative Aktion

Danger Button
→ kritische Aktion

Damit besitzt jede Variante eine klare Bedeutung.

UI Design muss außerdem reale Zustände berücksichtigen.

Nicht nur:

alles funktioniert

sondern auch:

Loading

Empty

Error

Disabled

No Permission

Offline

Ein gutes Interface erklärt auch diese Situationen.

Beispiel Empty State:

Du hast noch keine Projekte.

[ Erstes Projekt erstellen ]

ist hilfreicher als:

Keine Daten.

Bei KI-Anwendungen werden diese Zustände noch wichtiger.

Ein KI-Workflow kann beispielsweise sein:

Warteschlange
↓
Generierung
↓
Prüfung nötig
↓
Freigegeben

Die UI muss technische Zustände in verständliche Sprache übersetzen.

needs_review

wird beispielsweise:

Prüfung erforderlich

Das UI sollte den Nutzer nicht mit internen technischen Codes überfordern.

Gleichzeitig kann es Experten erlauben, bei Bedarf mehr Details einzublenden.

Das führt zu einem weiteren starken Prinzip:

einfache Standardoberfläche
+
optionale Expertenebene

Statt alle technischen Parameter permanent sichtbar zu machen.

Bei lokalen KI-Systemen könnte ein normaler Nutzer beispielsweise wählen:

Stil: Editorial

Format: 16:9

Varianten: 4

während die technische Schicht intern Einstellungen für:

Modell,

LoRA,

Sampling,

Auflösung

verwaltet.

Auch n8n-Workflows profitieren davon.

Statt rohe technische Zustände anzuzeigen, kann ein Dashboard fachliche Status verwenden:

Wird erstellt

Prüfung nötig

Freigegeben

Fehler

Das macht Automatisierung für Menschen bedienbar.

UI Design besitzt damit drei zentrale Aufgaben:

sichtbar machen

priorisieren

Interaktion verständlich machen

Eine gute Benutzeroberfläche beantwortet ständig kleine Fragen:

Was kann ich hier tun?

Was ist wichtig?

Was passiert beim Klick?

Hat meine Aktion funktioniert?

Was muss ich bei einem Fehler tun?

Wenn das Interface diese Fragen ohne lange Erklärung beantwortet, funktioniert es.

Der wichtigste Grundsatz lautet deshalb:

Ein gutes UI macht die Logik eines Systems sichtbar, ohne den Nutzer mit seiner technischen Komplexität zu belasten.