Ein Tag im Leben eines UX-Designers (B2B SaaS, IC-Edition)

Die Stellenbeschreibung versprach Ihnen, "schöne Erlebnisse zu gestalten und die Zukunft unseres Produkts zu prägen". Was Sie gestern tatsächlich getan haben: 90 Minuten mit einem Entwickler diskutiert, ob ein Bestätigungs-Modal einen sekundären Abbrechen-Button braucht, dann 40 Minuten einem Vertriebsmitarbeiter erklärt, warum "mach es knallig" kein Design-Briefing ist. Willkommen in der B2B-SaaS-UX.

Die Fantasie und die Realität sind verschiedene Jobs. Die Fantasie sind Dribbble-Shots, Moodboards und Beifall der Stakeholder. Die Realität sind Research-Notizen, Spec-Diskussionen und eine Figma-Datei mit 47 Frames namens "Frame 142", "Frame 143", "Frame 144". Beide Jobs sind real. Nur einer davon ist Ihrer.

So sieht ein normaler Wochentag für einen UX-Designer mit ein bis fünf Jahren Berufserfahrung aus. Kein Glamour. Keine Portfolio-Vorzeigeprojekte. Nur der tatsächliche Rhythmus der Arbeit, die Zeitfresser, vor denen Sie niemand warnt, und die kleinen Disziplinen, die darüber entscheiden, ob Sie müde-aber-zufrieden oder müde-und-frustriert nach Hause gehen.

8:02 Uhr: Figma und Slack Triage

Sie öffnen zuerst Figma. Drei Dateien haben Kommentare von über Nacht. Zwei von Entwicklern in einer anderen Zeitzone, einer von der PM, die abends arbeitet.

Sie öffnen Slack als zweites. Zwölf ungelesene Nachrichten in Ihren DMs und im #design-team-Kanal. Eine ist ein Vertriebsmitarbeiter mit einem Screenshot des Dashboards und den Worten "könnten wir das moderner wirken lassen". Eine ist eine Customer-Success-Person, die Sie in einem Thread über einen Kunden taggt, der den Export-Button nicht findet. Der Rest ist Rauschen.

Die Triage dauert zehn Minuten, wenn Sie es richtig machen. Drei Kategorien:

Entwicklung blockiert. Ein Entwickler steckt fest, weil ein Zustand in Ihrer Figma-Datei nicht spezifiziert ist. Das ist Ihr teuerster Interrupt, den Sie nicht aufschieben sollten. Wenn Sie drei Stunden warten, wechseln sie den Kontext zu etwas anderem, und Ihre Komponente wird eine Woche später geliefert. Antworten Sie jetzt in Figma-Kommentaren. Zwei-Satz-Antwort, Screenshot des Spec-Frames, Link zur Storybook-Komponente, falls vorhanden. Weitermachen.

"Mach es hübscher"-Anfragen. Der Vertriebsmitarbeiter möchte, dass das Dashboard "mehr knallt". Das ist eine echte Anfrage von einer echten Person, und sie verdient eine echte Antwort, aber sie verdient nicht Ihren Morgen. Antworten Sie in Slack: "Kommt auf das Backlog für visuelle Verbesserungen. Kurze Frage zuerst: Gibt es ein konkretes Gespräch, bei dem das Aussehen der entscheidende Faktor ist, oder ist das ein allgemeines Gefühl?" Neun von zehn Mal lautet die Antwort "allgemeines Gefühl" und die Anfrage erledigt sich still. Beim zehnten Mal ist es eine echte Kundeneskalation und Sie leiten es an Ihre Design-Leitung weiter.

Spec-Fragen. "Wie sieht dieser Zustand aus, wenn der Nutzer 0 Ergebnisse hat?" Das sind echte Fragen, die Ihre Zeit wert sind, aber sie brauchen keine synchrone Antwort. Merken Sie sie für den Async-Block um 10 Uhr vor.

Die Morgentriage ist nicht glamourös. Sie ist auch die einzige höchst effektive Zeit von 15 Minuten Ihres Tages. Designer, die sie überspringen, verbringen den Rest des Tages reaktiv. Designer, die sie gut machen, gestalten, wie ihr Tag aussieht.

10:00 Uhr: Asynchroner Spec-Block

Das ist der Teil des Jobs, den Ihnen in der Ausbildung niemand erklärt hat: Der Großteil Ihrer "Design"-Zeit ist Schreiben.

Sie öffnen Notion. Sie haben drei offene Spec-Fragen aus der Morgentriage. Jede braucht eine schriftliche Antwort, die die Diskussion beendet, nicht eine, die sie wieder eröffnet.

Schlechte Antwort: "Ich denke, es sollte wahrscheinlich eine Toast-Benachrichtigung sein, aber sagen Sie mir, was Sie denken." Das lädt zu einem sechseiligen Thread ein, weil Sie die Entscheidung zurück an den Entwickler delegiert haben.

Gute Antwort: "Toast-Benachrichtigung, oben rechts, 4-Sekunden-Auto-Dismiss. Nutzt die bestehende <Toast variant='success'>-Komponente in Storybook. Frame 47 in der Datei zeigt die Spec. Wenn die API länger als 8 Sekunden braucht, wechseln Sie zu einem dauerhaften Inline-Banner statt dem Toast (Frame 48 zeigt diese Variante). Linear-Ticket unten verlinkt."

Die gute Antwort braucht sechs Minuten zum Schreiben. Die schlechte Antwort dauert 30 Sekunden und kostet das Team über die nächsten zwei Tage eine Stunde. Das haben Sie auf die harte Tour gelernt.

Die Disziplin: Jede Spec-Antwort endet mit drei Dingen. Der Entscheidung, der Komponentenreferenz (Storybook-Link oder Figma-Frame-Nummer) und der Ticket-Rückverlinkung in Linear oder Jira. Keine Ausnahmen. Der Nachweispfad ist der springende Punkt. In sechs Monaten, wenn jemand fragt "warum haben wir es so gebaut", ist es der Pfad, der Sie davor bewahrt, die Entscheidung neu auszufechten.

Ihr Async-Block läuft von 10 bis 11:30 Uhr. Sie beantworten vier Spec-Threads, schreiben ein kurzes Notion-Dokument zu einer Pattern-Entscheidung und schließen zwei Figma-Kommentare, die eigentlich keine Antworten brauchten, weil der Entwickler es bereits durch Lesen der Datei herausgefunden hat. Diese letzte Kategorie ist ein stiller Gewinn. Sie bedeutet, dass Ihre Datei klar genug ist, um gelesen zu werden.

12:00 Uhr: Moderierter Usability-Test

Zuerst Mittagessen. Sie essen ein Sandwich an Ihrem Schreibtisch, weil der Test um 12:30 Uhr beginnt und Sie Ihren Testplan noch einmal durchlesen müssen. Ja, Sie sollten eine echte Mittagspause machen. Nein, das werden Sie nicht, nicht an Testtagen.

Der Test dauert 30 Minuten, moderiert, über Maze durchgeführt, mit einem echten Kunden: einem Abrechnungsleiter bei einem Logistikunternehmen mit 200 Mitarbeitern. Sie testen den neuen Rechnungsexport-Flow. Ihre Hypothese ist, dass der neue Flow die Zeit bis zum Export von 90 Sekunden auf unter 30 Sekunden reduziert. Ihre Nullhypothese ist, dass der neue Flow Nutzer auf eine Weise verwirrt, die der alte nicht getan hat.

Hier liegt der Fehler, den neue Designer machen. Sie achten nicht darauf, was der Nutzer sagt. Sie achten darauf, was er tut. Verbales Feedback ist meist Rauschen. Nutzer wollen hilfreich sein. Sie werden "das ist toll, sehr intuitiv" sagen, während ihr Mauszeiger neun Sekunden lang über dem falschen Button schwebt. Das Schweben ist das Datum. Das "sehr intuitiv" ist Höflichkeit.

Worauf Sie tatsächlich achten:

• Zögerlichkeit. Mauszeiger stoppt. Augen springen zu einem anderen Teil des Bildschirms. Der Nutzer liest ein Label erneut. Alles über zwei Sekunden Schweben-ohne-Klicken ist ein Signal.
• Falschklicks. Er klickt auf das Falsche, dann zurück, dann auf das Richtige. Der Falschklick ist das Signal, dass Ihre visuelle Hierarchie falsch priorisiert.
• Erneutes Lesen. Er liest ein Label, scrollt vorbei, scrollt dann zurück, um es erneut zu lesen. Dieses Label ist unklar. Ihre Aufgabe ist nicht, einen Tooltip hinzuzufügen. Ihre Aufgabe ist, das Label umzuschreiben.

Sie machen Notizen in einem dreierspaltigen Notion-Dokument: Zeitstempel, Beobachtung, Hypothese. Kein Kommentar, kein "ich glaube, das bedeutet". Nur was Sie gesehen haben und was es andeuten könnte. Die Synthese folgt später.

Ihr Notizensystem muss aufeinanderfolgende Sessions überstehen. Der Trick ist, eine einseitige Vorlage pro Studie mit vorab ausgefüllten Spalten zu verwenden und Screenshots nachher einzufügen, nicht während der Session. Wenn Sie während der Session Screenshots machen wollen, verpassen Sie das nächste Verhalten. Die Session hat Priorität. Das Artefakt kommt danach.

Der Abrechnungsleiter schließt die Exportaufgabe in 47 Sekunden ab. Besser als der alte Flow, schlechter als Ihre Hypothese. Er zögerte zweimal: einmal bei der Datumsbereichsauswahl (8 Sekunden), einmal bei der Dateiformat-Auswahl (5 Sekunden). Er sagte, die Erfahrung sei "viel besser als was wir jetzt haben", was real ist, aber nicht das Datum. Die beiden Zögerlichkeiten sind das Datum.

14:00 Uhr: Design Critique

45 Minuten mit zwei anderen Designern und Ihrer Design-Leitung. Drei Flows auf der Agenda, jeweils 15 Minuten. Sie präsentieren einen davon.

Die meisten Design Critiques scheitern auf dieselbe Weise: Sie werden zum Komitee-Design. Jemand sagt "was wäre, wenn wir Lila statt Blau probieren", jemand anderes sagt "was wäre, wenn das Modal von rechts hereingleitet", und 20 Minuten später hat der Raum einen Flow, der zu 80 % fertig war, in einen Flow umgestaltet, der jetzt zu 40 % fertig ist. Das ist ein bekanntes Versagensmuster. In Ihrem Kopf hat es einen Namen: die Fokusgruppen-Spirale.

So vermeiden Sie das. Wenn Sie einen Flow präsentieren, geben Sie vorab drei Dinge an:

1. Das Nutzerproblem. Nicht "wir überarbeiten den Export-Flow". Stattdessen: "Abrechnungsleiter bei mittelgroßen Kunden verbringen durchschnittlich 90 Sekunden mit dem Export einer Rechnung und teilen uns in Support-Tickets mit, dass es verwirrend ist."
2. Die Einschränkung. "Wir können den zugrundeliegenden API-Vertrag für zwei weitere Quartale nicht ändern."
3. Das spezifische Feedback, das Sie möchten. "Ich frage heute nicht nach visuellem Finish. Ich frage, ob dieser Flow den Mehrwährungsrand-Fall für unsere europäischen Kunden abdeckt."

Wenn Sie alle drei angeben, wird die Critique nützlich. Die Teilnehmer geben Ihnen Feedback zu dem, was Sie gefragt haben, nicht zu dem, was ihnen in den ersten 30 Sekunden aufgefallen ist.

Die zwei Arten von Critique-Feedback, die Sie tatsächlich wollen, klingen so. "Ich bin mit diesem Muster nicht einverstanden" ist eine Meinung, höflich anzuerkennen, aber berechtigt zu verwerfen. "Das wird für Enterprise-Admin-Nutzer nicht funktionieren, weil sie 200 gespeicherte Exporte haben und Ihre Dropdown-Liste nur 10 anzeigt" ist eine echte Critique. Die zweite Art ist Gold. Die erste ist Füllstoff. Behandeln Sie sie unterschiedlich.

Sie verlassen die Critique mit drei konkreten Änderungen am Flow, die vor dem Handoff vorzunehmen sind. Keine davon betrifft Farbe.

16:00 Uhr: Der Interrupt

Die PM schreibt Ihnen über Slack. "Hey, die Führungsebene möchte bis Freitag ein schnelles Redesign des Dashboards. Können Sie das morgen anpacken?" Es ist Mittwoch, 16:07 Uhr.

Das ist der Moment, der entscheidet, ob Sie zum Pixel-Lieferdienst des Teams werden oder Designer bleiben.

Die falsche Reaktion ist "klar, ich kümmere mich darum". Die falsche Reaktion fühlt sich gut an, weil Sie hilfreich sind. Sie ist die falsche Reaktion, weil Sie bis Freitag einen halbfertigen Dashboard-Entwurf, zwei übersprungene Usability-Sessions und ein Handoff-Dokument haben, das Sie für die Arbeit nicht geschrieben haben, zu der Sie sich letzte Woche verpflichtet haben.

Die richtige Reaktion ist eine Frage, kein Ja. "Ich schaue es mir gerne an. Können Sie mir sagen, was sich im Roadmap geändert hat, dass das ein Freitags-Thema ist, und was 'Redesign' hier bedeutet: visuelles Auffrischen des bestehenden Layouts oder umstrukturierte Informationsarchitektur? Das sind sehr unterschiedliche Aufgaben." Sie senden es in 90 Sekunden. Sie gehen zurück zu Ihrer Handoff-Vorbereitung.

Die Hälfte der Zeit zeigt die Frage, dass "Redesign" die Diagrammfarben ändern bedeutete, und eine andere Person im Team kann das erledigen. Ein Viertel der Zeit zeigt sich, dass die Anfrage real ist, die Deadline aber nicht. Das verbleibende Viertel ist ein echter Notfall, und Sie verschieben etwas aus Ihrer Woche, um ihn zu bearbeiten. Die PM respektiert Sie mehr für die Frage als für das reflexartige Ja.

17:00 Uhr: Handoff-Vorbereitung

Die letzten 30 Minuten. Das ist der Teil des Tages, bei dem die meisten Designer Abkürzungen nehmen, und beim nächsten Morgen die meisten Entwickler-Slacks ankommen mit "was meinten Sie damit?"

Die Handoff-Disziplin ist 20 Minuten Arbeit, die 90 Minuten Pings am nächsten Tag verhindert. Es ist die billigste Absicherung, die Sie je kaufen werden.

Sie räumen die Figma-Datei auf. Frames mit Absicht benannt: "Export-Flow / Schritt 2 / Mehrwährungsvariante". Ebenen gruppiert. Versteckte Frames gelöscht. Komponenten verlinkt, nicht getrennt.

Sie schreiben die einseitige Notion-Spec. Fünf Abschnitte, nicht mehr. Problem (ein Satz). Lösung (drei Sätze). Zustände und Randfälle (eine Liste). Komponentenreferenzen (Storybook-Links, Figma-Frame-Nummern). Offene Fragen (die Dinge, die Sie und der Entwickler noch entscheiden müssen).

Sie hängen das Notion-Dokument an das Linear-Ticket. Sie hinterlegen den Storybook-Link im Ticket-Kommentar. Sie taggen den Entwickler.

Sie schließen den Laptop um 17:32 Uhr.

Was die Stellenbeschreibung Ihnen nicht sagt

Die Hälfte dieses Jobs ist Research und Schreiben. Vielleicht mehr als die Hälfte. Der Figma-Teil (der in der Stellenbeschreibung als "schöne Erlebnisse gestalten" beschrieben wird) ist tatsächlich der kleinste Teil Ihrer Woche. Die meisten Wochen liegt er irgendwo zwischen 25 % und 35 % Ihrer Zeit. Den Rest verbringen Sie damit, mit Nutzern zu sprechen, mit Entwicklern zu sprechen, Specs zu schreiben, in Critiques zu sitzen und Interrupts zu triagieren.

Die Designer, die beim B2B SaaS ausbrennen, kamen mit der Erwartung von Dribbble. Sie wollten Screens erstellen. Sie bekamen einen Job, der hauptsächlich aus Gesprächen und Texten über Screens besteht. Der Mismatch reibt sie auf.

Die Designer, die aufblühen, behandeln Figma als Denkwerkzeug, nicht als Portfolio. Ihre Dateien sind in der Mitte chaotisch und am Ende ordentlich. Ihr Notion ist voller einseitiger Spec-Dokumente, die sonst niemand liest, die sie aber jedes Mal retten, wenn jemand fragt "warum haben wir es so ausgeliefert". Sie schreiben mehr als sie gestalten, und sie sind damit im Reinen, weil das Schreiben das ist, was das Gestalten zum Tragen bringt.

Der "Mach es hübscher"-Interrupt, die Fokusgruppen-Spirale, die Pixel-Lieferdienst-Falle: All das hat Namen, weil es Muster sind, kein Pech. Sobald Sie sie benennen, erkennen Sie sie in den ersten fünf Minuten. Das ist die Fähigkeit, die Ihnen in der Ausbildung niemand beibringt und die in keiner Stellenbeschreibung steht.

Sie sind nicht in diesem Job, um Screens zu erstellen. Sie sind darin, Entscheidungen über Screens zu treffen, diese schriftlich zu verteidigen und sie auf eine Weise auszuliefern, die den nächsten Roadmap-Wechsel übersteht. Die Screens sind das Artefakt. Die Entscheidungen sind die Arbeit.

Morgen sieht ungefähr so aus wie heute. Die Triage, der Async-Block, die Nutzersession, die Critique, der Interrupt, der Handoff. Andere Dateien, gleiche Form. Die Form ist der Job.

Weiterführende Inhalte

• Product Designer Job Description Template: das zugehörige Stellenprofil zu diesem Leitfaden
• Ihre ersten 30/60/90 Tage als neuer UX-Designer
• User Research, das den Roadmap bewegt
• Wireframing und Prototyping, das Engineering übersteht
• Häufige Fehler von UX-Designern