UI-States designen – Hover, Active, Disabled sauber lösen

Eine Oberfläche kann noch so sauber aussehen: Wenn Buttons, Links und Felder sich im Moment der Interaktion „komisch“ verhalten, sinkt das Vertrauen sofort. Ursache ist oft nicht das Layout, sondern fehlende oder uneinheitliche Zustände. Gemeint sind Varianten wie Hover (Maus darüber), Active (gedrückt), Focus (per Tastatur ausgewählt) oder Disabled (deaktiviert). Gute Zustände sorgen für klare Rückmeldung, barriereärmere Bedienung und weniger Diskussionen zwischen Design und Entwicklung.

Welche UI-Zustände wirklich nötig sind

Viele Designs zeigen nur den Normalzustand. In der Praxis braucht fast jedes interaktive Element mehrere Varianten. Wichtig ist dabei nicht „möglichst viele Effekte“, sondern eine nachvollziehbare Logik: Nutzer sollen erkennen, was klickbar ist, was gerade passiert und was als Nächstes möglich ist.

Basis-Set für Buttons, Links und Inputs

Als Mindestumfang hat sich für die meisten Projekte ein Set bewährt:

• Default (Normalzustand): so sieht das Element ohne Interaktion aus.
• Hover: Rückmeldung bei Maus/Trackpad. Sollte dezent sein, nicht wie ein neues Element wirken.
• Active (Pressed): Moment des Klicks/Taps. Vermittelt „der Klick ist angekommen“.
• Focus (Tastatur-Fokus): sichtbar, wenn per Tab navigiert wird. Das ist zentral für Tastaturbedienung und Accessibility.
• Disabled: klar erkennbar deaktiviert, ohne wie „kaputt“ auszusehen.
• Optional: Loading (wartend), Error/Success (Validierung), Selected (Auswahlzustand, z. B. Toggle).

Je nach Komponente kommen zusätzliche Zustände dazu: Checkboxen kennen z. B. „checked“, Tabs kennen „selected“, ein Menüpunkt kennt „current“ (aktuelle Seite).

Gestaltungsprinzipien: Was sich zwischen den Zuständen ändern darf

Ein Zustand sollte Rückmeldung geben, aber nicht die Identität der Komponente verändern. Besonders wichtig: Zustände dürfen das Layout nicht „springen“ lassen. Wenn sich Breite oder Höhe durch eine Outline oder andere Border-Stärken ändern, wirkt das UI instabil.

Kontrast, Helligkeit, Umriss: drei sichere Hebel

Für viele Designs reichen drei einfache Mechaniken:

• Farb-/Helligkeits-Shift: z. B. leicht dunkler beim Hover, noch etwas stärker bei Active. Das funktioniert für Flächen, Textlinks und Icons.
• Outline/Ring statt Border-Wechsel: Für Focus ist eine Outline (Umrandung) oft besser als eine Border, weil sie das Layout nicht verschiebt.
• Shadow subtil anpassen: z. B. beim Active den Schatten reduzieren, damit das Element „gedrückt“ wirkt.

Wichtig ist Konsistenz: Wenn Hover bei einem Button über Helligkeit gelöst wird, sollte das bei ähnlichen Buttons nicht plötzlich über eine Unterstreichung passieren. Sonst müssen Nutzer bei jeder Komponente neu lernen.

Was besser unverändert bleibt (um Chaos zu vermeiden)

• Größe, Padding und Border-Radius: nicht zwischen Zuständen wechseln.
• Typografie: keine Fontwechsel, keine Sprünge in der Schriftstärke nur für Hover.
• Icon-Positionen: keine Verschiebungen, die wie ein „Wackeln“ wirken.

Wenn sich etwas deutlich ändern soll (z. B. von „Outline-Button“ zu „Filled“), ist das eher eine andere Variante der Komponente als ein Zustand.

Focus sichtbar machen, ohne das Design zu „stören“

Focus ist der Zustand, der am häufigsten vergessen wird, obwohl er für Tastatur-Nutzer entscheidend ist. „Unsichtbarer Focus“ führt dazu, dass man nicht mehr weiß, wo man gerade ist. Der Klassiker: Designer entfernen den Standard-Focus im Browser, ersetzen ihn aber nicht.

So wirkt Focus modern und klar

Ein Focus-Stil muss nicht laut sein. Er muss nur eindeutig sein. Bewährt haben sich:

• Ein farbiger Ring um das Element (Outline), der sich deutlich vom Hintergrund abhebt.
• Ein zusätzlicher Außenabstand (visuell, nicht als echtes Layout-Padding), damit der Ring nicht an Nachbarelementen „klebt“.
• Bei dunklen Flächen ggf. zweifarbiger Ring (innen hell, außen dunkel), damit er auf vielen Hintergründen funktioniert.

Eine gute Orientierung bietet auch ein klar strukturiertes Layout und Priorisierung. Dazu passt der Beitrag Design-Hierarchie im Webdesign – Blickführung ohne Überladung, weil Focus besonders dann hilfreich ist, wenn visuelle Ebenen sauber getrennt sind.

Disabled richtig einsetzen: weniger Frust, mehr Klarheit

Disabled ist mehr als „grau machen“. Ein deaktiviertes Element sollte eindeutig nicht interaktiv sein, gleichzeitig aber noch erkennbar bleiben. Sonst suchen Nutzer lange nach der nächsten Möglichkeit.

Deaktiviert vs. nicht verfügbar: die Botschaft muss passen

Es hilft, zwei Situationen zu unterscheiden:

• Disabled, weil eine Bedingung fehlt (z. B. Formular unvollständig). Hier sollte idealerweise klar werden, was fehlt.
• Nicht verfügbar (z. B. Feature nicht erlaubt). Hier ist oft eine Erklärung besser als ein stilles Deaktivieren.

Gerade bei Formularen ist das Zusammenspiel aus Zuständen und Rückmeldungen entscheidend. Praktische Hinweise liefert UI-Formulare gestalten – Felder, Fehlertexte und Flow, weil dort sichtbar wird, wie Disabled, Error und Success in einem echten Flow zusammenwirken.

Gestaltungsregeln, die in fast jedem System funktionieren

• Kontrast reduzieren, aber nicht bis zur Unlesbarkeit. Text muss weiterhin als Label erkennbar sein.
• Pointer-Feedback vermeiden: kein Hover-Effekt bei Disabled.
• Icons ebenfalls abschwächen, aber nicht komplett verschwinden lassen (sonst wirkt es wie ein Bug).

States in Figma so anlegen, dass Teams sie nutzen

Damit Zustände im Projekt wirklich ankommen, müssen sie im Design-File leicht auffindbar und wiederverwendbar sein. Wenn States „irgendwo“ liegen, werden sie im Sprint vergessen.

Varianten statt lose Kopien

In Figma lassen sich Zustände am saubersten als Varianten einer Komponente abbilden. So kann ein Button z. B. die Eigenschaft „State“ mit Werten wie Default/Hover/Active/Focus/Disabled haben. Vorteil: Änderungen am Grundlayout propagieren automatisch in alle Zustände.

Wenn Varianten grundsätzlich schon im Team genutzt werden, lohnt sich ergänzend der Artikel Design-Varianten in Figma – sauber testen ohne Chaos, weil dort typische Strukturfehler (zu viele Properties, uneinheitliche Benennungen) gut greifbar werden.

Benennung und Dokumentation, die im Alltag hilft

Eine einfache, robuste Benennung reduziert Rückfragen:

• Komponente: „Button / Primary“
• Property: „State“
• Werte: Default, Hover, Active, Focus, Disabled, Loading

Kurze Hinweise in einer Designspezifikation (z. B. „Focus immer sichtbar, nicht entfernen“) reichen oft. Für Übergaben hilft zusätzlich Design-Übergaben in Figma – Specs, Assets, Kommentare sauber, damit Entwickler die Zustände nicht interpretieren müssen.

Mini-Fallbeispiel: Warum sich Buttons „billig“ anfühlen

Ein typisches Problem aus Projekten: Ein Primary-Button hat im Default einen Schatten. Im Hover wird nur die Farbe leicht dunkler. Beim Klick (Active) passiert gar nichts. Ergebnis: Der Button wirkt „träge“, als wäre der Klick nicht registriert. Nutzer klicken häufiger zweimal.

Eine einfache Korrektur bringt spürbar mehr Qualität:

• Active reduziert den Schatten deutlich und verschiebt die Fläche minimal optisch nach unten (ohne Layoutsprung).
• Hover bleibt dezent (kleiner Helligkeits-Shift), damit Active sich stärker abhebt.
• Focus bekommt einen klaren Ring, der bei Tastaturbedienung sofort Orientierung gibt.

Das Ergebnis ist kein „Fancy Effekt“, sondern eine eindeutige Rückmeldung in jedem Moment.

Prüfroutine für States vor dem Handoff

Eine kurze Kontrolle spart später viele Bugs. Diese Schritte lassen sich in 10–15 Minuten pro Screen durchführen.

• Alle interaktiven Elemente markieren (Buttons, Links, Inputs, Toggles, Tabs, Menüs).
• Pro Element prüfen: Default, Hover, Active, Focus, Disabled vorhanden?
• Layout-Stabilität checken: Keine Größen-/Padding-Sprünge zwischen Zuständen.
• Kontrast-Logik prüfen: Hover < Active (stärker), Disabled klar erkennbar.
• Tastatur-Flow „durchtabben“ (als Gedankenübung oder im Prototyp): Focus muss immer sichtbar sein.
• Im Team klären, ob „Loading“ nötig ist (z. B. bei Submit-Aktionen).

Übersicht: Zustände und typische Designmittel

Typische Fragen aus Projekten

• Braucht jede Komponente wirklich Hover? Auf Touch-Geräten gibt es keinen klassischen Hover. Trotzdem ist er für Desktop sinnvoll. Wichtig: Hover nie als einzige Information nutzen.
• Kann Disabled durch „Ausgrauen“ gelöst werden? Ja, aber mit Maß. Wenn Labels unlesbar werden, ist die Komponente nicht mehr verständlich. Besser: klare Deaktivierung plus Hinweis, wenn Nutzer sonst nicht weiterkommen.
• Was ist wichtiger: Active oder Focus? Beide erfüllen unterschiedliche Aufgaben. Active bestätigt den Klick, Focus zeigt Orientierung. In vielen Projekten wird Focus unterschätzt, obwohl er zentral für Bedienbarkeit ist.