2026
11. Mai 2026
Fragen vor Pixeln
Ein kurzes Handbuch für UX im Jahr 2026. Die Hürde für "sieht gut aus" liegt jetzt bei null. Was bleibt, ist das Hinterfragen, bevor ein Pixel gezeichnet wird.
S
Sascha Becker
Author17 Min. Lesezeit
11. Mai 2026
Ein kurzes Handbuch für UX im Jahr 2026. Die Hürde für "sieht gut aus" liegt jetzt bei null. Was bleibt, ist das Hinterfragen, bevor ein Pixel gezeichnet wird.
17 Min. Lesezeit
Im Jahr 2026 produziert ein halbwegs fähiger Generator in unter einer Minute ein poliertes Interface. Prompt eintippen, Layout bekommen. Prompt verfeinern, besseres Layout bekommen. Stil wählen, Palette tauschen, Empty State neu generieren. Der Bildschirm sieht gut aus. Er sieht aus, als hätte ihn jemand entworfen, der sein Handwerk versteht. In gewisser Weise stimmt das auch.
Damit hat sich die Hürde dafür verschoben, was als Designarbeit zählt. "Sieht gut aus" war früher ein bedeutsames Lob. Es signalisierte Handwerk, Geschmack, investierte Stunden. Heute signalisiert es, dass das Werkzeug benutzt wurde. Politur ist kein Wettbewerbsvorteil mehr. Sie ist der Standard.
Was nicht der Standard ist, ist das Denken darunter: ob der Bildschirm überhaupt existieren sollte, wo die Aufmerksamkeit beim Öffnen landen soll, was der Nutzer dreißig Sekunden vorher getan hat, was er als Nächstes versuchen wird und was es ihn kostet, wenn er falsch rät. Nichts davon wird generiert. Nichts davon wird in einem Code Review erwischt. Nichts davon taucht in einem Figma Mockup auf, das isoliert betrachtet großartig aussieht.
Dieser Artikel ist ein Handbuch für genau diesen Teil. Nicht die visuelle Ebene, sondern die Frageebene. Eine Liste der Fragen, die es wert sind, beantwortet zu werden, bevor ein einziger Pixel gezeichnet wird, plus eine kurze Diagnose, um eine UI Korrektur von einer echten UX Korrektur zu unterscheiden. Sie ist zum mehrfachen Nachschlagen gedacht, nicht zum einmaligen Lesen.
Jared Spool macht seit über einem Jahrzehnt denselben Punkt: UX ist die Erfahrung, die der Nutzer von Anfang bis Ende macht, und UI ist eine von vielen Oberflächen, auf denen sie sich zeigt.1 Ein schöner Bildschirm, der an einem verworrenen Flow hängt, ist schlechte UX in gutem UI Gewand. Ein schlichter Bildschirm, der an einem Flow hängt, der den Nutzer in zwei klaren Schritten zum Ziel bringt, ist gute UX im T-Shirt.
Don Norman, der den Begriff "User Experience" Anfang der 90er bei Apple geprägt hat, hat ihn von Anfang an als alles rund um die Interaktion mit einem Produkt definiert, nicht nur als Bildschirm.2 Der Bildschirm ist eine Scheibe. Diese Scheibe ist zufällig die sichtbarste, weshalb sie den größten Teil des Budgets und der Gespräche aufsaugt. Sie ist auch die Scheibe, die jetzt am billigsten zu produzieren ist.
Die Falle sieht so aus. Eine Ansicht fühlt sich falsch an. Jemand bemerkt es. Der Vorschlag lautet: "Lass uns diese Karte neu designen." Die Karte wird neu designt. Sie sieht besser aus. Das ursprüngliche Problem (Nutzer brechen einen Flow ab, übersehen einen Button, landen auf dem falschen Bildschirm) ist unverändert, weil das Problem nie die Karte war. Es war der Pfad, der zur Karte geführt hat, oder die Annahme, dass diese Karte überhaupt existieren musste.
Die Fragen in diesem Handbuch sind dafür gedacht, diese Lücke aufzudecken, bevor sie als neu gestaltete Karte auftaucht.
Die meisten "UX Probleme", die von Nutzern, dem Support oder Stakeholdern gemeldet werden, werden in UI Begriffen beschrieben, weil UI das ist, worauf man zeigen kann. "Der Button ist schwer zu finden." "Das Formular ist verwirrend." "Diese Seite ist hässlich." Eine UI förmige Beschwerde bedeutet keine UI förmige Korrektur.
Eine kurze Diagnose, die du durchgehen solltest, bevor du Figma öffnest:
| Wenn die Antwort lautet... | Dann ist die Korrektur wahrscheinlich... |
|---|---|
| Der Nutzer findet die Aktion nicht, die er braucht | UX. Falscher Bildschirm, falscher Moment oder falsche Informationsarchitektur. |
| Der Nutzer findet die Aktion, vertraut ihr aber nicht | UX. Fehlendes Feedback, fehlender Kontext, unklare Konsequenz. |
| Der Nutzer löst die Aktion aus und landet, wo er es erwartet hatte | UI Politur. Die Seite funktioniert, aber die visuelle Hierarchie stimmt nicht. |
| Der Nutzer schließt die Aufgabe ab, sagt aber, es fühle sich "klobig" an | UX. Zu viele Schritte, fehlende Defaults, das System zwingt den Nutzer zum Nachdenken. |
| Der Nutzer kann nicht erkennen, ob etwas passiert ist | UX. Fehlendes oder verzögertes Feedback, gebrochene Schleife zwischen Aktion und Ergebnis. |
| Zwei Bildschirme sehen fast gleich aus, der Nutzer wählt den falschen | UX. Zwei Bildschirme, die gleich aussehen, sollten meistens nicht zwei Bildschirme sein. |
| Der Bildschirm tut das Richtige, sieht aber veraltet aus | UI Politur. Wirklich kosmetisch. Behandle es entsprechend. |
Wenn die meisten deiner "UX Probleme" in der UI Politur Zeile landen, herzlichen Glückwunsch: Du hast gute UX und einen Styling Backlog. Wenn sie überall sonst landen, wird das Neudesign eines einzelnen Bildschirms die Metrik, die dich interessiert, vermutlich nicht bewegen.
Die Patch Falle
Die billigste Korrektur ist "mach diese Steuerung prominenter". Sie wird das Review bestehen, sie wird nach Fortschritt aussehen, und sie wird den Funnel nicht bewegen. Wenn ein Symptom nach jeder Runde UI Politur zurückkehrt, liegt das Problem eine Ebene höher: im Flow, im Einstiegspunkt oder in der Existenz des Bildschirms selbst.
Was folgt, ist eine Arbeitsliste. Geh sie durch, bevor du das Designtool öffnest, nicht danach. Zwölf Fragen, ungefähr in der Reihenfolge, in der sie beißen, wenn man sie überspringt. Die meisten sind unspektakulär. Die ersten drei werden am häufigsten übersprungen und sind am teuersten, wenn sie es werden.
Das billigste UI ist das, das du nicht ausspielst. Bevor du eine neue Ansicht entwirfst, frage, ob dieselbe Aufgabe auch durch eine Inline Aktion, einen Dialog, einen Default, der die Wahl wegnimmt, oder schlicht durch Nichtfragen erledigt werden kann. Jeder neue Bildschirm ist Navigationskosten, Wartungskosten und ein Ort, an dem sich der Nutzer verlieren kann. Die Antwort lautet manchmal "ja, er rechtfertigt seinen Platz". Sie lautet weit häufiger "nein, das könnte eine Zeile in der bestehenden Liste sein".
Bildschirme werden isoliert entworfen, aber sie werden in Flows benutzt. Der Nutzer ist nicht aus dem Nichts auf deine Ansicht teleportiert worden. Er kam von irgendwoher, in einem bestimmten Zustand, mit einer bestimmten Absicht. Wenn das Design einen frischen, fokussierten Nutzer voraussetzt, wird es bei dem häufigsten Fall danebenliegen: dem Nutzer mitten in einer Aufgabe, mitten in einem Gespräch, mitten in einer Suche, mit einem Gedanken im Kopf, den er sich nicht leisten kann zu verlieren. Verankere den Bildschirm im Moment, nicht im Empty State.
Nicht der Feature Name. Nicht der Seitentitel. Die Absicht des Nutzers, formuliert, wie er sie formulieren würde. "Diese Rechnung bezahlen." "Die Datei finden, die ich gestern offen hatte." "Entscheiden, ob ich verlängere." Wenn das Team sich nicht auf diesen Satz einigen kann, wird der Bildschirm ein Kompromiss aus drei verschiedenen unausgesprochenen Absichten sein und keine davon gut bedienen.
Jeder Bildschirm hat ein Aufmerksamkeitsbudget. Der Nutzer verbringt grob die erste Sekunde damit, auf genau eine Sache zu schauen, dann die nächsten zwei Sekunden auf eine oder zwei weitere.3 Wenn du nicht benennen kannst, was die erste Sache ist, hat der Bildschirm keine Hierarchie. Wenn du es benennen kannst, es aber nicht das Wichtigste für die Aufgabe des Nutzers ist, ist die visuelle Hierarchie falsch, egal wie gut das Spacing ist.
Sobald sich der Nutzer orientiert hat, welche eine Aktion erwartest du, dass er durchführt? Ist sie das prominenteste Element auf dem Bildschirm? Ist sie in der Sprache des Nutzers beschriftet, nicht in der des Systems? Steht sie dort, wo das Auge nach dem Orientierungs Scan landet? Wenn die nächste Aktion einen Scan erfordert, hat das Design implizit entschieden, dass "der Nutzer es schon herausfinden wird". Das ist eine Hoffnung, keine Designentscheidung.
Jedes Interface wird zweimal designt: einmal für den Happy Path und einmal für den Moment, in dem der Nutzer das Falsche tut. Die meisten Designs liefern nur das Erste aus. Der Unhappy Path ist der Nutzer, der ins falsche Feld tippt, den falschen Button klickt, mitten in der Bearbeitung wegnavigiert, Zurück drückt, doppelt absendet, eine Berechtigung verweigert, die Verbindung verliert. Jeder dieser Fälle hat einen Wiederherstellungsaufwand. Designs, die sie ignorieren, sind Designs, die in der Demo funktionieren und in der Produktion brennen.
Der billigste Unhappy Path Test
Öffne den Bildschirm. Klicke auf alles, was nicht der vorgesehene nächste Schritt ist. Notiere, was jede dieser Aktionen den Nutzer kostet. Wenn eine davon Arbeit verliert, Kontext verliert oder ihn an einen Ort bringt, von dem er nicht in einem Schritt zurückkommt, sind das die Fälle, für die das Design eine Antwort braucht. Sie werden eintreten.
Jedes Formularfeld, jede Bestätigung, jedes "Bist du sicher?" ist eine kleine Unterstellung, dass der Nutzer vielleicht nicht weiß, was er tut. Manche dieser Unterstellungen sind berechtigt. Die meisten sind Überbleibsel aus der ersten Auslieferung des Features, als das Team nervös war. Prüfe, was das Design den Nutzer bestätigen, wiederholen oder erneut eingeben lässt. Wenn du jeden einzelnen Punkt nicht mit einem echten Fehlerfall verteidigen kannst, den er verhindert, streich ihn.
Das polierte Mockup zeigt den Bildschirm mit drei perfekt repräsentativen Einträgen. Echte Nutzer sehen ihn mit null Einträgen am ersten Tag, mit fünfhundert Einträgen im zweiten Jahr, mit einer langsamen API Antwort in der ersten Woche und mit einem 500er Fehler an dem Tag, an dem ein Kollege auf sie angewiesen ist. Jeder dieser Zustände ist ein echter Bildschirm, den der Nutzer sehen wird. Nur den mittleren zu designen heißt, eine Fiktion zu designen.
Eine praktische Checkliste:
Designs, die nur den "happy, voll, schnell" Zustand beantworten, bestehen das Review und scheitern in Woche zwei.
Aktion ohne Feedback ist der häufigste Fehler im Interface Design.4 Der Nutzer klickt Speichern, das Netzwerk macht 800 Millisekunden hin und her, der Bildschirm tut nichts, der Nutzer klickt Speichern erneut. Jede Interaktion braucht eine sichtbare Bestätigung, dass das System sie empfangen hat, und ein sichtbares Ergebnis, sobald das System gehandelt hat. Optimistische Updates, Inline States, Toasts, Fokuswechsel: Wähle eines und nutze es konsistent. Stille ist kein Zustand.
Das Design, das mit "der Nutzer hat den Button geklickt und es hat funktioniert" endet, ist unvollständig. Nach dem Erfolg ist der Nutzer irgendwo mit einem neuen Zustand, einer neuen Frage, einem neuen nächsten Schritt. Wo platzierst du ihn? Auf demselben Bildschirm mit einer Bestätigung? Auf einem Folge Bildschirm, auf dem die nächste wahrscheinliche Aktion bereits vorbereitet ist? Zurück, wo er hergekommen ist? Der Moment nach dem Erfolg ist einer der hebelstärksten Momente in jedem Interface, weil der Nutzer aufmerksam ist und sich gerne führen lässt. Die meisten Designs verschenken ihn.
Nicht alle Aktionen verdienen dasselbe Gewicht. Eine Zeile Testdaten zu löschen und die Rechnungshistorie eines Kunden zu löschen sind nicht dieselbe Operation und sollten nicht dieselbe Anzahl Klicks oder dieselbe Art Bestätigung erfordern. Reversible Aktionen mit niedrigem Einsatz sollten ein Klick und ein klares Undo sein. Irreversible Aktionen mit hohem Einsatz sollten absichtlich langsamer sein, mit einer Bestätigung, die das konkret betroffene Element nennt, nicht ein abstraktes "Bist du sicher?". Passe die Reibung an die Schadensreichweite an.
Diese Frage macht die meisten der vorigen elf günstig. Eine einzige Beobachtungssitzung mit einem echten Nutzer, der die tatsächliche Aufgabe im tatsächlichen Flow erledigt, fördert mehr Probleme zutage als eine Woche internes Review. Die Intuition des Teams darüber, wo Nutzer kämpfen werden, liegt zuverlässig daneben, weil das Team das Ding gebaut hat und nicht mehr verlernen kann, wie es funktioniert.5 Fünf Nutzer fangen rund 85% der Usability Probleme eines Flows ab. Ein Nutzer fängt ein Drittel davon ab. Die Grenzkosten eines weiteren Nutzers sind Stunden, nicht Wochen. Es gibt kein Designbudget, das dafür zu klein ist.
Die Fragen funktionieren nur, wenn sie zum richtigen Zeitpunkt auftauchen. Die meisten Teams, die "bessere UX machen" wollen, schieben ein Review am Ende ein, nachdem das Design fertig ist. Das ist der schlechteste Zeitpunkt, um zu fragen, ob der Bildschirm überhaupt existieren sollte. Eine Antwort an dieser Stelle kostet das Wegwerfen des Designs.
Eine bessere Platzierung, grob in chronologischer Reihenfolge:
Beim Ticket. Bevor das Designticket gezogen wird, sollte das Team die Fragen 1, 2 und 3 beantworten können. Sollte das existieren, was hat der Nutzer vorher getan, was versucht er zu erreichen. Wenn das Ticket diese Fragen nicht beantworten kann, verfeinere das Ticket, fang nicht das Design an.
Bei der ersten Skizze. Die Fragen 4 bis 7 gehören zur ersten niedrig auflösenden Skizze. Wo das Auge landet, was die nächste Aktion ist, was passiert, wenn der Nutzer falsch liegt, was das Design beim Nutzer voraussetzt. Keine davon braucht Pixel zur Beantwortung. Sie brauchen ein Whiteboard oder eine Serviette. Wenn du das Layout nicht in Bleistift verteidigen kannst, wird keine Politur es retten.
Bei der hochauflösenden Stufe. Die Fragen 8 und 9, die Empty / Slow / Broken / Full Zustände und das Feedback Modell, gehören hierher. Sie werden gerne übersprungen, weil sie unspektakulär sind. Ihr Fehlen ist auch das, was in der Produktion zuerst auffällt.
Vor der Übergabe. Die Fragen 10 und 11, der Zustand nach dem Erfolg und die Reibungs Kalibrierung, verdienen einen expliziten Durchgang vor der Übergabe an die Entwicklung. Sie sind oft erst sichtbar, wenn die Bildschirme in Reihenfolge betrachtet werden, nicht isoliert.
Vor "fertig". Frage 12, einen echten Nutzer beobachten. Fünf, wenn du kannst, einen, wenn du nicht kannst. Bevor das Feature fertig genannt wird, nicht danach.
Eine Meeting Kadenz, die nichts kostet
Füge drei Minuten zu deinem Designreview hinzu: eine Minute zu "was hat der Nutzer vor diesem Bildschirm getan?", eine zu "was ist das Erste, worauf er schaut?", und eine zu "was passiert, wenn er falsch liegt?". Du brauchst keinen formalen Prozess. Du brauchst jemanden, der diese drei Dinge jedes einzelne Mal fragt, bis das Team beginnt, sie unaufgefordert zu beantworten.
Wenn die Fragen so offensichtlich sind, warum wird dann der Großteil der Arbeit in der Branche nicht so gemacht? Ein paar ehrliche Gründe.
Hübsch ist lesbar. Denken nicht. Ein poliertes Mockup wird im Stand up gelobt. Ein neu geschnittener Flow, der zwei Bildschirme entfernt hat, nicht. Die Arbeit, die das bessere Ergebnis liefert, ist unsichtbar, weil das Artefakt "wir haben weniger ausgeliefert" ist. Teams, die das laute Denken belohnen, bekommen mehr davon.
Die Werkzeuge formen die Arbeit. Designtools sind Oberflächentools. Sie sind exzellent darin, Pixel zu produzieren, und gleichgültig gegenüber Flows. Der Pfad des geringsten Widerstands in jedem modernen Designtool ist, den aktuellen Bildschirm besser aussehen zu lassen, nicht zu fragen, ob der aktuelle Bildschirm existieren sollte. Werkzeuge haben eine Schwerkraft, und die Schwerkraft zieht zum Artefakt.
Stakeholder fragen nach Bildschirmen. "Kannst du mir ein Mockup zeigen?" ist die häufigste Anfrage, die ein Designer hört. Fast niemand fragt "kannst du mir den User Flow zeigen, bevor du anfängst zu mocken?" Das Standardlieferobjekt ist ein Bildschirm, also werden Bildschirme produziert. Das Lieferobjekt zu ändern ändert die Arbeit.
Der Nutzer ist nicht im Raum. Die meisten Designentscheidungen werden zwischen den Leuten getroffen, die das Produkt gebaut haben. Sie teilen Annahmen, die der Nutzer nicht teilt. Ohne eine Stimme im Raum, die nicht die des Teams ist, werden die Annahmen des Teams zum Design.
Prozess frisst Handwerk. Wenn Teams die Lücke bemerken, ist der Instinkt, eine "UX Review" Stufe in den Workflow einzubauen. Reviews fangen ein paar Dinge ab, aber sie ändern nicht, wie die Arbeit in den Stunden zwischen den Reviews gemacht wird. Die Fragen in diesem Handbuch funktionieren nur, wenn sie in der Designphase leben, nicht in einem separaten Gate.
Keines davon ist unlösbar. Sie sind vorhersehbar, und sie sind es wert, benannt zu werden, weil jedes Team, das versucht, seine UX Hürde anzuheben, in dieselben fünf Hindernisse in derselben Reihenfolge läuft.
Generative Werkzeuge sind sehr gut darin, Interfaces zu bauen. Sie sind nicht gut, und werden es vermutlich auch nicht bald sein, im Entscheiden, welches Interface existieren sollte, welche Frage der Nutzer eigentlich stellt, was der Nutzer vor zwei Minuten getan hat oder was es kostet, wenn er einen Fehler macht. Diese Entscheidungen sind lokal zum Team, zum Produkt, zum Kunden, zum Moment. Sie sind auch die Entscheidungen, die den Unterschied ausmachen zwischen einem Bildschirm, der designt aussieht, und einem Produkt, das sich designt anfühlt.
Die optimistische Version dieses Übergangs ist, dass die Zeit, die frei wird, weil man nicht mehr mit Pixeln kämpft, in die Fragen dieses Handbuchs investiert wird. Die pessimistische Version ist, dass die freigewordene Zeit darin verbracht wird, mehr Bildschirme zu produzieren. In welcher Version ein Team landet, ist keine Funktion der Werkzeuge. Es ist eine Funktion davon, welche Fragen im Raum gestellt werden, von wem und wie früh.
Die Arbeit, die gute UX produziert, hat sich in zwanzig Jahren nicht verändert. Die Arbeit, die gut aussehendes UI produziert, ist heute beinahe kostenlos. Dass beides verwechselt wird, ist die Quelle der meisten Verwirrung im Produktdesign heute, und genau das sollen die Fragen in diesem Handbuch trennen.
Stelle die Fragen. Stelle sie immer wieder. Die Bildschirme folgen dann von selbst.
Es gibt einen Skill dafür
Diese zwölf Fragen und das UI-vs-UX-Diagnostic gibt es als Agent-Skill.
Installation mit npx skills@latest add saschb2b/skills --skill ask-ux oder
direkt zum vollen ask-ux-Skill.
Die kanonische Fallstudie dafür, warum eine einzige schlechte UX Entscheidung mehr kosten kann als ein mehrjähriger visueller Relaunch. Einmal im Jahr neu lesen.
Don Norman, der den Begriff Anfang der 90er bei Apple geprägt hat, darüber, warum UX immer die gesamte Erfahrung abdecken sollte, nicht nur das Interface.
Die Heuristiken von 1994 halten immer noch. Sichtbarkeit des Systemstatus, Übereinstimmung mit der realen Welt, Fehlervermeidung, Wiedererkennen statt Erinnern. Eine kurze Liste, die jeder Designer aufsagen können sollte.
Das klassische Argument für Usability Testing mit kleinem Budget. Fünf Nutzer fangen die meisten Probleme ab. Ein Nutzer fängt mehr als null ab. Es gibt keine Ausrede, nicht zu testen.
Immer noch das nützlichste einzelne Buch zu Usability. Die ganze These steht im Titel, aber die Kapitel zu Selbstevidenz, Hierarchie und Testen sind die zum Nachlesen.
Eine Neurahmung von UX als 'hilf dem Nutzer, in seinem Ziel besser zu werden', nicht 'hilf dem Nutzer, das Produkt zu benutzen'. Die Verschiebung ist klein, die Konsequenzen sind groß.
Zielorientiertes Design, Personas und die Disziplin, für die Absicht des Nutzers zu designen statt für die Struktur des Systems. Das Referenzwerk für das Designen von Flows, nicht von Bildschirmen.
| Der Nutzer macht weiterhin das, wovor das System warnt | UX. Die Warnung steht am falschen Ort, oder das Design kämpft gegen den Workflow. |