Português

A Day in the Life of a UX Designer (B2B SaaS, IC Edition)

The job description said you'd "design beautiful experiences and shape the future of our product." What you actually did yesterday was spend 90 minutes arguing with an engineer about whether a confirmation modal needs a secondary cancel button, then 40 minutes explaining to a sales rep why "make it pop" is not a design brief. Welcome to B2B SaaS UX.

The fantasy and the reality are different jobs. The fantasy is Dribbble shots, mood boards, and stakeholder applause. The reality is research notes, spec arguments, and a Figma file with 47 frames named "Frame 142," "Frame 143," "Frame 144." Both jobs are real. Only one of them is yours.

This is what a normal weekday looks like for a UX designer with one to five years in. No glamour. No portfolio money shots. Just the actual rhythm of the work, the time sinks nobody warns you about, and the small disciplines that decide whether you go home tired-but-fine or tired-and-resentful.

8:02am — Figma and Slack triage

You open Figma first. Three files have overnight comments. Two from engineers in another timezone, one from the PM who works late.

You open Slack second. Twelve unreads in your DMs and the #design-team channel. One is a sales rep with a screenshot of the dashboard and the words "can we make this look more modern." One is a customer success person tagging you in a thread about a customer who can't find the export button. The rest is noise.

The triage takes ten minutes if you do it right. Three categories:

Blocking engineering. An engineer is stuck because a state isn't specified in your Figma file. This is your most expensive interrupt to defer. If you wait three hours, they context-switch to something else and your component ships a week late. Answer in Figma comments now. Two-sentence answer, screenshot of the spec frame, link to the Storybook component if it exists. Move on.

Pretty-up requests. The sales rep wants the dashboard to "pop more." This is a real request from a real person, and it deserves a real answer, but it does not deserve your morning. Reply in Slack: "Adding to the visual-polish backlog. Quick question first. Is there a specific deal you're trying to close where the look is the blocker, or is this a general feeling?" Nine times out of ten, the answer is "general feeling" and the request quietly dies. The tenth time, it's a real customer escalation and you escalate it to your design lead.

Spec questions. "What does this state look like when the user has 0 results?" These are real and worth your time, but they don't need a synchronous answer. Mark them for the async block at 10am.

The morning triage is not glamorous. It is also the single highest-leverage 15 minutes of your day. Designers who skip it spend the rest of the day reactive. Designers who do it well shape what their day looks like.

10:00am — Async spec block

This is the part of the job nobody told you about in school: most of your "design" time is writing.

You open Notion. You have three open spec questions from the morning triage. Each one needs a written answer that closes the loop, not one that reopens it.

Bad answer: "I think it should probably be a toast notification, but let me know what you think." This invites a six-message thread, because you've outsourced the decision back to the engineer.

Good answer: "Toast notification, top-right, 4-second auto-dismiss. Reuses the existing <Toast variant='success'> component in Storybook. Frame 47 in the file shows the spec. If the API takes longer than 8 seconds, swap to a persistent inline banner instead of the toast (frame 48 shows that variant). Linked the Linear ticket below."

The good answer takes six minutes to write. The bad answer takes 30 seconds and costs the team an hour over the next two days. You learned this the hard way.

The discipline is: every spec answer ends with three things. The decision, the component reference (Storybook link or Figma frame number), and the ticket linkback in Linear or Jira. No exceptions. The evidence trail is the whole point. Six months from now when someone asks "why did we build it this way," the trail is what saves you from re-litigating the decision.

Your async block runs from 10am to 11:30am. You answer four spec threads, write one short Notion doc on a pattern decision, and close two Figma comments that didn't actually need answers because the engineer already figured it out by reading the file. That last category is a quiet win. It means your file is clear enough to read.

12:00pm — Moderated usability test

Lunch first. You eat a sandwich at your desk because the test starts at 12:30 and you need to re-read your test plan. Yes, you should take a real lunch. No, you won't, not on test days.

The test is 30 minutes, moderated, run through Maze with a real customer: a billing manager at a 200-person logistics company. You're testing the new invoice-export flow. Your hypothesis is that the new flow cuts time-to-export from 90 seconds to under 30. Your null hypothesis is that the new flow confuses users in a way the old one didn't.

Here is the part new designers get wrong. You are not watching for what the user says. You are watching for what they do. Verbal feedback is mostly noise. Users want to be helpful. They will say "this is great, very intuitive" while their cursor hovers over the wrong button for nine seconds. The hover is the data. The "very intuitive" is politeness.

What you are actually watching for:

  • Hesitation. Cursor stops. Eyes flick to a different part of the screen. The user re-reads a label. Anything over two seconds of hover-without-click is a flag.
  • Misclicks. They click the wrong thing, then back-button, then click the right thing. The wrong-click is the signal that your visual hierarchy is lying about what's primary.
  • Re-reads. They read a label, scroll past, then scroll back to re-read it. That label is unclear. Your job is not to add a tooltip. Your job is to rewrite the label.

You take notes in a three-column Notion doc: timestamp, observation, hypothesis. No commentary, no "I think this means." Just what you saw and what it might suggest. You'll synthesize after.

Your note-taking system has to survive back-to-back sessions. The trick is to use a single-page template per study with the columns pre-populated and screenshots glued in afterward, not during. If you try to take screenshots during the session, you miss the next behavior. The session is the priority. The artifact comes after.

The billing manager finishes the export task in 47 seconds. Better than the old flow, worse than your hypothesis. She hesitated twice — once at the date-range picker (8 seconds), once at the file-format selector (5 seconds). She said the experience was "much better than what we have now," which is real but not the data. The two hesitations are the data.

2:00pm — Design critique

Forty-five minutes with two other designers and your design lead. Three flows on the agenda, fifteen minutes each. You're presenting one of them.

Most critiques fail the same way: they turn into committee design. Someone says "what if we tried purple instead of blue," someone else says "what if the modal slid in from the right," and 20 minutes later the room has redesigned a flow that was 80% done into a flow that's now 40% done. This is a known failure mode. It has a name in your head: the focus-group spiral.

Here is how you avoid it. When you present a flow, you give three things up front:

  1. The user problem. Not "we're redesigning the export flow." Instead: "Billing managers at mid-market customers spend an average of 90 seconds exporting an invoice and tell us in support tickets it's confusing."
  2. The constraint. "We can't change the underlying API contract for two more quarters."
  3. The specific feedback you want. "I'm not asking about visual polish today. I'm asking whether this flow handles the multi-currency edge case for our European customers."

If you give all three, critique becomes useful. People give you feedback on the thing you asked about, not on the thing they happened to notice in the first 30 seconds.

The two kinds of critique feedback you actually want sound like this. "I disagree with this pattern" is opinion, polite to acknowledge, fine to dismiss. "This won't work for enterprise admin users because they have 200 saved exports and your dropdown only shows 10" is a real critique. The second kind is gold. The first kind is throat-clearing. Treat them differently.

You leave critique with three concrete changes to make to the flow before handoff. None of them are about color.

4:00pm — The interrupt

The PM Slacks you. "Hey, leadership wants a quick redesign of the dashboard by Friday. Can you take a stab tomorrow?" It is Wednesday at 4:07pm.

This is the moment that defines whether you become the team's pixel concierge or stay a designer.

The wrong response is "sure, I'll get on it." The wrong response feels good in the moment because you're being helpful. It is the wrong response because by Friday you will have a half-finished dashboard mockup, two skipped usability sessions, and a handoff doc you didn't write for the work you actually committed to last week.

The right response is a question, not a yes. "Happy to look. Can you tell me what changed in the roadmap that made this a Friday item, and what 'redesign' means here: visual refresh of the existing layout, or restructured information architecture? Those are very different jobs." You send it in 90 seconds. You go back to your handoff prep.

Half the time, the question reveals that "redesign" meant "change the chart colors," and a different person on the team can do that. A quarter of the time, it reveals that the request is real but the deadline isn't. The remaining quarter of the time, it's a genuine emergency, and you bump something off your week to handle it. The PM respects you more for the question than for the reflexive yes.

5:00pm — Handoff prep

Last 30 minutes. This is the part of the day where most designers cut corners and most engineering Slacks the next morning to ask "what did you mean here?"

The handoff discipline is 20 minutes of work that prevents 90 minutes of pings tomorrow. It is the cheapest insurance you will ever buy.

You clean the Figma file. Frames named with intent: "Export flow / step 2 / multi-currency variant." Layers grouped. Hidden frames deleted. Components linked, not detached.

You write the one-page Notion spec. Five sections, no more. Problem (one sentence). Solution (three sentences). States and edge cases (a list). Component references (Storybook links, Figma frame numbers). Open questions (the things you and the engineer still need to decide).

You attach the Notion doc to the Linear ticket. You drop the Storybook link in the ticket comment. You tag the engineer.

You close the laptop at 5:32pm.

What the JD doesn't tell you

Half this job is research and writing. Maybe more than half. The Figma part (the part the JD describes as "designing beautiful experiences") is actually the smallest slice of your week. Most weeks it's somewhere between 25% and 35% of your time. The rest is talking to users, talking to engineers, writing specs, sitting in critiques, and triaging interrupts.

The designers who burn out at B2B SaaS came in expecting Dribbble. They wanted to make screens. They got a job that's mostly conversations and writing about screens. The mismatch eats them.

The designers who thrive treat Figma as a thinking tool, not a portfolio. Their files are messy in the middle and clean at the end. Their Notion is full of one-page spec docs that nobody else reads but that save them every time someone asks "why did we ship it this way." They write more than they design, and they're fine with it because the writing is what makes the designing land.

The pretty-up interrupt, the focus-group spiral, the pixel concierge trap — these all have names because they're patterns, not bad luck. Once you name them, you can spot them in the first five minutes. That's the skill nobody teaches you in school and nobody puts on the JD.

You are not in this job to make screens. You are in it to make decisions about screens, defend them in writing, and ship them in a way that survives next quarter's roadmap shift. The screens are the artifact. The decisions are the work.

Tomorrow looks roughly the same as today. The triage, the async block, the user session, the critique, the interrupt, the handoff. Different files, same shape. The shape is the job.

Learn More