UX Designer verbringen zu viel Zeit in Figma und zu wenig im eigenen Produkt

Vielleicht ist das die wichtigste Erkenntnis überhaupt. Ein perfekt gebauter Screen in Figma sagt erstaunlich wenig darüber aus, wie sich ein Produkt nach drei Monaten täglicher Benutzung anfühlt. In Figma gibt es keine echten Ladezeiten, keine zehn Jahre alten Datensätze, keine Berechtigungsprobleme, keine vergessenen Empty States, keine Browser-Eigenheiten und keine Situation, in der jemand unter Zeitdruck versucht, eine Aufgabe zum zwanzigsten Mal an diesem Tag zu erledigen. Figma zeigt einen idealisierten Zustand. Das echte Produkt zeigt die Realität.

In vielen Produktorganisationen entsteht dadurch eine interessante Distanz: UX arbeitet in Figma, Product in Jira oder Linear, Development im Code, Management in Dashboards und Marketing mit Screenshots. Alle beschäftigen sich permanent mit dem Produkt – und trotzdem verbringt kaum jemand mehrere Stunden pro Woche wirklich im Produkt selbst. So kennen Teams irgendwann Roadmap, Tickets, Komponenten und Feature-Namen besser als das tatsächliche Nutzungserlebnis.

Genau hier setzt Heavy Use an. Es geht nicht darum, vor einem Release einmal den Happy Path durchzuklicken, sondern das Produkt so intensiv zu verwenden, dass seine Eigenheiten sichtbar werden. Erst dann merkt man, welche Navigation zwar logisch, aber dauerhaft langsam ist; welche Information immer an der falschen Stelle auftaucht; welcher Dialog nach dem fünfzigsten Mal nervt; oder welche Funktion theoretisch gut gelöst ist, praktisch aber ständig einen Umweg erzeugt.

User Testing ist extrem wertvoll, aber es zeigt meist einen Ausschnitt. Wir geben einem Nutzer eine Aufgabe, beobachten zwanzig oder dreißig Minuten und sehen, wo er zögert, was er übersieht oder wo er abbricht. Was wir damit kaum sehen, ist die Wirkung von Wiederholung: Wie fühlt sich eine Funktion nach dem hundertsten Mal an? Welche fünf Sekunden werden nach drei Monaten unerträglich? Welche kleine Inkonsistenz kostet täglich Zeit? Genau diese Dimension wird erst sichtbar, wenn Nutzung zur Routine wird.

Ein einzelner zusätzlicher Klick ist meistens kein Problem. Wenn ein Nutzer einen Prozess aber 50-mal pro Tag ausführt, werden daraus 250 Klicks pro Woche, rund 1.000 im Monat und 12.000 im Jahr. Aus einer scheinbar kleinen Interaktion wird wiederkehrende Arbeit. Heavy User beginnen deshalb, Interfaces nicht nur visuell oder funktional zu betrachten, sondern auch zeitlich: Was wiederholt sich? Was kostet Aufmerksamkeit? Was muss immer wieder neu entschieden oder eingegeben werden?

Viele dieser Probleme lassen sich auf wenige typische Reibungspunkte reduzieren:

• dieselben Filter oder Einstellungen immer wieder setzen,
• Informationen erneut eingeben, obwohl das System sie bereits kennt,
• Bestätigungsdialoge und Zwischenschritte wiederholt durchlaufen,
• für häufige Aktionen tief navigieren oder zwischen Tools wechseln,
• auf langsame Zustände warten oder denselben Kontext ständig neu herstellen.

Mein stärkstes UX-Signal ist deshalb manchmal schlicht: Wann nervt mich mein eigenes Produkt? Nicht einmal, sondern wiederholt. Genervtheit ist häufig ein guter Indikator für systematische Reibung. Beim ersten Mal akzeptiert man einen unnötigen Schritt, beim zehnten Mal wundert man sich und beim fünfzigsten Mal stellt man die eigentlich interessante Frage: Warum existiert dieser Schritt überhaupt? Vielleicht müssen wir das Formular nicht schöner machen, sondern abschaffen. Vielleicht braucht es keinen besseren Dialog, sondern gar keinen Dialog. Vielleicht sollte der Prozess nicht optimiert, sondern automatisiert werden.

Gerade mit AI wird diese Frage noch wichtiger. Wenn ein System meine Rolle, meinen Kontext, meine bisherigen Entscheidungen und häufigsten Aktionen kennt, warum zwingt es mich dann immer wieder zu denselben Eingaben? Heavy Use legt solche Muster offen – und macht aus kleinen UX-Reibungen oft konkrete Automatisierungs- oder Produktideen.

Wer das eigene Produkt intensiv benutzt, beobachtet irgendwann automatisch auch sein eigenes Verhalten. Wo suche ich? Wo springe ich zurück? Wo öffne ich parallel Excel? Wo mache ich Screenshots, kopiere Daten in Notizen oder baue mir einen Workaround? Gerade diese Umwege sind extrem wertvoll, denn sie zeigen, wo ein Produkt nicht vollständig zum realen Prozess passt. Wenn Nutzer regelmäßig außerhalb des Systems weiterarbeiten müssen, fehlt vielleicht eine Funktion – oder eine vorhandene ist zu kompliziert, zu langsam oder falsch platziert.

Deshalb sollten Designer und Product Teams nicht nur Features testen, sondern echte Arbeit im Produkt erledigen. Nicht nur prüfen, ob der Export-Button funktioniert, sondern die Datei exportieren, öffnen, weiterverarbeiten und teilen. Nicht nur testen, ob die Suche Ergebnisse liefert, sondern einen alten Datensatz finden, dessen exakten Namen man nicht kennt. Nicht nur einen Checkout durchspielen, sondern wirklich bestellen, ändern, stornieren und erneut bestellen. Das echte Nutzungserlebnis beginnt oft genau dort, wo der definierte Testfall endet.

Besonders deutlich wird das bei komplexen B2B-Produkten. Ein Screen kann hervorragend aussehen und der Gesamtprozess trotzdem mühsam sein, weil dahinter Berechtigungen, Freigaben, ERP- und Produktdaten, Varianten, Statuswechsel, Tabellen, Exporte, Legacy-Systeme und reale Unternehmensabläufe stehen. In solchen Produkten ist UX sehr häufig Prozessdesign und nicht nur Screen Design. Wer diese Prozesse wirklich verstehen will, sollte sie selbst mehrfach mit echten Daten durchlaufen.

Ich habe durch eigene Produkte wahrscheinlich mehr über UX gelernt als durch viele theoretische Methoden. Bei Kundenprojekten kann man eine Entscheidung irgendwann übergeben: Das Feature geht live, das Projekt läuft weiter. Beim eigenen Produkt funktioniert das nicht. Man begegnet seinen Entscheidungen jeden Tag wieder. Bei Produkten wie Gutscheingirl, coopz oder Mina war ich nicht nur derjenige, der über UX nachgedacht hat, sondern gleichzeitig Produktverantwortlicher, Betreiber, Nutzer, Support, Tester und teilweise Vertrieb. Dadurch verschwindet die Distanz zwischen Designentscheidung und Konsequenz.

Eine Idee kann im Konzept hervorragend aussehen, in Figma überzeugen und im Meeting Zustimmung bekommen – und zwei Wochen später merkt man bei täglicher Nutzung, dass sie nervt. Dann spielt die ursprüngliche Design-Rationale kaum noch eine Rolle. Entscheidend ist nur: Funktioniert es im Alltag? Diese Erfahrung zwingt einen dazu, sich weniger in die eigene Lösung zu verlieben und viel schneller bereit zu sein, sie zu verändern.

Dabei gilt natürlich weiterhin der wichtigste Einwand: You are not the user. Heavy Use darf nie bedeuten: „Ich finde es gut, also finden Nutzer es gut.“ Designer kennen das System besser, haben andere Ziele und andere Erfahrungen. Aber aus diesem Grundsatz sollte auch nicht die gegenteilige Schlussfolgerung entstehen, dass die eigene Nutzungserfahrung irrelevant sei. Wenn ich täglich merke, dass ein Vorgang langsam ist, ich ständig dieselben Daten eingeben muss oder eine häufige Aktion fünf Ebenen tief liegt, ist das zumindest ein Signal, das untersucht werden sollte.

Für mich entstehen die stärksten Produktentscheidungen deshalb aus drei Perspektiven, die zusammenkommen müssen:

• Was sagen Nutzer? Interviews, Support, Feedback und User Testing.
• Was tun Nutzer tatsächlich? Analytics, Funnels, Feature Usage, Search Logs und Session Recordings.
• Was erleben wir selbst? Heavy Use und die Qualität der täglichen Interaktion.

Keine dieser Perspektiven reicht allein. Wenn aber alle drei auf dasselbe Problem zeigen, wird es sehr interessant.

Noch eine These, die vielleicht nicht jedem gefällt: Viele Produkte brauchen weniger große UX-Redesigns und mehr permanente kleine Verbesserungen. Ein neues Design System, eine neue Navigation oder ein kompletter Relaunch lassen sich hervorragend präsentieren. Im Alltag entscheiden aber oft andere Dinge darüber, ob sich ein Produkt gut anfühlt: ein gespeicherter Filter, ein sinnvoller Default, eine vorausgefüllte Eingabe, ein Klick weniger, eine bessere Fehlermeldung oder eine Ladezeit, die von vier Sekunden auf eine Sekunde sinkt.

Wir überschätzen sichtbares Design und unterschätzen unsichtbare Produktqualität. Ein Schritt, der nicht mehr existiert, lässt sich schlecht in einem Portfolio zeigen. Ein automatisch ausgefülltes Feld sieht nicht spektakulär aus. Eine bessere Performance erzeugt keinen schönen Screenshot. Für Nutzer können genau diese Änderungen aber wertvoller sein als das nächste große Feature.

Mit der Zeit entsteht außerdem das, was ich UX Debt nennen würde. Ein zusätzlicher Klick hier, ein inkonsistenter Begriff dort, noch ein Dialog, noch ein Sonderfall, noch ein Tab. Keine einzelne Entscheidung ist katastrophal – aber tausend kleine Entscheidungen übereinander machen ein Produkt schwer. Heavy User spüren diesen Zustand sehr früh, weil sie ihn ständig erleben.

Das verändert auch Prioritäten. Roadmaps haben oft einen eingebauten Bias: Neu ist interessanter als verbessern. Neue Integration, neue AI-Funktion, neues Feature. Vielleicht wäre für den Nutzer aber wertvoller, wenn die bestehende Kernfunktion endlich richtig gut wäre. Gute Produktteams brauchen deshalb neben einer Feature Roadmap auch eine Art Reibungs-Roadmap: Welche kleinen Dinge kosten Nutzer jeden Tag Zeit, und welche davon können wir eliminieren?

Dazu gehören für mich auch Themen, die manchmal zu schnell als technische Details abgetan werden. Performance ist UX. Bei 300 Aktionen pro Tag spürt man jede zusätzliche Sekunde. Defaults sind UX. Welche Ansicht öffnet sich, welcher Filter ist vorausgewählt, was merkt sich das System und was kann es aus dem Kontext ableiten? Gerade durch Heavy Use entwickelt man ein Gefühl dafür, welche dieser unsichtbaren Details ein Produkt wirklich besser machen.

Ein Problem bleibt: Produktteams gewöhnen sich erstaunlich schnell an schlechte UX. Nach einiger Zeit kennen wir die versteckten Buttons, merkwürdigen Begriffe, Tastenkombinationen, Workarounds und Bugs so gut, dass sie uns kaum noch auffallen. Heavy Use sollte deshalb bewusst betrieben werden. Zwei Fragen helfen dabei: Wenn ich das heute zum ersten Mal sehen würde – würde ich es verstehen? Und genauso wichtig: Wenn ich das jeden Tag hundertmal machen müsste – würde ich es hassen?

Ich würde dafür sogar ein kleines Ritual im Produktteam etablieren: einen Heavy User Review. Kein dreistündiger Workshop und keine 80 Slides, sondern 30 Minuten alle ein oder zwei Wochen. Jeder bringt drei Beobachtungen aus der echten Nutzung mit – noch keine Lösungen, nur Reibung.

• „Ich musste dreimal denselben Filter setzen.“
• „Ich wusste nicht, ob gespeichert wurde.“
• „Der Dialog kam bei jedem Vorgang wieder.“
• „Ich musste eine Information in einem anderen System suchen.“
• „Für eine eigentlich einfache Aktion brauchte ich sechs Schritte.“
• „Die Suche funktioniert nur, wenn ich den Begriff exakt kenne.“

Solche Beobachtungen sind erstaunlich gute Ausgangspunkte für Produktverbesserungen. Sie erzeugen außerdem etwas, das sich schwer messen lässt, aber enorm wichtig ist: Produktgefühl. Wer ein Produkt hunderte Stunden benutzt, entwickelt ein Gespür dafür, was passt, was zu kompliziert ist, welche Information zu spät kommt oder welcher Schritt eigentlich nicht existieren sollte. Dieses Gefühl ersetzt keine Daten – aber es macht gute Hypothesen schneller möglich.

Figma ist ein hervorragendes Werkzeug. Aber vielleicht sollten UX Designer etwas weniger Zeit damit verbringen, perfekte Screens zu betrachten – und mehr Zeit damit, schlechte Prozesse zu erleben. Öffnet das echte Produkt. Loggt euch ein. Nutzt nicht nur den Happy Path. Sucht alte Daten, ändert Einstellungen, macht Fehler, springt zwischen Prozessen, benutzt das Produkt mobil, auf einem langsamen Gerät oder zehnmal hintereinander. Und schreibt auf, was euch dabei nervt.

Nicht, weil ihr dadurch plötzlich eure Nutzer ersetzt. Sondern weil ihr aufhört, euer Produkt nur von außen zu betrachten. Irgendwann kennt ihr dann nicht mehr nur Screens, Features und Roadmap, sondern auch die Reibung, Gewohnheiten, Schwächen, Abkürzungen und kleinen Zeitfresser. Genau dort entstehen meiner Erfahrung nach viele der besten UX-Verbesserungen.

UX Designer sollten ihr eigenes Produkt nicht nur designen. Sie sollten zu seinen intensivsten Nutzern gehören. Oder noch kürzer: Schließt Figma. Öffnet euer Produkt. Und benutzt es. Jeden Tag.