Buttons richtig gestalten: Hierarchie, Beschriftung, Zustände und Größe

Stell dir die Startseite eines kleinen Yogastudios vor. Ganz oben ein schönes Foto, darunter drei Buttons nebeneinander: „Mehr erfahren“, „Kursplan“ und „Jetzt starten“. Alle drei sind gleich groß, alle drei leuchten im selben Türkis. Weiter unten folgen noch „Hier klicken“, „Probestunde“ und ein kleines graues „Absenden“ unter dem Newsletter-Feld.

Wer die Seite zum ersten Mal besucht, will eigentlich nur eins: eine Probestunde buchen. Aber welcher Button führt dorthin? „Jetzt starten“ klingt danach, könnte aber auch zu einem Onlinekurs führen. „Probestunde“ steht weit unten und sieht aus wie alle anderen. Die Seite hat sechs Buttons und trotzdem keinen, der eindeutig sagt: Hier geht es weiter.

Genau darum geht es in diesem Artikel. Buttons gehören zu den kleinsten Elementen eines Interfaces, aber an ihnen entscheidet sich, ob Menschen das tun können, wofür sie gekommen sind. Du erfährst, wie du Buttons nach Wichtigkeit ordnest, wie du sie beschriftest, welche Zustände sie brauchen und wie groß sie sein sollten. Vorwissen brauchst du dafür nicht.

Was ist ein Button, und was ist ein Call to Action?

Ein Button (auf Deutsch auch Schaltfläche) ist ein Element, mit dem du eine Aktion auslöst: etwas speichern, abschicken, in den Warenkorb legen, einen Dialog schließen. Er unterscheidet sich damit von einem Link, der dich an eine andere Stelle bringt, etwa auf eine neue Seite. Diese Unterscheidung klingt technisch, hat aber praktische Folgen. Dazu später mehr.

Ein Call to Action, kurz CTA, ist ein Begriff aus dem Marketing und bedeutet wörtlich „Handlungsaufforderung“. Gemeint ist das Element, das Menschen zum wichtigsten nächsten Schritt einlädt: „Probestunde buchen“, „Kostenlos testen“, „Angebot anfordern“. Meist ist ein CTA ein Button, manchmal auch ein auffälliger Link oder ein ganzer Kasten mit Überschrift, Text und Button.

Jeder CTA ist also eine Aufforderung, aber nicht jeder Button ist ein CTA. „Abbrechen“, „Filter zurücksetzen“ oder „Schließen“ sind Buttons, die gebraucht werden, aber niemanden zu etwas auffordern sollen. Wenn ein CTA dazu führt, dass jemand das tut, was die Website erreichen will, also kauft, bucht oder sich anmeldet, spricht man von einer Conversion.

Woran Menschen einen Button erkennen

Bevor jemand auf einen Button klickt, muss er überhaupt als Button erkannt werden. Klingt selbstverständlich, ist es aber nicht. Im Design spricht man hier von Signifiern: sichtbaren Hinweisen, die zeigen, dass und wie man mit einem Element interagieren kann. Bei Buttons sind das typischerweise eine Fläche mit Hintergrundfarbe oder ein Rahmen, abgerundete Ecken, ausreichend Innenabstand um den Text und eine Position, an der man einen Button erwartet.

Wie wichtig diese Hinweise sind, hat die Nielsen Norman Group (NN/g) 2017 in einer Eyetracking-Studie mit 71 Testpersonen gezeigt. Eyetracking bedeutet, dass eine Kamera aufzeichnet, wohin Menschen auf dem Bildschirm schauen. Die Testpersonen sollten auf Websites ein bestimmtes klickbares Element finden. Auf Varianten mit schwachen Signifiern, etwa flachem Text ohne Fläche oder Unterstreichung, brauchten sie im Schnitt 22 % länger und schauten 25 % mehr Stellen an als auf Varianten mit deutlichen Hinweisen. Die Blicke wanderten suchend über die Seite.

Für die Praxis heißt das: Ein Button sollte aussehen wie ein Button. Ein farbiges Wort ohne Fläche, das sich nur beim Darüberfahren mit der Maus verändert, wird leicht übersehen. Auf dem Smartphone gibt es dieses Darüberfahren außerdem gar nicht. Bleib bei bewährten Formen, denn Menschen verbringen die meiste Zeit auf anderen Websites und bringen ihre Erwartungen von dort mit. Dieses Prinzip heißt Jakob’s Law.

Hierarchie: Nicht jeder Button ist gleich wichtig

Zurück zum Yogastudio. Das Grundproblem der Startseite ist nicht ein einzelner schlecht gestalteter Button. Es ist das Fehlen einer Rangfolge. Wenn alle Buttons gleich laut sind, ist keiner laut. Menschen müssen jeden einzelnen lesen und abwägen, bevor sie sich entscheiden.

Apple formuliert das in seinen Gestaltungsrichtlinien, den Human Interface Guidelines, ziemlich direkt: Pro Ansicht sollte es nur einen oder zwei auffällig gestaltete Buttons geben. Zu viele davon erhöhen die geistige Belastung, weil Menschen mehr Zeit damit verbringen, die Optionen abzuwägen, bevor sie wählen.

Die drei Ebenen

Die meisten Interfaces kommen mit drei Ebenen aus. Die Namen variieren je nach Team und Design System, das Prinzip ist überall gleich:

• Primärer Button: die wichtigste Aktion in diesem Bereich. Gefüllte Fläche in der Akzentfarbe, die stärkste visuelle Wirkung. Pro Bereich gibt es idealerweise genau einen.
• Sekundärer Button: wichtige, aber nachrangige Aktionen. Häufig nur mit Rahmen (Outline) oder mit einer blasseren Füllung. Er ist gut erkennbar, drängt sich aber nicht vor.
• Tertiärer Button: die leiseste Ebene, oft nur Text ohne Fläche (Text-Button). Gedacht für Nebenaktionen wie „Abbrechen“ oder „Später erinnern“.

Googles Material Design, ein weit verbreitetes Design System, unterscheidet sogar fünf Stufen: vom gefüllten Button („filled“) für wichtige, abschließende Aktionen wie „Speichern“ oder „Bestätigen“ über getönte und erhöhte Varianten und den Outline-Button für Aktionen mit mittlerer Wichtigkeit bis zum Text-Button für die Aktionen mit der geringsten Priorität. Für den Einstieg reichen drei Ebenen völlig.

Die Hierarchie über Stil zeigen, nicht über Größe

Ein naheliegender Gedanke ist, den wichtigsten Button einfach größer zu machen. Apple rät davon ab: Stehen mehrere Optionen nebeneinander, sollten die Buttons gleich groß sein und sich nur im Stil unterscheiden. Unterschiedlich große Buttons direkt nebeneinander wirken schnell unruhig und uneinheitlich. Gleiche Größe signalisiert dagegen: Das hier sind zusammengehörige Optionen, und eine davon ist die empfohlene.

Für das Yogastudio sieht das so aus:

Vorher: „Mehr erfahren“, „Kursplan“ und „Jetzt starten“, alle drei gleich groß und gleich türkis gefüllt.

Nachher: „Probestunde buchen“ als einziger gefüllter Button. Daneben „Kursplan ansehen“ als Outline-Button. „Mehr erfahren“ entfällt, denn der Text unter dem Foto erklärt das Studio bereits.

Nach dieser Änderung muss niemand mehr überlegen. Der Blick fällt auf den türkisen Button, und der sagt genau, was passiert.

Hierarchie gilt pro Bereich, nicht pro Seite

Eine lange Seite darf mehrere primäre Buttons haben, solange sie in verschiedenen Bereichen stehen. Das Yogastudio kann „Probestunde buchen“ oben im Kopfbereich und noch einmal am Seitenende anbieten. Wichtig ist, dass innerhalb eines Bildschirmausschnitts klar bleibt, welche Aktion die wichtigste ist. Und dass derselbe CTA überall gleich heißt. Wenn er oben „Probestunde buchen“ und unten „Jetzt kostenlos testen“ heißt, fragen sich Menschen zu Recht, ob das zwei verschiedene Dinge sind.

Reihenfolge in Dialogen

Bei einem Dialog mit zwei Buttons, etwa „Speichern“ und „Abbrechen“, stellt sich die Frage, welcher links und welcher rechts steht. Die NN/g gibt dazu eine pragmatische Antwort: Es gibt keine allgemeingültig richtige Reihenfolge. Windows stellt die bestätigende Aktion traditionell zuerst, Apple stellt sie ans Ende. Wichtiger als die Reihenfolge selbst ist, dass sie innerhalb deines Produkts immer gleich ist. Wer sich einmal daran gewöhnt hat, wo „Speichern“ sitzt, klickt beim nächsten Mal ohne Nachdenken dorthin.

Eine Ausnahme verdient Aufmerksamkeit: destruktive Aktionen, also solche, die etwas unwiderruflich löschen. Apple rät ausdrücklich, einer zerstörerischen Aktion nicht die Rolle des hervorgehobenen Hauptbuttons zu geben, auch wenn sie die wahrscheinlichste Wahl ist. Der Grund: Gerade weil der Hauptbutton so auffällt, klicken Menschen ihn manchmal, ohne ihn genau zu lesen. Ein Löschen-Button bekommt deshalb eine Warnfarbe (meist Rot) und eine eindeutige Beschriftung, aber nicht automatisch den Platz des Standardbuttons.

Beschriftung: Der Button sagt, was passiert

Die Beschriftung ist der Teil des Buttons, der am meisten über ihn verrät, und gleichzeitig der Teil, an dem am häufigsten gespart wird. Solche kurzen Texte im Interface nennt man Microcopy. Bei Buttons gilt eine einfache Regel: Wer nur den Button liest, sollte wissen, was nach dem Klick passiert.

Verb plus Objekt

Am zuverlässigsten funktionieren Beschriftungen, die mit einem Verb beginnen und das Objekt der Handlung nennen. Apple empfiehlt das in seinen Richtlinien ebenfalls und nennt als Beispiel „Add to Cart“, also „In den Warenkorb“. Ein paar Vorher-nachher-Beispiele:

• „OK“ wird zu „Termin bestätigen“
• „Absenden“ wird zu „Anfrage senden“
• „Hier klicken“ wird zu „Kursplan als PDF laden“
• „Weiter“ wird zu „Weiter zur Zahlung“
• „Ja“ (im Dialog „Möchtest du die Datei löschen?“) wird zu „Datei löschen“

Das letzte Beispiel ist besonders wichtig. Ein Dialog mit „Ja“ und „Nein“ zwingt Menschen, die Frage darüber zu lesen und im Kopf zu übersetzen. Wenn die Frage auch noch verneint formuliert ist („Möchtest du wirklich nicht speichern?“), ist ein Fehlklick fast vorprogrammiert. Mit „Datei löschen“ und „Abbrechen“ ist jeder Button für sich verständlich. Die NN/g empfiehlt aus demselben Grund, Buttons mit konkreten Aktionen statt mit allgemeinen Wörtern wie „OK“ zu beschriften.

„Hier klicken“ und „Mehr erfahren“ vermeiden

„Hier klicken“ beschreibt die Bedienung, nicht das Ziel. „Mehr erfahren“ ist etwas besser, bleibt aber vage: mehr worüber? Wenn auf einer Seite fünfmal „Mehr erfahren“ steht, sind die Buttons außerdem nicht mehr unterscheidbar. Das betrifft besonders Menschen, die einen Screenreader nutzen, also eine Software, die Bildschirminhalte vorliest. Viele Screenreader können alle Links und Buttons einer Seite als Liste ausgeben. Fünfmal „Mehr erfahren“ hintereinander hilft dort niemandem.

Besser ist es, das Ziel zu nennen: „Mehr über Hatha Yoga“ oder „Preise ansehen“. Das ist etwas länger, aber eindeutig.

Kurz, aber nicht kryptisch

Zwei bis vier Wörter reichen für die meisten Buttons. Längere Beschriftungen brechen auf dem Smartphone in zwei Zeilen um und wirken dann unruhig. Wenn eine Aktion mehr Erklärung braucht, gehört sie in einen kurzen Satz neben oder unter den Button, nicht in den Button selbst. Beim Yogastudio steht unter „Probestunde buchen“ zum Beispiel: „Kostenlos, ohne Vertrag. Du brauchst nur eine Matte.“ Dieser Satz räumt die häufigsten Bedenken aus, ohne den Button zu überladen.

Die Sprache konsistent halten

Entscheide dich für eine Form und bleib dabei. Wenn ein Button „Speichern“ heißt, sollte der nächste nicht „Änderungen sichern“ heißen. Für deutschsprachige Interfaces hat sich der Infinitiv bewährt („Termin buchen“, „Konto anlegen“). Auch die Imperativform („Buche deinen Termin“) ist möglich, wirkt aber schnell aufdringlich, wenn sie auf jedem Button steht.

Ehrlich bleiben

Beschriftungen können auch manipulieren. Ein bekanntes Muster ist das sogenannte Confirmshaming: Der Button zum Ablehnen eines Newsletters heißt dann etwa „Nein danke, ich verpasse lieber Angebote“. Solche Tricks gehören zu den Dark Patterns. Sie bringen kurzfristig vielleicht ein paar Anmeldungen, kosten aber Vertrauen. Ein Ablehnen-Button heißt schlicht „Nein, danke“ oder „Nicht jetzt“.

In Deutschland ist für Onlineshops übrigens auch die Beschriftung des Bestellbuttons gesetzlich geregelt: Nach § 312j BGB muss er eindeutig auf die Zahlungspflicht hinweisen, etwa mit „zahlungspflichtig bestellen“. Was das im Checkout genau bedeutet, steht im Artikel Formulare, die niemand abbricht.

Zustände: Ein Button ist nie nur ein Bild

Ein Button sieht nicht immer gleich aus. Er reagiert auf das, was Menschen mit ihm tun, und auf das, was im System passiert. Diese verschiedenen Erscheinungsbilder nennt man Zustände (englisch „states“). Wer einen Button gestaltet, gestaltet also nicht ein Element, sondern eine kleine Familie von Varianten.

Die wichtigsten Zustände

• Standard (Default): So sieht der Button aus, wenn niemand mit ihm interagiert.
• Hover: Die Maus schwebt über dem Button. Eine leichte Farbänderung zeigt: Hier lässt sich klicken. Auf Touchscreens gibt es diesen Zustand nicht, er darf also nie die einzige Information sein.
• Fokus: Der Button ist per Tastatur ausgewählt, zum Beispiel nach mehrmaligem Drücken der Tabulatortaste. Ein deutlich sichtbarer Rahmen zeigt, wo man sich gerade befindet.
• Gedrückt (Active oder Pressed): Der Moment des Klicks oder Tippens. Der Button wird etwas dunkler oder wirkt leicht eingedrückt.
• Laden: Die Aktion läuft, das Ergebnis ist noch nicht da.
• Deaktiviert (Disabled): Der Button ist sichtbar, aber gerade nicht bedienbar.

Fokus: unsichtbar, bis er fehlt

Viele Menschen bedienen Websites nicht mit der Maus, sondern mit der Tastatur, etwa weil sie motorisch eingeschränkt sind, einen Screenreader nutzen oder einfach schneller tippen als klicken. Für sie ist der Fokuszustand die einzige Orientierung. Ohne ihn wissen sie nicht, welcher Button gleich ausgelöst wird, wenn sie Enter drücken.

Die Web Content Accessibility Guidelines (WCAG), die international maßgeblichen Richtlinien für barrierefreie Webinhalte, verlangen deshalb in Kriterium 2.4.7 („Focus Visible“) auf Stufe AA, dass der Tastaturfokus sichtbar ist. Ein häufiger Fehler ist, die Standard-Fokusmarkierung des Browsers per CSS zu entfernen, weil sie „nicht schön“ aussieht. Wenn du sie ersetzt, dann durch eine eigene, die mindestens genauso gut sichtbar ist. Mehr zum Thema findest du im Glossar unter Tastaturbedienung.

Gedrückt und Laden: Rückmeldung geben

Apple formuliert es knapp: Ein eigener Button braucht immer einen gedrückten Zustand. Ohne ihn fühlt er sich an, als würde er nicht reagieren, und Menschen fragen sich, ob ihr Tippen überhaupt angekommen ist.

Noch wichtiger wird Rückmeldung, wenn eine Aktion Zeit braucht. Stell dir vor, jemand tippt beim Yogastudio auf „Probestunde buchen“, und zwei Sekunden lang passiert nichts Sichtbares. Was folgt, ist vorhersehbar: Die Person tippt noch einmal, vielleicht ein drittes Mal, und im schlimmsten Fall entstehen drei Buchungen. Apple empfiehlt für solche Fälle, im Button selbst eine Ladeanzeige einzublenden und die Beschriftung anzupassen, etwa von „Checkout“ zu „Checking out…“. Auf Deutsch könnte das so aussehen:

Vorher: „Probestunde buchen“, nach dem Tippen zwei Sekunden lang keine Veränderung.

Nachher: „Probestunde buchen“ wird sofort zu „Wird gebucht …“ mit kleinem Ladekreis. Ein zweites Tippen löst keine weitere Buchung aus.

Der Button behält dabei seine Breite, damit das Layout nicht springt.

Deaktivierte Buttons: mit Vorsicht einsetzen

Ein ausgegrauter Button, der erst aktiv wird, wenn ein Formular vollständig ist, wirkt auf den ersten Blick elegant. In der Praxis bringt er einige Probleme mit sich. Das schwedische Beratungsunternehmen Axess Lab hat sie in einem viel zitierten Artikel zusammengefasst:

• Ein deaktivierter Button erklärt nicht, warum er deaktiviert ist. Menschen müssen raten, was noch fehlt.
• Er ist meist blass und kontrastarm und damit schwer lesbar. Die WCAG nehmen inaktive Elemente ausdrücklich von den Kontrastanforderungen aus, was es nicht besser macht.
• Per Tastatur und mit Screenreadern lässt er sich oft gar nicht erreichen, weil deaktivierte Elemente aus der Tab-Reihenfolge fallen.

Die Empfehlung von Axess Lab: Den Button aktiv lassen und beim Klick klar sagen, was noch fehlt, direkt am betroffenen Feld. Wenn du ihn trotzdem optisch zurücknehmen willst, dann so, dass er gut lesbar bleibt. Deaktivierte Buttons sind nicht verboten, aber sie sollten die Ausnahme sein, etwa wenn eine Aktion wirklich gerade unmöglich ist und ein kurzer Hinweis daneben den Grund nennt.

Größe und Abstand: Treffen muss leicht sein

Ein Button, den man nicht trifft, hilft niemandem. Wie leicht sich ein Ziel treffen lässt, hängt von seiner Größe und seiner Entfernung ab. Diesen Zusammenhang beschreibt Fitts’ Law: Je größer und näher ein Ziel ist, desto schneller und sicherer erreicht man es.

Mindestgrößen

Für die Größe von Buttons gibt es klare Richtwerte:

• Die WCAG 2.2 verlangen in Kriterium 2.5.8 („Target Size (Minimum)“) auf Stufe AA mindestens 24 × 24 CSS-Pixel. Kleinere Ziele sind nur erlaubt, wenn genug Abstand zu benachbarten Zielen besteht.
• Die strengere Stufe AAA (Kriterium 2.5.5) fordert 44 × 44 CSS-Pixel.
• Apple empfiehlt eine Trefferfläche von mindestens 44 × 44 Punkten.
• Google empfiehlt für Android mindestens 48 × 48 dp (dichteunabhängige Pixel, eine Maßeinheit, die auf verschiedenen Displays etwa gleich groß wirkt).

Für die Praxis ist die Faustregel einfach: Buttons, die auf dem Smartphone angetippt werden, sollten mindestens 44 bis 48 Pixel hoch sein. 24 Pixel sind die Untergrenze der WCAG, keine Empfehlung für gute Bedienbarkeit.

Wichtig dabei: Es zählt die anklickbare Fläche, nicht unbedingt die sichtbare. Ein kleines Symbol, etwa ein „X“ zum Schließen, kann optisch zierlich bleiben, solange seine Trefferfläche durch Innenabstand groß genug ist. Apple empfiehlt bei Bild-Buttons zum Beispiel rund 10 Pixel Innenabstand zwischen Bild und Buttonrand.

Abstand zwischen Buttons

Mindestens genauso wichtig wie die Größe ist der Abstand. Zwei Buttons, die direkt aneinanderstoßen, laden zum Danebentippen ein. Besonders heikel ist das, wenn die beiden Aktionen sehr unterschiedliche Folgen haben, etwa „Speichern“ und „Löschen“. Solche Paare gehören nicht dicht nebeneinander, und die destruktive Aktion braucht zusätzlich eine Bestätigung oder die Möglichkeit, sie rückgängig zu machen.

Position

Auf dem Smartphone erreichen Menschen den unteren Bildschirmbereich mit dem Daumen leichter als die oberen Ecken. Für wichtige Aktionen in Apps hat es sich deshalb bewährt, sie unten zu platzieren, oft als Button über die volle Breite. Auf Websites gilt: Der primäre Button steht dort, wo die Entscheidung fällt, also direkt nach der Information, die jemand für diese Entscheidung braucht. Beim Yogastudio steht „Probestunde buchen“ deshalb unter der kurzen Beschreibung des Angebots und noch einmal nach den Preisen, nicht isoliert in einer Ecke.

Kontrast und Farbe

Ein Button muss sich klar von seiner Umgebung abheben, und sein Text muss gut lesbar sein. Für beides gibt es messbare Werte. Das Kontrastverhältnis beschreibt, wie stark sich zwei Farben in ihrer Helligkeit unterscheiden. Die WCAG verlangen für normalen Text mindestens 4,5:1 (Kriterium 1.4.3). Für die Begrenzung eines Bedienelements fordern sie in Kriterium 1.4.11 („Non-text Contrast“) mindestens 3:1 gegenüber den angrenzenden Farben, allerdings nur dann, wenn diese Begrenzung nötig ist, um den Button überhaupt zu erkennen. Ein Button, der schon durch seinen Text als Button erkennbar ist, braucht keinen kontrastreichen Rahmen.

Praktisch bedeutet das: Ein hellgrauer Outline-Button auf weißem Hintergrund kann problematisch sein, wenn der Rahmen das Einzige ist, was ihn als Button kennzeichnet. Für die Fokusmarkierung gilt ebenfalls ein Kontrast von 3:1 zu den angrenzenden Farben.

Und Farbe allein reicht nie. Wenn sich der primäre Button vom sekundären nur durch Grün statt Grau unterscheidet, sehen das nicht alle Menschen gleich. Gefüllte Fläche gegenüber Rahmen ist ein Unterschied, der auch ohne Farbwahrnehmung funktioniert. Prüfen lassen sich die Werte zum Beispiel mit dem WebAIM Contrast Checker.

Button oder Link?

Zum Schluss ein Punkt, der eher die Umsetzung betrifft, aber auch im Design wichtig ist: Buttons lösen Aktionen aus, Links führen woandershin. Im Code entspricht das zwei verschiedenen HTML-Elementen, <button> und <a>. Screenreader kündigen sie unterschiedlich an, und sie reagieren unterschiedlich auf die Tastatur.

Im Design verschwimmt das oft, und das ist auch in Ordnung: Ein CTA wie „Kursplan ansehen“ führt technisch auf eine andere Seite, darf aber wie ein Button aussehen. Wichtig ist nur, dass im Code das richtige Element steckt. Ein häufiger Fehler ist das Gegenteil: ein <div>, das wie ein Button aussieht und per Klick funktioniert, sich aber weder mit der Tastatur erreichen lässt noch vom Screenreader als Button erkannt wird.

Ein weiteres Detail betrifft Buttons, die nur ein Symbol zeigen, etwa ein Herz zum Merken oder ein Zahnrad für die Einstellungen. Laut MDN Web Docs, der Referenz von Mozilla für Webentwicklung, haben solche Buttons ohne Text keinen zugänglichen Namen, den ein Screenreader vorlesen kann. Die Lösung: ein Text im Button, der notfalls nur für Screenreader sichtbar ist. Sichtbarer Text hilft aber allen, denn nicht jedes Symbol ist so eindeutig, wie es im Designteam wirkt.

Fazit

Am Ende hat die Startseite des Yogastudios nicht mehr sechs gleich laute Buttons, sondern eine klare Rangfolge. „Probestunde buchen“ ist der einzige gefüllte Button im sichtbaren Bereich, mit einem kurzen Satz darunter, der Bedenken ausräumt. „Kursplan ansehen“ steht daneben als Outline-Button. Alle Buttons sind mindestens 44 Pixel hoch, haben einen sichtbaren Fokus und zeigen nach dem Tippen, dass etwas passiert. „Hier klicken“ und „Absenden“ sind verschwunden.

Gute Buttons sind selten spektakulär. Sie fallen dann auf, wenn sie fehlen: wenn Menschen suchen, zögern, doppelt klicken oder das Falsche löschen. Wenn du dir bei jedem Button die vier Fragen dieses Artikels stellst (Wie wichtig ist er? Sagt er, was passiert? Reagiert er auf alles, was Menschen tun? Lässt er sich gut treffen?), bist du den meisten Interfaces schon einen Schritt voraus. Ob es wirklich funktioniert, zeigt ein kurzer Test: Lass jemanden ohne Erklärung die wichtigste Aufgabe auf deiner Seite erledigen und beobachte, wohin der Blick zuerst geht.

Checkliste

• Jeder Bereich hat genau einen primären Button, alle anderen sind sichtbar nachrangig.
• Die Hierarchie entsteht über Stil (gefüllt, Rahmen, Text), nicht über unterschiedliche Größen nebeneinander.
• Derselbe CTA heißt überall gleich.
• Jede Beschriftung nennt die Aktion, idealerweise als Verb plus Objekt. Kein „OK“, „Hier klicken“ oder „Ja“.
• Destruktive Aktionen sind eindeutig beschriftet, farblich markiert und nicht der Standardbutton.
• Hover, Fokus, Gedrückt und Laden sind gestaltet, der Fokus ist deutlich sichtbar.
• Deaktivierte Buttons sind die Ausnahme und erklären, warum sie nicht bedienbar sind.
• Touch-Ziele sind mindestens 44 × 44 Pixel groß und haben genug Abstand zueinander.
• Buttontext hat mindestens 4,5:1 Kontrast, nötige Begrenzungen mindestens 3:1.
• Im Code stecken echte <button>- und <a>-Elemente, Symbol-Buttons haben einen zugänglichen Namen.

Quellen

• Nielsen Norman Group: Flat UI Elements Attract Less Attention and Cause Uncertainty
• Nielsen Norman Group: OK-Cancel or Cancel-OK?
• Apple Human Interface Guidelines: Buttons
• Material Design (Material Web): Buttons
• Google: Touch target size (Android-Barrierefreiheit)
• Axess Lab: Disabled buttons suck
• W3C: Understanding SC 2.5.8 Target Size (Minimum)
• W3C: Understanding SC 1.4.11 Non-text Contrast
• W3C: Understanding SC 2.4.7 Focus Visible
• MDN Web Docs: Das Button-Element
• Gesetze im Internet: § 312j BGB