Ihre ersten 30/60/90 Tage als neuer UX-Designer

Tag 1. Sie melden sich bei Figma an, öffnen den Team-Workspace und finden eine Datei mit dem Titel "ALT-NICHT-VERWENDEN-final-v4" mit 47 ungelesenen Kommentaren. Drei weitere Figma-Bibliotheken sind an der Spitze des Workspace angepinnt: v2, v2.1 und v3-WIP. Keine davon entspricht dem, was Sie gerade in der Produktion gesehen haben. Ihre PM schickt Ihnen eine Kalendereinladung für "Design-Review" morgen um 10 Uhr. Es gibt keine Agenda.

Willkommen bei UX im B2B SaaS.

Dieser Leitfaden ergänzt das Product Designer Job Description Template. Die Stellenbeschreibung beschreibt, was Sie eingestellt wurden zu tun, und das hier ist, wie die eigentliche Arbeit aussieht. Wenn Sie das lesen, bevor Sie anfangen, drucken Sie es aus. Wenn Sie es drei Wochen nach dem Start lesen, liegen Sie nicht im Rückstand. Die meisten neuen UX-Designer haben keinen 90-Tage-Plan, weshalb die Organisation ihnen einen geben wird, ob sie wollen oder nicht.

Warum ein schriftlicher 30/60/90-Plan für Designer wichtig ist

Engineering hat Standups. PMs haben Roadmaps und Sprint-Planung. Sales hat eine Zahl. Designer haben... ein Gefühl? Ein monatliches Design-Crit, wenn jemand daran denkt, es zu buchen?

Ohne einen schriftlichen Plan werden Ihre ersten 90 Tage zu dem, was Ihr lautester Stakeholder gerade in dieser Woche braucht. Eine PM bucht 30 Minuten vor der Sprint-Planung eine "schnelle Design-Review" und verlässt den Raum mit Mockups. Ein Entwickler pingt Sie wegen eines Hex-Codes und Sie verbringen 40 Minuten in Figma. Drei Monate später haben Sie 60 kleine visuelle Korrekturen geliefert und null strategische Arbeit, und Ihre Führungskraft fragt nach Ihrem Impact.

Ein schriftlicher 30/60/90-Plan ist Ihre beste Verteidigung gegen Scope Creep, "mach das hübscher"-Interrupts und die Behandlung als Photoshop-auf-Abruf. Er gibt Ihnen auch etwas, auf das Sie in Woche 4 zeigen können, wenn jemand fragt, warum Sie das Dashboard noch nicht redesignt haben.

Der folgende Plan geht davon aus, dass Sie eine Mid-Level-UX-Einstellung sind (2 bis 5 Jahre Erfahrung), Individual Contributor, und einem B2B-SaaS-Unternehmen irgendwo zwischen Series A und börsennotiert beitreten. Sie wurden für echte Produktarbeit eingestellt. Nicht für das Redesign der Marketing-Website. Nicht für ein "Brand-Refresh".

Tage 1 bis 30: Prüfen, nicht liefern

Der größte Fehler, den neue UX-Designer machen, ist es, in Woche 2 etwas Sichtbares zu liefern. Das Dashboard-Redesign. Den "modernisierten" Empty State. Die neuen Farb-Tokens. Es fühlt sich produktiv an. Es sieht nach Fortschritt aus. Sechs Monate später ist es auch der Grund, warum Sie still herausgemanagt werden, weil niemand die User Research findet, die es rechtfertigte, und die Entwickler, die drei Komponenten in einem engen Sprint neu gebaut haben, sind nicht mehr Ihre Freunde.

In Monat 1 haben Sie nicht den Kontext, um etwas tatsächlich Richtiges zu liefern. Also tun Sie es nicht.

Das Design-System prüfen

Öffnen Sie jede Figma-Datei im Workspace. Jede einzelne. Machen Sie eine Liste. Notieren Sie für jede Datei: wann wurde sie zuletzt bearbeitet, wer hat sie zuletzt bearbeitet, ist sie mit einer aktiven Spec verlinkt, benutzt jemand im Team sie gerade.

Vergleichen Sie nun, was in Figma ist, mit dem, was in der Produktion ist. Öffnen Sie die Live-App. Inspizieren Sie einen Button. Vergleichen Sie ihn mit der Button-Komponente in v2, v2.1 und v3-WIP. Sie werden Drift finden. Drei oder vier Pixel Padding hier, ein anderer Border-Radius dort, ein Hover-Zustand, der in Figma existiert, aber nicht im Code. Katalogisieren Sie das.

Ergebnis: ein einseitiges "Design-System-Realitäts-Check"-Dokument. Komponentenname, Figma-Version, in der sie lebt, Produktionsversion, Drift-Zusammenfassung, Eigentümer-Unklarheit. Schlagen Sie noch keine Fixes vor. Dokumentieren Sie nur. Dieses Dokument wird das Artefakt, das belegt, dass Sie das Durcheinander verstanden haben, bevor Sie versucht haben, es aufzuräumen, und es stützt den Fall für Design-System-Investitionen, wenn am Ende von Q1 Budgetgespräche stattfinden.

An 5 User-Research-Calls teilnehmen

Wenn es eine aktive Research-Funktion gibt, bitten Sie die Researcherin, Sie als stillen Beobachter zu anstehenden Sessions hinzuzufügen. Wenn es keine gibt (und bei den meisten B2B-SaaS-Unternehmen mit unter 200 Mitarbeitern gibt es keine), werden Sie kreativ.

Bitten Sie Sales, Ihnen 5 aufgezeichnete Discovery-Calls weiterzuleiten. Bitten Sie Support um die 10 meistgeklickten Session-Recordings in FullStory oder Hotjar. Nehmen Sie an 2 Onboarding-Calls mit neuen Kunden teil. Hören Sie sich 2 Kündigungs-Calls an, wenn Sie das verkraften.

Sie suchen keine "Erkenntnisse" im Sinne von Präsentationsfolien. Sie lernen die Sprache. Wie beschreiben Nutzer das Produkt? Wie nennen sie die Funktionen? Welche Wörter tauchen immer wieder auf, wenn sie frustriert sind? Notieren Sie Sprache, nicht nur Schmerzpunkte. Das Vokabular, das Sie in Woche 2 aufnehmen, erspart Ihnen 100 Stunden Microcopy-Überarbeitung in Monat 6.

Den Design-zu-Engineering-Fluss kartieren

Setzen Sie sich mit einem Entwickler zusammen, der kürzlich eine UI-Änderung geliefert hat. Bitten Sie ihn, Sie vollständig durch den Prozess zu führen: den Figma-Frame, wo die Spec lag, woher die Design-Tokens kamen, wie er Padding und Farbe in Code übersetzt hat, wonach er den vorherigen Designer fragen musste, was er sich selbst ausdenken musste.

Zeichnen Sie das nun auf einer Seite. Designer, Figma-Frame, Spec-Dokument (wo?), Tokens (wo?), Entwickler, Storybook (existiert es? ist es aktuell?), Produktion.

Sie werden mindestens drei Stellen finden, an denen der Handoff gebrochen ist. Die Tokens liegen in drei verschiedenen Quellen der Wahrheit. Das Storybook wurde seit 11 Monaten nicht mehr aktualisiert. Specs liegen je nach Autor in Notion, Confluence und Figma-Kommentaren. Dokumentieren Sie das. Es ist das zweite Beweisartefakt für Ihren 90-Tage-Bericht.

Die 3 wichtigsten UX-Debt-Punkte identifizieren

Nicht "die Homepage wirkt veraltet". Echte Reibungspunkte. Die Art, die das Unternehmen Geld kostet oder Support-Budget verbrennt.

Beispiele, die zählen:

• Filter verlieren den Zustand beim Seiten-Reload, sodass Nutzer ihre Arbeit jedes Mal wiederholen müssen, wenn sie navigieren.
• Das Onboarding hat 4 Sackgassen-Zustände, in denen Nutzer gegen eine Wand stoßen, ohne einen Ausweg.
• Die Sammelaktions-Leiste überdeckt die Tabellen-Footer-Paginierung, sodass Nutzer nicht sehen können, dass sie Elemente jenseits von Seite 1 ausgewählt haben.

Beispiele, die nicht zählen:

• "Die Buttons sehen alt aus."
• "Die Icons sind inkonsistent."
• "Es fühlt sich nicht modern an."

Gelangen Sie zu Ihren Top 3 durch Triangulierung: Support-Ticket-Volumen, NPS-Verbatims, Einwände aus dem Vertrieb und die User-Calls, an denen Sie teilgenommen haben. Schreiben Sie jeden als: beobachtetes Verhalten, Beweise (Ticket-Anzahl, Call-Zitate, Session-Replay), geschäftlicher Impact. Diese drei Punkte werden Ihre 60- und 90-Tage-Belege.

Das Eine, was Sie in den Tagen 1 bis 30 nicht tun

Liefern.

Widerstehen Sie jeder Anfrage, in Ihrem ersten Monat ein sichtbares Artefakt abzugeben. Widerstehen Sie dem "schnellen Gewinn". Widerstehen Sie dem Redesign. Widerstehen Sie dem Brand-Refresh. Neue Designer, die in Woche 2 etwas Hochsichtbares liefern, sind dieselben, deren Arbeit in Monat 6 still rückgängig gemacht wird, weil sie nicht den Kontext hatten, um richtig zu liegen.

Wenn eine PM drängt, lautet die Antwort: "Ich möchte, dass meine erste gelieferte Änderung eine ist, die ich mit Daten verteidigen kann. Das werde ich in 4 bis 6 Wochen haben." Die meisten vernünftigen PMs werden das respektieren. Die unvernünftigen sagen Ihnen damit etwas Nützliches über das Team.

Tage 31 bis 60: Laufen, beitragen, klein liefern

Jetzt haben Sie Kontext. Zeit, ihn in Belege und gelieferte Arbeit umzuwandeln, aber klein, begrenzt, verteidigbar.

1 Usability-Test durchführen

Nehmen Sie einen Ihrer 3 UX-Debt-Punkte. Führen Sie einen Usability-Test damit durch. Fünf Nutzer. Unmoderiert ist in Ordnung. Maze oder UserTesting liefern Ihnen Daten innerhalb einer Woche für unter 200 Dollar. Wenn Sie eine Research-Funktion haben, bitten Sie um Hilfe bei der Moderation einer Session als Co-Pilot. Wenn nicht, schlägt Maze mit 5 unmoderierten Nutzern keine Daten jederzeit.

Das Ziel in Monat 2 ist nicht "tolle Research". Es geht darum, Daten zu produzieren, bevor Änderungen vorgeschlagen werden. Das erste Mal, wenn Sie in ein Design-Review gehen und sagen "wir haben das mit 5 Nutzern getestet, hier ist die Task-Completion-Rate, hier ist die Stelle, an der sie nicht weiterkamen", verändert sich das Gespräch dauerhaft. Sie hören auf, die Person zu sein, die Meinungen hat, und werden die Person, die Belege mitbringt. Das ist die größte Glaubwürdigkeits-Freischaltung in Ihren ersten 90 Tagen.

1 Design-System-Muster beitragen

Versuchen Sie nicht, das gesamte design system zu reparieren. Das ist ein Sog. Andere haben es vor Ihnen versucht, sind auf halbem Weg gescheitert und haben Ihnen die halbfertige v3-WIP-Datei als Beweis hinterlassen.

Wählen Sie eine Komponente. Das Formular-Input. Den Empty State. Die Toast-Benachrichtigung. Gleichen Sie ab, was in Figma ist, mit dem, was tatsächlich geliefert wurde, lassen Sie einen Entwickler eine saubere Version in Storybook einchecken und dokumentieren Sie die Tokens. Fertig.

Das verdient Ihnen Engineering-Vertrauen schneller als jedes Redesign. Entwickler wissen, wie schmerzhaft Design-System-Drift ist; sie haben damit länger gearbeitet als Sie schon dort sind. Eine Komponente vollständig zu reparieren, signalisiert, dass Sie die eigentliche Aufgabe verstehen. Es gibt Ihnen auch ein echtes Artefakt, auf das Sie in Ihrem 90-Tage-Bericht zeigen können: "Ich habe 1 abgestimmte Komponente geliefert. Hier ist das Vorher/Nachher. Hier ist der Geschwindigkeitsgewinn bei ähnlicher Arbeit im nächsten Quartal."

1 kleines Redesign liefern

Nehmen Sie den zweiten Ihrer 3 UX-Debt-Punkte. Begrenzen Sie ihn auf einen einzelnen Sprint: zwei Wochen, nicht zwei Monate. Schreiben Sie ein einseitiges Briefing: das Problem, den Beleg (aus Ihren User-Calls und dem Usability-Test), die vorgeschlagene Änderung, die Kennzahl, die Sie beobachten werden.

Die Kennzahl ist wichtig. Wählen Sie etwas Konkretes. Task-Completion-Rate für den betroffenen Flow. Support-Ticket-Volumen für diesen Screen. Zeit bis zum Wert für die redesignte Aktion. Messen Sie zwei Wochen vorher, liefern Sie, messen Sie zwei Wochen danach. Selbst wenn das Ergebnis gemischt ist, haben Sie die Fähigkeit aufgebaut, Design-Impact zu messen, anstatt sich auf "es fühlt sich besser an" zu verlassen.

Auf Ihr erstes "Mach das hübscher"-Ticket zurückweisen

Ungefähr 60 % aller eingehenden Design-Anfragen bei einem B2B SaaS werden von Entwicklern oder PMs mit einer visuellen Anpassung kommen. "Können wir diesen Button blau machen." "Kann das Spacing hier enger sein." "Diese Karte braucht einen Schatten."

Die meisten davon sind keine echten UX-Probleme. Sie sind die ästhetische Präferenz von jemandem oder ein Workaround für ein echtes Problem, das nicht artikuliert wurde.

Halten Sie eine einzeilige Antwort bereit. Fügen Sie sie in Slack oder das Ticket ein:

"Ich schaue es mir gerne an. Können Sie teilen, welches Nutzerverhalten das ausgelöst hat? Wenn es eine visuelle Präferenz ist, füge ich es dem nächsten Design-System-Durchlauf hinzu. Wenn Nutzer nicht weiterkommen, möchte ich das zugrundeliegende Problem beheben, nicht nur die Oberfläche."

Verwenden Sie das einmal, schriftlich, in einem öffentlichen Kanal. Das Volumen der "Mach das hübscher"-Tickets sinkt innerhalb einer Woche spürbar. Sie weigern sich nicht, die Arbeit zu machen. Sie rahmen sie neu. Die PMs und Entwickler, denen Nutzer wichtig sind, nennen Ihnen das zugrundeliegende Problem, und Sie beheben etwas Echtes. Die, die nur eine visuelle Anpassung wollten, lassen das Ticket still fallen.

Tage 61 bis 90: Eine Kennzahl verantworten, H2 planen

Die Monate 1 und 2 dienten dazu, sich das Recht zu verdienen, die Richtung vorzugeben. Monat 3 ist der Moment, in dem Sie sie vorgeben.

1 UX-Kennzahl verantworten

Wählen Sie eine messbare, sichtbare UX-Kennzahl und stellen Sie Ihren Namen darauf. Nicht fünf. Eine.

Kandidaten, die im B2B SaaS funktionieren:

• Aktivierungsrate bei einem Schlüssel-Onboarding-Flow
• Task-Completion-Rate für den meistgenutzten Workflow im Produkt
• NPS für einen spezifischen Funktionsbereich, den Sie bearbeiten
• Support-Ticket-Volumen bei den Screens in Ihrem Scope
• Zeit bis zum ersten Wert für neue Nutzer

Machen Sie sie sichtbar. Posten Sie sie wöchentlich in einem Slack-Kanal. Fügen Sie sie dem Team-Dashboard hinzu. Erwähnen Sie sie in Design Crits. Der Sinn ist nicht, sich für die Zahl zu rechtfertigen. Der Sinn ist, die Person im Team zu sein, die zuverlässig weiß, was mit Nutzern bei einem bestimmten Flow passiert. Innerhalb eines Quartals, wenn jemand fragt "wie läuft das Onboarding?", werden die Leute an Sie denken.

Einen 90-Tage-Bericht präsentieren

Ein Dokument. Fünf Abschnitte. Je eine Seite. Schicken Sie es bis Tag 90 an Ihre Führungskraft, Ihre PM und Ihren Engineering-Lead.

1. Was ich geprüft habe. Design-System-Drift-Befunde, Design-zu-Engineering-Fluss-Karte, Top 3 UX-Debt-Punkte.
2. Was ich geliefert habe. Die abgestimmte Komponente, das kleine Redesign, die Vorher/Nachher-Kennzahlen.
3. Was ich über Nutzer gelernt habe. Wichtigste Muster aus den 5 Calls und dem Usability-Test. Keine generischen Erkenntnisse; spezifische Verhaltensweisen mit Zitaten.
4. Was kaputt ist. Die Verbindungslücken, die Tooling-Lücken, die Research-Lücken.
5. Was ich für H2 vorschlage. 3 bis 5 Wetten, jede formuliert als: Hypothese / Beleg / Experiment / Erfolgskennzahl.

Diesen Bericht zu überspringen ist der größte unerzwungene Fehler im ersten Quartal eines neuen Designers. Es ist Ihr einziger Moment, die Erzählung Ihrer eigenen Arbeit zu setzen, bevor es jemand anderes in einem Performance-Review sechs Monate später für Sie tut.

Einen H2-Designplan vorschlagen

Drei bis fünf Wetten. Verknüpft mit Produkt-KPIs, nicht mit "das X redesignen".

Eine schlechte Wette sieht so aus: "Das Dashboard redesignen."

Eine gute Wette sieht so aus: "Die Dashboard-Aktivierungsrate von 34 % auf 50 % steigern, indem die Zeit bis zum ersten Diagramm von 8 Minuten auf unter 2 Minuten reduziert wird. Hypothese: die meisten neuen Nutzer brechen die Datenquellen-Verbindung ab. Beleg: 4 von 5 Nutzern in unserem Usability-Test stagnieren bei der Daten-Auswahl. Experiment: einen geführten 3-Schritt-Setup mit Beispieldaten-Fallback liefern. Erfolgskennzahl: Aktivierungsrate an Tag 7."

Jede Wette hat eine Hypothese, einen Beleg (Ihre Prüfung, Ihr Usability-Test, Ihre Support-Tickets), ein Experiment und eine Erfolgskennzahl. Fünf davon reichen. Drei sind auch in Ordnung. Qualität der Formulierung schlägt Quantität der Wetten jedes Mal.

Ihren Arbeitsrhythmus etablieren

Sorgen Sie dafür, dass der Rhythmus im Team-Kalender steht, bevor der Rhythmus von jemand anderem Ihren aufzehrt.

• Design Crit: wöchentlich, 45 Minuten, von Ihnen moderiert
• Research-Review: zweiwöchentlich, 30 Minuten, teilen Sie, was Sie von Nutzern gehört haben
• Design-System-Sprechstunde: wöchentlich, 30 Minuten, jeder kann mit Komponentenfragen vorbeikommen
• 1:1 mit Engineering-Lead: zweiwöchentlich, 30 Minuten, Handoff und Tooling besprechen

Das sind keine Optionen. Wenn Sie sie nicht buchen, werden Ihre Wochen für immer reaktiv.

Einige Realitätschecks zum Mitnehmen

Der "Mach das hübscher"-Interrupt verschwindet nicht vollständig. Er schrumpft nur, sobald Sie ein paar davon neu gerahmt haben. Halten Sie die einzeilige Antwort griffbereit. Verwenden Sie sie freundlich.

Design-System-Versionsdrift ist dauerhaft. Gehen Sie davon aus, dass die Figma-Bibliothek falsch ist. Die Source of Truth ist das, was ausgeliefert wurde. Prüfen Sie zuerst die Produktion, dann Figma. Neue Designer verschwenden Wochen damit, Figma mit Figma abzustimmen; die einzige Abstimmung, die zählt, ist Figma-zu-Produktion.

Die PM, die in Figma vormockt, ist nicht Ihr Feind. Sie füllt ein Vakuum. Kämpfen Sie nicht in Woche 1 dagegen an. Bis Monat 2 lenken Sie um mit: "Gute Richtung. Testen wir das mit 3 Nutzern, bevor wir die Spec einfrieren." Bis Monat 3 werden Sie als erste um Richtung gefragt.

Wenn es keine UXR-Funktion gibt, sind Sie es. Nicht offiziell, nicht Vollzeit, aber genug, damit Entscheidungen aufhören, meinungsgesteuert zu sein. Fünf User-Calls im Monat sind eine Research-Funktion für ein 50-Personen-SaaS. Zwei Stunden Session-Replays pro Woche sind eine Research-Funktion. Liefern Sie die Praxis, nicht den Titel.

Häufige Fallen zu vermeiden

• Das Dashboard in Monat 1 redesignen. Sie haben nicht den Kontext.
• Versuchen, das design system als erstes Projekt zu reparieren. Es ist ein Sog. Reparieren Sie eine Komponente vollständig.
• Jedem "Mach das hübscher"-Ticket zustimmen. Trainiert die Organisation, Sie als Photoshop zu behandeln.
• Den 90-Tage-Bericht überspringen. Sie verlieren Ihren einmaligen besten Moment, die Erzählung zu setzen.
• 90 Tage im Verborgenen arbeiten und dann mit einem 40-seitigen Audit auftauchen. Kleine, sichtbare Erfolge schlagen große unsichtbare Audits jedes Mal.

Erfolgsmessung an Tag 90

Am Ende Ihrer ersten 90 Tage sieht die ehrliche Bilanz so aus:

• Sie können die 3 wichtigsten Nutzer-Reibungspunkte mit Daten, nicht mit Meinungen, benennen.
• Sie haben 1 kleines Redesign mit einem gemessenen Vorher/Nachher geliefert.
• Sie haben mindestens 1 design-system-Komponente zwischen Figma und Produktion abgestimmt.
• Sie verantworten 1 sichtbare UX-Kennzahl, die das Team wöchentlich prüft.
• Ihr H2-Plan ist genehmigt oder in aktiver Diskussion mit PM und Engineering-Lead.
• "Mach das hübscher"-Tickets wurden größtenteils durch "Können Sie sich dieses Nutzerverhalten ansehen" ersetzt.

Wenn Sie vier dieser sechs erreichen, sind Sie weiter, als die meisten B2B-SaaS-UX-Einstellungen an Tag 90. Wenn Sie alle sechs treffen, haben Sie sich das Recht verdient, in H2 die strategische Richtung vorzugeben, was der Beginn der eigentlich interessanten Arbeit ist.

Mehr darüber, was Sie eingestellt wurden zu liefern und wie die Rolle von hier wächst, finden Sie im Product Designer Job Description Template. Die 90-Tage-Erwartung in diesem Leitfaden ist die praktische Version dessen, was diese Stellenbeschreibung beschreibt.

Weiterführende Inhalte

• Product Designer Job Description Template
• Wie man ein Design-System-Audit durchführt
• Usability-Testing ohne Budget
• Auf "Mach das hübscher"-Anfragen zurückweisen