Deutsch

Ein Tag im Leben eines Product Designers (B2B SaaS Realität, nicht die LinkedIn-Version)

Die Stellenbeschreibung sagt "End-to-End-Verantwortung für Produktdesign übernehmen". Der Kalender des Dienstags sagt drei Meetings, neunzig Minuten echte Figma-Zeit und ein Exec-Slack-Drop um 16:47 Uhr, der fragt, warum Ihr Produkt noch nicht wie Linear aussieht.

Diese Lücke ist der Job. Kein Fehler im System. Der Job.

Wenn Sie die Product Designer Job Description Template gelesen und sich einen Tag voller konzentrierter Handwerksarbeit vorgestellt haben, ist dieser Artikel die Kalibrierung. Ein echter Dienstag für einen Mid-Level-IC-Designer bei einem 60-köpfigen B2B-SaaS-Unternehmen, mit Kalender, Slack-Threads und den kleinen politischen Auseinandersetzungen, die mehr Energie kosten als Ihnen irgendjemand im Interview sagt.

Warum das jetzt relevant ist

Designer kündigen in den ersten sechs Monaten. Nicht weil sie nicht designen können. Sondern weil sie mit der Erwartung ankommen, 70% Handwerk zu bekommen, und stattdessen so etwas wie 30% Handwerk, 40% Abstimmung und 30% Schadensbegrenzung erleben.

Niemand sagt Ihnen das im Interview, weil der Hiring Manager Sie nicht abschrecken will und die Kollegen nicht zugeben wollen, wie viele ihrer Wochen aus Meetings bestehen. Also stoßen Sie dazu, verbringen drei Wochen damit, zu beobachten wie Senior Designer die meiste Zeit in Slack und Linear verbringen, und fragen sich, ob Sie den falschen Job angenommen haben.

Haben Sie nicht. Die Aufteilung ist einfach die Aufteilung. Sie beim Namen zu nennen macht sie erträglich.

Also hier ist ein echter Tag. Nicht die Höhepunkte. Die echten Stunden.

Ein echter Tag

8:00 Uhr: Kundengesprächs-Review

Kaffee, Kopfhörer, Gong-Tab offen. Das gestrige Onboarding-Gespräch mit dem neuen Kunden aus dem Home-Services-Bereich dauerte 47 Minuten. Sie brauchen nur 22 davon, den Teil, wo die Administratorin versucht hat, 80 Deals auf einmal zu bearbeiten, und aufgegeben hat.

Sie schauen bei 1,5-facher Geschwindigkeit. Sie markieren vier Reibungsmomente in Notion unter dem Tag "bulk-edit-Schmerz". Ein Zitat hält Sie inne: "Ich habe einfach in eine Tabellenkalkulation exportiert und wieder importiert, weil das schneller war." Dieser eine Satz zerstört die Annahme hinter dem Spec des nächsten Sprints, das Bulk-Editing immer noch als "Nice-to-have" führt. Es ist kein Nice-to-have. Es ist der Grund, warum dieser Kunde im vierten Monat abspringen wird, wenn niemand etwas dagegen tut.

Sie fügen den Gong-Link mit Zeitstempel plus das Zitat in das Discovery-Dokument ein. Zwölf Minuten gesamt. Die besten zwölf Minuten des ganzen Tages.

9:30 Uhr: Discovery-Arbeit und Skizzen

Maze-Ergebnisse vom unmoderierten Test des Freitags landen in Ihrem Posteingang. 14 von 20 Testern konnten die Sekundäraktion auf der Deal-Karte nicht finden. Die Heatmap ist brutal. Alle hovern über dem falschen Button.

Sie öffnen Figma, neue Datei, und skizzieren drei Richtungen für den Bulk-Edit-Flow. Keine Pixel. Keine Typografie. Nur graue Rechtecke und Pfeile. Richtung A ist ein Checkbox-und-Toolbar-Muster (vertraut, langweilig, sicher). Richtung B ist ein Seitenpanel, das sich bei Auswahl öffnet (mehr Platz, mehr Klicks). Richtung C ist direktes Bearbeiten in der Tabelle selbst (weniger Klicks, schwieriger zu bauen, Engineering wird sich beschweren).

Neunzig Minuten. Drei Skizzen. Null Pixel. Sie haben noch nichts designt, das irgendjemand "Design" nennen würde, und das ist in Ordnung. Die Skizzen sind das Design. Die Pixel kommen später, und nur für die eine Richtung, die die nächsten vier Stunden überlebt.

11:30 Uhr: Async mit PM und Engineering zu Kompromissen

Linear-Thread zum Spec. Der Engineering-Lead schreibt: "Richtung C bedeutet, dass wir drei Komponenten in Storybook aktualisieren und wahrscheinlich die Tabellen-Virtualisierungsschicht anfassen müssen. Das ist zwei Sprints, nicht einer." PM schreibt zurück: "Können wir Richtung A diesen Sprint liefern und C nächstes Quartal nochmal anschauen?"

Das ist der Moment, wo Sie entweder nachgeben oder widersprechen. Sie widersprechen. Sie fügen den Gong-Link aus 8 Uhr in den Thread ein mit dem Zitat und einer Zeile: "Richtung A behebt das Export-und-Reimport-Verhalten nicht. Wir werden dieses Kundenprofil weiter verlieren, wenn wir A liefern und es dabei belassen."

Sie bekommen kein Ja. Sie bekommen "Lass uns das in der Critique um 13:30 Uhr besprechen." Das ist das richtige Ergebnis. Sie haben das Gespräch erkauft. Das ist der Gewinn.

Währenddessen antworten Sie auf zwei andere Linear-Kommentare, markieren ein Ticket als "braucht Spec" und schreiben einen vierzeiligen Kommentar zum Empty-State-Mock eines Kollegen, der sagt, er sei schön, aber die Texte machen zu viel Arbeit. Sie bekommen ein Daumen-hoch-Emoji zurück. Async von seiner besten Seite.

13:30 Uhr: Design-Critique

Fünfundvierzig Minuten mit zwei anderen Designern. Sie pinnen die drei Richtungen, gehen durch das Kundenzitat zuerst (immer mit dem Kunden starten, nie mit dem Design), und zeigen dann die Skizzen.

Richtung A wird als auslieferbar gelobt. Richtung C wird dafür gelobt, das Problem wirklich zu lösen. Richtung B wird auseinandergenommen, was fair ist: Sie wussten, dass es die schwächste war. Dann fragt ein Senior Designer: "Wie sieht der Empty State in C aus? Wenn der Nutzer keine Deals ausgewählt hat, wird die Inline-Bearbeitungs-Affordance kaputt aussehen."

Sie haben keine Antwort. Sie haben eine Skizze des befüllten Zustands und eine vage Handbewegung für leer. Das ist die Lücke. Critique hat Ihre Richtung nicht getötet. Es hat das Loch gefunden, in das Sie nächste Woche gefallen wären, und jetzt können Sie es flicken, bevor Sie drei Tage in hochauflösende Designs investieren.

Sie verlassen das Meeting mit Richtung C am Leben, Richtung A tot und einer klaren Aufgabe: Lösen Sie den Empty State, bevor Sie irgendetwas in Produktionsqualität bauen.

15:00 Uhr: Hochauflösiges Figma und Storybook-Prüfung

Neunzig Minuten echtes Figma. Das Fenster zwischen Critique und der unvermeidlichen Unterbrechung am Tagesende. Sie bringen Richtung C für zwei Screens in Produktionsqualität: den befüllten Zustand mit drei ausgewählten Deals und den Empty State, den Sie soeben als fehlend erkannt haben.

Sie prüfen gegen die design system-Tokens. Zwei Farben stehen nicht auf der Token-Liste. Ein Abstandswert weicht um 4px ab. Sie korrigieren beides. Sie öffnen Storybook, prüfen die bestehende Tabellenzeilen-Komponente und bestätigen, dass das Inline-Bearbeitungsmuster eine neue Variante braucht. Sie erstellen ein Storybook-Ticket in Linear, taggen den design system-Maintainer und verlinken zurück auf den Spec.

Das ist der Teil des Tages, der sich anfühlt wie der Job aus dem Interview. Er ist auch der kürzeste Abschnitt. Beachten Sie, dass es neunzig Minuten sind, keine sechs Stunden.

16:47 Uhr: Die Exec-Unterbrechung

Die Slack-DM kommt an. "Habe gesehen, dass [Wettbewerber] gerade sein neues Dashboard geliefert hat. Sieht wirklich sauber aus. Können wir das für unsere App anschauen? Kunden fragen immer wieder danach."

Der Reflex wäre, entweder (a) Ja zu sagen und in Panik zu geraten, oder (b) Nein zu sagen und defensiv zu wirken. Beides ist falsch.

Sie schreiben drei Sätze:

Hier ist der Link zum Discovery-Dokument. Bulk-Edit ist der größte Reibungspunkt dieses Quartals, und wir liefern die Lösung in zwei Sprints. Ich mache gerne separat ein kurzes Design-Review zum Dashboard, würde aber vorschlagen, Dashboard-Arbeit im Q3-Plan zu lassen, da wir Kundendaten haben, die den aktuellen Sprint stützen. Soll ich 15 Minuten für morgen aufsetzen, damit ich Sie durch die Bulk-Edit-Research führen kann?

Sie fügen das Notion-Discovery-Dokument mit dem Kundenzitat und den vier zeitgestempelten Gong-Momenten bei. Sie senden.

Der Exec liest es. Drei Minuten später: "Verstanden, macht Sinn. Machen wir die 15 Minuten morgen."

Sie haben den Termin zurückgewonnen. Ohne Nein zu sagen. Indem Sie Ihre Arbeit gezeigt haben, was ehrlich gesagt der einzige Schritt ist, der bei Führungskräften je funktioniert. Meinung gegen Meinung ist ein Münzwurf. Belege gegen Meinung gewinnen fast immer, weil die Führungskraft eigentlich nicht falsch liegen will, sondern nur gehört werden will.

17:30 Uhr: Tagesabschluss-Handoff

Linear-Update. Vier Zeilen. Das ist die Vorlage, die Sie jeden Tag nutzen:

Was heute geliefert wurde: Richtung C Hochauflösung für Bulk-Edit (befüllt + leer)
Was blockiert: Storybook-Variante für Inline-Edit-Tabellenzeile (eingereicht, wartet auf design system-Review)
Was als nächstes kommt: Edge Cases für >100 Ausgewählte, Fehlerzustände, Tastaturnavigation
Was morgen getestet wird: Discovery-Gespräch mit [Kundenname]: Stimmt Richtung C mit dem Export-Import-Workaround überein?

Taggen Sie den Engineering-Lead auf den Figma-Frames. Legen Sie den Spec-Link im Team-Channel ab. Fügen Sie die Maze-Test-ID für den nächsten Freitag hinzu. Laptop zu.

Gesamte Figma-Zeit heute: ungefähr 110 Minuten in einem 8-Stunden-Tag. Das sind etwa 23% Ihrer Zeit auf dem, was die meisten Nicht-Designer als den ganzen Job betrachten.

Die anderen 77% waren Kundenbelege, Abstimmung, Verteidigung und Handoff. Das ist der Job. Die 23% ernten nur den Ruhm auf Dribbble.

Die Realitätschecks

Die Deadline-Druck-Realität des PM

PMs drücken auf Deadlines, weil das ihr Job ist. Sie sind nicht der Feind. Aber wenn Sie jedes Mal nachgeben, wenn der PM die kleinere Version ausliefern will, werden Sie zu "dem Designer, der mit dem PM übereinstimmt", was sich etwa sechs Monate lang wie ein Kompliment anhört und dann wird Ihnen klar, dass Sie aufgehört haben zu designen und angefangen haben zu dekorieren.

Der richtige Schritt ist nicht, jede Auseinandersetzung zu suchen. Der Schritt ist, sich die Auseinandersetzungen auszusuchen, bei denen Sie Kundenbelege haben und diese entschlossen zu führen, und bei denen, wo Sie das nicht haben, nachzugeben. Das Bulk-Edit heute war eine Auseinandersetzung mit Kundenbelegen. Es war es wert. Die Empty-State-Texte, über die Sie an einem anderen Tag streiten würden? Wahrscheinlich nicht. Wählen Sie Ihre Schlachten.

Die Wettbewerber-Redesign-Unterbrechung

Führungskräfte sehen einen Wettbewerber etwas Glänzendes liefern und geraten in Panik. Immer. Die Antwort ist fast nie "Ja, lass uns redesignen." Die Antwort folgt dem Drei-Satz-Muster von 16:47 Uhr:

  1. Mit Belegen bestätigen: "Hier ist, woran wir arbeiten und welche Kundendaten dahinter stehen."
  2. Kleinere Verpflichtung anbieten: "Ich mache gerne ein 15-Minuten-Review separat."
  3. Timing umrahmen: "Lass uns das in die Q3-Diskussion einbringen, nicht in diesen Sprint."

Die Antwort funktioniert, weil sie der Führungskraft etwas gibt (ein Meeting, eine Anerkennung) ohne ihr das zu geben, worum sie gebeten hat (ein Redesign). Sie nehmen fast immer den Trostpreis, weil sie eigentlich nur das Gefühl haben wollten, aufzupassen.

Die "Ich bin nur ein Figma-Dekorateur"-Diagnose

Hier ist der Selbstcheck, führen Sie ihn jeden Freitag durch:

Wann habe ich zuletzt mit einem Kunden gesprochen? Einen echten Anruf angehört? Ein Support-Ticket gelesen?

Wenn die Antwort mehr als 10 Tage ist, sind Sie Dekorateur, kein Designer. Sie verschieben Pixel ohne Grundwahrheit, was bedeutet, dass Ihre Designentscheidungen aus ästhetischen Vorlieben und dem letzten Dribbble-Shot kommen, den Sie gesehen haben. Das ist in Ordnung für Hobbyprojekte und fatal für das Ausliefern von Software, für die Menschen bezahlen.

Der Fix: buchen Sie diese Woche ein Kundengespräch. Kein Research-Gespräch mit einem PM-Skript. Ein echtes Gespräch. Schauen Sie es auf Gong an, wenn Sie nicht in den Kalender kommen. Zweiundzwanzig Minuten reichen, um Ihren Blick zurückzusetzen.

Der Stack (benannt, mit dem echten Job)

Die Tools, die jeder IC Designer bei einem B2B-SaaS-Unternehmen 2026 nutzt, und was jedes einzelne davon im täglichen Ablauf wirklich leistet:

  • Figma: Exploration, Critique-Pinning, Produktions-Handoff. Die ganze Strecke von der Skizze bis zur Auslieferung lebt hier. Zahlen Sie erst für Plugins, wenn Sie sechs Monate lang die nativen Multi-Edit- und Auto-Layout-Funktionen genutzt haben.
  • Maze (oder UserTesting): Unmoderierte Tests im wöchentlichen Rhythmus. 20 Tester, 4 Fragen, 48-Stunden-Turnaround. Die günstige, schnelle Feedback-Schleife, die 14-von-20-Probleme abfängt, bevor sie in die Entwicklung gelangen.
  • Notion: Discovery-Dokumente, Kundenzitat-Bibliothek, Design-Prinzipien. Nach Funktionsbereich getaggt, nicht nach Datum. Die Zitatbibliothek ist der Ort, wo das Zitat von 8 Uhr über das Exportieren in eine Tabellenkalkulation jetzt lebt, bereit für das nächste Argument.
  • Storybook: Die design system-Wahrheitsquelle. Neue Komponenten landen hier, nicht in Ihrer Figma-Datei. Wenn Ihr Team Figma als Wahrheitsquelle behandelt, ist Ihr design system kaputt: die Wahrheitsquelle muss das sein, was Engineering tatsächlich ausliefert.
  • Linear: Spec, Tickets, Engineering-Handoff, Status. Jeder Spec verlinkt einen Figma-Frame, ein Notion-Dokument und ein Kundenzitat. Wenn ein Linear-Ticket keines dieser drei hat, ist es nicht bereit zum Bauen.

Die Kombination zählt mehr als jedes einzelne Tool. Figma ohne Notion ist Dekoration. Notion ohne Linear ist Theater. Linear ohne Maze ist Raten. Der gesamte Stack ist eine geschlossene Schleife vom Kundensignal zum ausgelieferten Feature, und der Job des Designers ist, diese Schleife eng zu halten.

Vorlagen und Tools

Der vierzeilige Tagesabschluss-Handoff

Was heute geliefert wurde:
Was blockiert:
Was als nächstes kommt:
Was morgen getestet wird:

Tragen Sie es täglich um 17:30 Uhr in Linear ein. Engineering weiß am Morgen, was sie erhalten. PM weiß, was gefährdet ist. Sie hören auf, "Wo stehen wir dabei?"-Slacks um 9 Uhr morgens zu bekommen.

Das Exec-Unterbrechungs-Antwortskript

Drei Sätze. Immer in dieser Reihenfolge: mit Belegen bestätigen, kleinere Verpflichtung anbieten, Timing umrahmen. Passen Sie die Formulierung an, nie die Struktur. Die Struktur ist das, was die Panik entschärft.

Der wöchentliche "Bin ich ein Dekorateur?"-Selbstcheck

Jeden Freitag, zwei Fragen:

  1. Wann habe ich zuletzt einen echten Kundenanruf angehört oder ein echtes Support-Ticket gelesen?
  2. Welche dieser Woche getroffenen Entscheidungen basierten auf Kundenbelegen gegenüber meinem Geschmack?

Wenn Frage 1 mehr als 10 Tage ist, korrigieren Sie es am Montag. Wenn Frage 2 mehr Geschmack als Belege zeigt, driften Sie ab.

Das Notion-Kundenzitat-Tagging-Schema

Jedes Zitat, das Sie speichern, braucht drei Tags: Funktionsbereich (bulk-edit, onboarding, dashboard), Schmerztyp (workaround, dropoff, confusion, delight) und Kundensegment (smb, mid-market, enterprise). Wenn Sie um 16:47 Uhr ein Zitat für eine Exec-Unterbrechung brauchen, können Sie es in fünfzehn Sekunden abrufen. Ohne Tags scrollen Sie.

Einen guten Tag messen

Nicht jeder Tag liefert Pixel. Wie wissen Sie also, ob es ein guter Tag war? Vier Signale:

  1. Ein echtes Kundensignal protokolliert. Ein Zitat, ein Gong-Zeitstempel, ein notiertes Support-Ticket. Eines. Pro Tag. Das ist alles.
  2. Ein Kompromiss mit Belegen verteidigt, nicht mit Meinung. Selbst wenn Sie die Auseinandersetzung verloren haben, ist die Verteidigung selbst der Gewinn, weil sie Engineering und PM beweist, dass Design keine ästhetische Vorliebe ist, sondern eine Disziplin.
  3. Ein Figma-Frame näher am Ausliefern als gestern. Muss nicht fertig sein. Muss weiter sein als zuvor.
  4. Null Slack-Nachrichten, die Sie bereuen, an den Exec geschickt zu haben. Das klingt wie ein Witz. Ist es nicht.

Wenn Sie alle vier treffen, war heute ein guter Tag, auch wenn die LinkedIn-Version Ihres Jobs das "langweilig" nennen würde. LinkedIn bezahlt Sie nicht. Ihre Kunden schon.

Mehr erfahren