Your First 30/60/90 Days as a New UX Designer

Day 1. You log into Figma, open the team workspace, and find a file titled "OLD-DO-NOT-USE-final-v4" with 47 unread comments. Three other Figma libraries are pinned to the top of the workspace: v2, v2.1, and v3-WIP. None of them match what you just saw shipped in production. Your PM Slacks you a calendar invite for "design review" tomorrow at 10am. There's no agenda.

Welcome to UX in B2B SaaS.

This guide pairs with the Product Designer Job Description Template. The JD describes what you were hired to do, and this is what the actual work looks like. If you're reading this before you start, print it. If you're reading it three weeks in, you're not behind. Most new UX designers don't have a 90-day plan, which is precisely why the org will give them one whether they want it or not.

Why a Written 30/60/90 Matters for Designers Specifically

Engineering has standups. PMs have roadmaps and sprint planning. Sales has a number. Designers have… vibes? A monthly design crit if someone remembers to book it?

Without a written plan, your first 90 days become whatever your loudest stakeholder needs that week. A PM books "quick design review" 30 minutes before sprint planning and walks out with mocks. An engineer pings you about a hex code and you spend 40 minutes in Figma. Three months in, you've shipped 60 small visual tweaks and zero strategic work, and your manager is asking what your impact has been.

A written 30/60/90 is your single best defense against scope creep, "make this prettier" interrupts, and being treated as Photoshop-on-call. It also gives you something to point to in week 4 when someone asks why you haven't redesigned the dashboard yet.

The plan below assumes you're a mid-level UX hire (2-5 years experience), individual contributor, joining a B2B SaaS company anywhere from Series A to public. You were hired to do real product work. Not redesign the marketing site. Not "refresh the brand."

Days 1-30: Audit, Don't Ship

The single biggest mistake new UX designers make is shipping something visible in week 2. The dashboard redesign. The "modernized" empty state. The new color tokens. It feels productive. It looks like progress. Six months later it's also the reason you're being quietly managed out, because nobody can find the user research that justified it, and the engineers who rebuilt three components on a tight sprint are not your friends anymore.

In month 1, you don't have the context to ship anything that's actually correct. So don't.

Audit the Design System

Open every Figma file in the workspace. Every one. Make a list. For each file, note: when was it last edited, who edited it last, is it linked from any active spec, does anyone on the team currently use it.

Now compare what's in Figma to what's in production. Open the live app. Inspect a button. Compare it to the button component in v2, v2.1, and v3-WIP. You will find drift. Three or four pixels of padding here, a different border-radius there, a hover state that exists in Figma but not in code. Catalog it.

Output: a 1-page "design system reality check" doc. Component name, Figma version it lives in, production version, drift summary, ownership ambiguity. Do not propose fixes yet. Just document. This doc becomes the artifact that proves you understood the mess before you tried to clean it up, and it makes the case for design system investment when budget conversations happen at the end of Q1.

Sit in 5 User Research Calls

If there's an active research function, ask the researcher to add you to upcoming sessions as a silent observer. If there isn't (and at most B2B SaaS companies under 200 people, there isn't), get creative.

Ask sales to forward you 5 recorded discovery calls. Ask support for the 10 most-watched session recordings in FullStory or Hotjar. Sit in 2 onboarding calls with new customers. Listen to 2 cancellation calls if you can stomach it.

You're not looking for "insights" in the slide-deck sense. You're learning the language. How do users describe the product? What do they call the features? Which words come up over and over when they're frustrated? Take notes on language, not just pain points. The vocabulary you pick up in week 2 will save you 100 hours of rewriting microcopy in month 6.

Map the Design-to-Eng Flow

Sit down with one engineer who's shipped a recent UI change. Ask them to walk you through, end to end: the Figma frame, where the spec lived, where the design tokens came from, how they translated padding and color into code, what they had to ask the previous designer about, what they had to invent.

Now draw it on one page. Designer → Figma frame → spec doc (where?) → tokens (where?) → engineer → Storybook (does it exist? is it current?) → production.

You will find at least three places where the handoff is broken. The tokens live in three different sources of truth. The Storybook hasn't been updated in 11 months. Specs live in Notion, Confluence, and Figma comments depending on who wrote them. Document this. It is the second proof artifact for your 90-day report.

Identify the Top 3 UX Debt Items

Not "the homepage looks dated." Real friction. The kind that costs the business money or burns support budget.

Examples that count:

Filters lose state on page reload, so users redo their work every time they navigate away.
Onboarding has 4 dead-end states where users hit a wall with no recovery path.
The bulk action bar covers the table footer pagination, so users can't see they've selected items beyond page 1.

Examples that don't count:

"The buttons look old."
"The icons are inconsistent."
"It doesn't feel modern."

Get to your top 3 by triangulating: support ticket volume, NPS verbatims, sales objections, and the user calls you sat in on. Write each one as: behavior observed, evidence (ticket count, call quotes, session replay), business impact. These three items become your 60- and 90-day proof points.

The One Thing You Don't Do in Days 1-30

Ship.

Resist every request to deliver a visible artifact in your first month. Resist the "quick win." Resist the redesign. Resist the brand refresh. New designers who ship something high-visibility in week 2 are the same ones whose work gets quietly rolled back in month 6 because they didn't have the context to be right.

If a PM pushes hard, the response is: "I want my first shipped change to be one I can defend with data. I'll have that in 4-6 weeks." Most reasonable PMs will respect this. The unreasonable ones are telling you something useful about the team.

Days 31-60: Run, Contribute, Ship Small

Now you have context. Time to convert it into evidence and shipped work, but small, scoped, defensible.

Run 1 Usability Test

Pick one of your 3 UX debt items. Run a usability test on it. Five users. Unmoderated is fine. Maze or UserTesting will get you data inside a week for under $200. If you have a research function, ask them to help moderate one session so you can co-pilot. If you don't, Maze with 5 unmoderated users beats no data every time.

The goal in month 2 is not "great research." It's producing data before proposing changes. The first time you walk into a design review and say "we tested this with 5 users, here's the task completion rate, here's where they got stuck" — the conversation changes permanently. You stop being the person who has opinions and become the person who brings evidence. That is the single biggest credibility unlock in your first 90 days.

Contribute 1 Design System Pattern

Don't try to fix the whole design system. It's a sinkhole. People have tried before you, gotten halfway, and left you the half-finished v3-WIP file as proof.

Pick one component. The form input. The empty state. The toast notification. Reconcile what's in Figma to what's actually shipped, get an engineer to commit a clean version into Storybook, and document the tokens. Done.

This earns you engineering trust faster than any redesign. Engineers know how painful design system drift is; they've been working around it longer than you've been there. Fixing one component, all the way, signals that you understand the actual job. It also gives you a real artifact to point to in your 90-day report: "I shipped 1 reconciled component. Here's the before/after. Here's the velocity gain on similar work next quarter."

Ship 1 Small Redesign

Take the second of your 3 UX debt items. Scope it to fit in a single sprint: two weeks, not two months. Write a 1-page brief: the problem, the evidence (from your user calls and usability test), the proposed change, the metric you'll watch.

The metric matters. Pick something concrete. Task completion rate on the affected flow. Support ticket volume on that screen. Time-to-value for the action being redesigned. Measure for two weeks before, ship, measure for two weeks after. Even if the result is mixed, you've built the muscle of measuring design impact instead of relying on "it feels better."

Push Back on Your First "Make This Prettier" Ticket

Roughly 60% of inbound design requests at a B2B SaaS will be engineers or PMs asking for a visual tweak. "Can we make this button blue." "Can the spacing be tighter here." "This card needs a shadow."

Most of these are not actual UX problems. They're someone's aesthetic preference, or a workaround for a real issue they haven't articulated.

Have a 1-line response ready. Paste it into Slack or the ticket:

"Happy to look — can you share what user behavior triggered this? If it's a visual preference, I'll batch it with the next design system pass. If users are getting stuck, I want to fix the underlying problem, not just the surface."

Use it once, in writing, on a public channel. The volume of "make this prettier" tickets drops noticeably within a week. You're not refusing the work. You're reframing it. The PMs and engineers who care about users will give you the underlying problem, and you'll fix something real. The ones who just wanted a visual tweak will quietly drop the ticket.

Days 61-90: Own a Metric, Plan H2

Months 1 and 2 were about earning the right to set direction. Month 3 is when you set it.

Own 1 UX Metric

Pick one measurable, visible UX metric and put your name on it. Not five. One.

Candidates that work in B2B SaaS:

Activation rate on a key onboarding flow
Task completion rate for the most-used workflow in the product
NPS for a specific feature area you're touching
Support ticket volume on the screens in your scope
Time-to-first-value for new users

Make it visible. Post it weekly in a Slack channel. Add it to the team dashboard. Reference it in design crits. The point is not to be defensive about the number. The point is to be the person on the team who reliably knows what's happening with users on a specific flow. Within a quarter, when someone asks "how's onboarding doing," people will think of you.

Present a 90-Day Report

One document. Five sections. One page each. Send it to your manager, your PM, and your eng lead by day 90.

What I audited. Design system drift findings, design-to-eng flow map, top 3 UX debt items.
What I shipped. The reconciled component, the small redesign, the before/after metrics.
What I learned about users. Top patterns from the 5 calls + usability test. Not generic insights; specific behaviors with quotes.
What's broken. The connective tissue gaps, the tooling gaps, the research gaps.
What I'm proposing for H2. 3-5 bets, each framed as: hypothesis / evidence / experiment / success metric.

Skipping this report is the single biggest unforced error in a new designer's first quarter. It's your one moment to set the narrative on your own work before someone else does it for you in a perf review six months later.

Propose an H2 Design Plan

Three to five bets. Tied to product KPIs, not to "redesign the X."

A bad bet looks like: "Redesign the dashboard."

A good bet looks like: "Increase dashboard activation rate from 34% to 50% by reducing the time-to-first-chart from 8 minutes to under 2. Hypothesis: most new users abandon during data source connection. Evidence: 4 out of 5 users in our usability test stalled at the data picker. Experiment: ship a guided 3-step setup with sample data fallback. Success metric: activation rate at day 7."

Each bet has a hypothesis, evidence (your audit, your usability test, your support tickets), an experiment, and a success metric. Five of these is plenty. Three is fine. Quality of framing beats quantity of bets every time.

Establish Your Operating Rhythm

Get cadence on the team calendar before someone else's cadence consumes yours.

Design crit: weekly, 45 minutes, you run it
Research review: bi-weekly, 30 minutes, share what you've heard from users
Design system office hours: weekly, 30 minutes, anyone can drop in with component questions
1:1 with eng lead: bi-weekly, 30 minutes, talk handoff and tooling

These aren't optional. If you don't book them, your weeks become reactive forever.

A Few Reality Checks to Carry With You

The "make this prettier" interrupt won't go away entirely. It just shrinks once you've reframed a few. Keep the 1-line response handy. Use it kindly.

Design system version drift is permanent. Assume the Figma library is wrong. The source of truth is what shipped. Audit production first, Figma second. New designers waste weeks reconciling Figma to Figma; the only reconciliation that matters is Figma-to-production.

The PM who pre-mocks in Figma is not your enemy. They're filling a vacuum. Don't fight it in week 1. By month 2, redirect with: "Love the direction. Let's pressure-test it with 3 users before we lock the spec." By month 3, you're the one being asked for direction first.

If there's no UXR function, you are it. Not officially, not full-time, but enough that decisions stop being opinion-led. Five user calls a month is a research function for a 50-person SaaS. Two hours a week of session replays is a research function. Ship the practice, not the title.

Common Pitfalls to Avoid

Redesigning the dashboard in month 1. You don't have the context.
Trying to fix the design system as your first project. It's a sinkhole. Fix one component, fully.
Saying yes to every "make this prettier" ticket. Trains the org to treat you as Photoshop.
Skipping the 90-day report. You lose your single best moment to set narrative.
Going dark for 90 days then surfacing with a 40-page audit. Small visible wins beat big invisible audits, every time.

Measuring Success at Day 90

By the end of your first 90 days, the honest scorecard looks like this:

You can name the top 3 user friction points with data, not opinions.
You've shipped 1 small redesign with a measured before/after.
You've reconciled at least 1 design system component between Figma and production.
You own 1 visible UX metric the team checks weekly.
Your H2 plan is approved, or in active discussion, with PM and eng lead.
"Make this prettier" tickets have largely been replaced by "can you look at this user behavior."

If you hit four of those six, you're ahead of where most B2B SaaS UX hires are at day 90. If you hit all six, you've earned the right to set strategic direction in H2 — which is when the actually interesting work starts.

For more on what you were hired to deliver and how the role grows from here, see the Product Designer Job Description Template. The 90-day expectation in this guide is the practical version of what that JD describes.

UX Designer Playbooks