Day in the Life of a UX Designer
Three designers wrote down everything they did on one ordinary workday. No prompts, no interviews. Just the day as it happened.
These characters are composites, built from dozens of real accounts, interviews, and community threads. The people aren't real. The experiences are.
What you'll learn
- A specific day in a ux designer's working life, broken down hour by hour
- The work that does not appear in the job description but takes up significant time
- What the role feels like from the inside on a normal day
Claire's Tuesday
Oat milk latte from the kitchen. Open Figma before Slack, which is my rule. If I open Slack first, the morning is gone. I have maybe ninety minutes of uninterrupted design time before the meetings start. Today I'm working on the permissions settings redesign. Our current permissions page has a table with 34 rows and 6 columns of checkboxes. Two hundred and four checkboxes on one screen. It's incomprehensible. Even our own customer success team can't explain it without a cheat sheet.
Deep in the permissions work. I'm replacing the checkbox table with a role-based system. Instead of configuring 204 individual permissions, admins pick a role template and then adjust the exceptions. In my prototype, I have four templates: Admin, Manager, Employee, and Custom. The Custom option expands into a grouped accordion view instead of the table. I've been working on the accordion interaction for three days. The tricky part is showing inherited permissions. If a Manager role inherits 80% of Admin permissions, the accordion needs to visually communicate which settings are inherited (and locked) versus which are custom (and editable). I'm using a dimmed toggle with a lock icon for inherited settings and a full-color toggle for custom ones.
First meeting. Sprint planning with the PM, Hiro, and the engineering team. Four engineers: two front-end, one back-end, and a QA lead named Becca. Hiro walks through the sprint goals. My permissions redesign is the main feature. I screen-share the Figma prototype. The front-end lead, Margot, asks about the lock icon on inherited permissions. She says the icon component library doesn't have a lock icon in the right size. I say I'll add one. She says, "Can we use a tooltip instead? Tooltips are already built." I say tooltips require hovering and this needs to be visible at rest. She says, "Adding a new icon means updating the design system package and deploying it to the component library, which is a separate PR that needs a review from the design systems team."
We spend fourteen minutes discussing whether a lock icon or a tooltip is the right way to communicate that a permission is inherited. Fourteen minutes on a sixteen-pixel icon. Hiro suggests we "time-box the discussion" which is PM language for "please stop." We agree on the lock icon with a note that Margot will file the design system PR this week. I will send her the SVG by end of day. The fourteen minutes were not wasted. They were the negotiation. This is the job.
Design critique with the other two designers on my team, Wes and Alana. I present the permissions work. Wes asks why I'm using an accordion instead of tabs. Good question. I explain that tabs would require a user to know which category a permission belongs to before they can find it, and our research showed that admins don't think in categories, they think in tasks. "I want to control who can approve time-off requests." That's a task that spans two categories in the current system. The accordion lets me group by task flow instead of system category. Wes nods. Alana suggests adding a search field for admins who manage more than fifty employees. I hadn't thought of that. Add it to the design. Good critique.
Lunch at my desk. Salad from Sweetgreen that cost $16.50, which feels wrong every time but the line is short and it's across the street. Eat while reading a Slack thread about the design system color tokens. Someone on the marketing team used our primary blue in an email template and it's slightly different from the web blue because the email client renders hex colors differently from the browser. This is not my problem but I read the entire 23-message thread anyway because I find color rendering problems soothing in the same way some people find crossword puzzles soothing. My therapist would have something to say about that.
Back in Figma. Add the search field Alana suggested. It goes above the accordion, full width, with a placeholder that says "Search permissions, e.g. 'approve time off'." Test it in the prototype. The interaction is clean: as you type, the accordion sections filter to show only matching permissions. I'm happy with this. It solves the fifty-employee problem elegantly. Spend twenty minutes getting the animation timing right on the accordion collapse. The default Figma smart animate is too fast. I slow it to 200 milliseconds with an ease-out curve. Nobody will consciously notice this. But it'll feel right. That's the craft part. The 200 milliseconds that nobody notices but everybody feels.
One-on-one with my manager, Craig. He asks how the permissions project is going. I say it's on track. He asks about my career development. I say I want to move toward Staff level. He says the path is "leading a cross-team initiative and demonstrating strategic impact." I ask what that means specifically. He says, "I'll think about it and we can discuss next time." This is the third one-on-one where we've had this exact exchange. The answer to "what does Staff look like" is always "we'll discuss next time." I don't think Craig knows what Staff looks like either. He's figuring it out at the same pace I am.
Export the lock icon as SVG. Open our icon component library in Figma. Add the icon following the naming convention: `icon/lock/16`. Set the stroke width to 1.5px to match the rest of the icon set. Export. Send to Margot on Slack with a message: "Lock icon, 16px, 1.5px stroke. Let me know if the artboard setup works for the component library build." She replies with a thumbs up. Fourteen minutes of meeting discussion, resolved with one SVG and a thumbs up. If we'd just Slacked about it in the first place, we'd have saved thirteen minutes. But Hiro likes to "align in person." So we align in person.
Write handoff annotations for the permissions prototype. This is the least glamorous part of UX design and also the most important. If the annotations are unclear, engineering will interpret the design their own way, and their interpretation will be wrong in small ways that are hard to articulate but easy to feel. I annotate every state: default, hover, focus, disabled, error. I annotate the responsive breakpoints. I annotate the keyboard navigation order. For the inherited permissions lock icon, I write: "Lock icon appears at 40% opacity, positioned 4px right of the toggle. No hover state. Not interactive. Purely informational. If the user clicks the locked toggle, show an inline toast: 'This permission is set by the Manager role. To change it, switch to Custom.'"
That toast message took me fifteen minutes to write. Fifteen minutes for one sentence that the user will read in three seconds. But if the sentence is wrong, if it says "inherited" instead of "set by the Manager role," the user won't understand what to do. The word "inherited" is our internal language. The user doesn't know what inheritance means in this context. They know what "set by the Manager role" means. That translation, from system language to human language, is the work. Most of the work.
Close Figma. Walk to the T. Think about the accordion animation. Think about whether 200 milliseconds is right or if 180 would be better. Think about the toast message and whether "switch to Custom" is clear enough or if it should say "select the Custom role above." Think about these things on the Red Line to Davis Square and keep thinking about them while making dinner and eventually stop thinking about them around 9 PM when I start watching a show about people who restore old houses, which is design but for rooms instead of screens, and I find that very relaxing.
Felix's Thursday
Check the A/B test dashboard before anything else. We launched a test on Monday: new hotel search results layout versus the existing one. My redesign uses larger photos, a horizontal scroll for room types, and a sticky price filter at the top. The existing layout is a vertical list with small thumbnails. Four days of data. 48,000 users in each variant. My version is losing. Conversion rate on hotel bookings: control 3.7%, variant 3.4%. That's a 0.3 percentage point drop. Statistically significant as of this morning.
Slack the PM, Hannah. "The hotel search test is significant in the wrong direction. Down 0.3pp on conversion. Want to look at the segments before we kill it?" Hannah replies: "Already saw. Let's look at the data in our 9:30." This is the moment I dread. The design I believed in is objectively performing worse. I have to sit in a room and talk about why.
Meeting with Hannah and the data analyst, Marco. We look at segments. Desktop users: my version is flat, no change. Mobile users: my version is down 0.5pp. The mobile drop is driving the overall loss. Marco pulls up the heatmaps from Hotjar. On mobile, users are scrolling horizontally through the room type carousel and then not scrolling back to the main results list. They're getting stuck in the carousel. The horizontal scroll interaction that I thought would surface more options is actually trapping users in a dead end.
Hannah says, "Should we kill it?" I say, "Can we test a modified version? Remove the horizontal scroll, keep the larger photos and the sticky filter." Hannah checks the sprint capacity. "We can ship a V2 next Tuesday if engineering can reuse the photo component." I Slack the front-end engineer, Jun. He says yes, the photo component is modular. We have a plan. Kill V1 today, build V2 over the weekend sprint, launch next Tuesday. My original design failed. But the failure told us something. The photos and the filter might still be improvements. The carousel was the problem. Now we know.
Back in Figma. Strip the horizontal carousel from the hotel search design. Replace it with a compact room type selector: pills at the top of each hotel card, "Standard," "Suite," "Family," that filter the price shown. No horizontal scroll. No dead end. The interaction is simpler. Less crafted. Less interesting. Probably better. There's a lesson in there that I keep having to relearn: simpler usually wins in consumer design. The interesting interaction is for the designer. The simple interaction is for the user. They're rarely the same thing.
Lunch at the ramen place on Market. Sit at the counter alone, which I prefer because it gives me fifteen minutes of not talking to anyone. The morning was a lot of talking. A/B test review, sprint negotiation, engineering alignment. None of it was design. All of it was necessary for the design to ship. The ratio at a consumer app is roughly: 25% designing, 25% meetings about the design, 25% writing specs and annotations for engineering, and 25% analyzing whether the design worked. I thought design would be the biggest slice. It's the smallest.
Design review with the other product designers: Kim, Lara, and our design lead, Akiko. I present the failed A/B test and the V2 direction. Kim asks if I considered vertical expand-collapse for the room types instead of pills. I hadn't. She sketches it on her iPad and Airdrops me the sketch. It's good. The expand-collapse would let each hotel card show the default room and then expand to reveal others, keeping the vertical scroll intact. I like it better than my pills solution. Spend the rest of the review sketching with Kim on a hybrid approach: pills for filtering when there are two to three room types, expand-collapse when there are four or more. Akiko says, "This is why we do design review." She's right. Kim's idea is better than mine and I wouldn't have gotten there alone.
Prototype the hybrid room type interaction. The pills version takes thirty minutes. The expand-collapse version takes an hour because the animation needs to push the content below it down smoothly. I use Figma's smart animate and it works on the third try. Add a subtle 180-degree rotation on the chevron icon when expanded. Small detail. Nobody at the meeting will mention it. Users won't notice it. But it tells the user, subconsciously, that the card is open and can be closed. That communication happens in 150 milliseconds of rotation. If it matters to one user who would otherwise be confused, it was worth the ten minutes I spent on it.
Write the spec for V2 and send it to Jun. Fourteen Figma frames with annotations. Edge cases documented: what happens when a hotel has only one room type (no pills, no expand, just show the room), what happens when the price changes based on dates after selection (show strikethrough original price with updated price), what happens when a room type is sold out (gray pill, not clickable, "Sold out" label). Jun replies: "Clean spec. One question: the expand animation, do you care about the easing curve or can I use our default?" I tell him ease-out, 200ms. He says ok. The interaction between a designer who cares about easing curves and an engineer who's willing to implement them is the foundation of good product design. Not every engineer is willing. Jun is. I'm lucky.
Walk home through the Mission. Think about the A/B test. Think about the carousel that trapped users. Think about how I'd spent two days refining the horizontal scroll interaction, perfecting the snap points and the peek behavior, making it feel smooth and intentional. And then 48,000 people used it and 0.5% fewer of them booked a hotel. All that craft in the service of a dead end. I'm not upset about it. This is how consumer design works. You design, you test, you learn, you redesign. The emotional cycle is: excitement, investment, data, disappointment, learning, excitement again. I'm on the learning part right now. By Monday I'll be excited about V2. That's the loop.
Tamika's Wednesday
G train to Greenpoint. The office is a converted warehouse that the founders insist on calling a "studio," which is accurate in the sense that we do creative work here and inaccurate in the sense that it's a WeWork sublease with exposed brick and a Keurig. Arrive at 8:30. The client presentation is at 10. I have ninety minutes to finalize the deck.
The client is a mid-size insurance company in New Jersey. We're redesigning their agent portal, the internal tool their 800 insurance agents use to manage policies, file claims, and communicate with customers. We're in week seven of a twelve-week engagement. Today I'm presenting the interaction design for the claims filing flow. Three weeks of work compressed into a forty-five-minute presentation. My designer, Kris, did the wireframes. I refined them and built the prototype. Our researcher, Tomás, ran five usability tests with agents last week. The results are strong: task completion time dropped from six minutes to two minutes and forty seconds. Error rate dropped from 23% to 4%. These are good numbers. I'm proud of them.
Pre-meeting huddle with Kris and our account director, Simone. Simone's job is managing the client relationship. My job is presenting the work. We discuss potential pushback. The big one: we've reduced the claims form from four pages to two by removing fields that our research showed agents never fill out. One of those fields is "Secondary Contact Phone Number." It's been on the form since 2018. Nobody uses it. In five usability tests, zero agents entered data in it. But removing a field from an insurance form is, in the insurance industry, roughly equivalent to suggesting they demolish a building. There will be pushback. Simone says, "If they push back on Secondary Contact, we concede. It's not worth the political capital." I agree. Strategically. Emotionally, I want to fight for it because the field adds cognitive load and clutter and zero value. But Simone is right. We pick our battles.
Client presentation via Zoom. Seven people on the client side. The CIO, Linda. Two IT directors. The head of claims operations, Garrett. Two agent supervisors. And their project manager, Claire. I share my screen and walk through the redesigned claims flow. Show the before and after. Show the usability test numbers. Play a thirty-second clip of an agent completing the new flow where she says, "Oh, this is way better. I can actually see what I'm doing."
Garrett loves it. He's the one who works with agents every day and he can see the improvement immediately. Linda nods along. The IT directors ask implementation questions that I defer to their engineering team. And then, exactly as predicted, one of the agent supervisors, a man named Phil, says, "Where's the Secondary Contact Phone Number field?"
I explain that the field had zero usage across our test sessions and removing it reduces the form length by 12%. Phil says, "We added that field because an agent in Trenton needed it for a commercial policy in 2018." One agent. In 2018. Eight years ago. For one commercial policy. And the field has been taking up space on every claim form for 800 agents ever since. I want to say this. I don't. I say, "That's helpful context. We can keep the field available as an optional expandable section at the bottom of the form, so agents who need it can access it without it adding to the default form length." Phil says, "That works." Simone catches my eye on the Zoom grid and gives me the smallest possible nod.
The optional expandable section will take Kris about two hours to add to the design. It's a compromise. The form is still shorter. Phil gets his field. The agent in Trenton from 2018 is served. This is agency UX. The design is never pure. It's a negotiation between what's right, what's acceptable, and what the person in the room with the strongest opinion will tolerate.
Post-presentation debrief with Simone and Kris. Simone says it went well. The claims flow is approved with the Phil modification. Next week we present the policy management redesign. I assign Kris the expandable section update and start thinking about the policy management work. Pull up the current policy management screens. Forty-seven unique states across twelve flows. This is going to take the rest of the engagement and probably some change requests beyond it. Change requests are how agencies make margin, which is a thing I didn't understand until year three.
Lunch at the Thai place on Manhattan Ave with Kris. He's frustrated about the Phil compromise. "We tested this," he says. "Zero usage. Why are we keeping it?" I tell him the thing I've learned in six years of agency work: the research convinces us, not them. The research gives us authority to propose. It does not give us authority to decide. The client decides. Our job is to make the best possible version of what the client will accept. Kris is 26. He'll learn this or he'll leave agency work. Most designers leave. The ones who stay are the ones who find satisfaction in the negotiation, not just the design.
Switch to the other active project: a nonprofit donation platform redesign. Different client, different problems. The nonprofit wants to increase average donation size. Their current donation page has four preset amounts ($25, $50, $100, $250) and a custom field. I've redesigned it with three changes: social proof ("327 people donated this month"), an anchoring default ($75 pre-selected instead of the lowest option), and a monthly option that shows the annual impact ("$25/month provides 300 meals per year"). Tomás tested it with twelve recruited donors last week. Average intended donation increased from $62 to $89. The monthly opt-in rate was 34%. Good numbers.
The challenge with the nonprofit is different from the insurance company. The insurance company pushes back on removing things. The nonprofit pushes back on adding things because every new element requires their developer, a single part-time contractor named Sam, to implement it. Sam has ten hours a week. My social proof counter requires a real-time API call. Sam says that's "at least four hours of work." Four of his ten weekly hours. For one line of text on one page. The economics of nonprofit design are brutal. Every pixel has a labor cost that's measured in fractions of one person's very limited time.
Design system work. Every Thursday from 4 to 5 I spend an hour maintaining our agency's internal component library. Today I'm updating the form field components to include the new error state pattern we developed for the insurance project. The pattern uses an inline error message below the field instead of a top-of-form error summary. It tested better. I want to codify it so the next project can use it without redesigning error states from scratch. This work is invisible. No client pays for it. Simone approved one hour a week of "non-billable design system time" after I made the case that reusable components save us forty to sixty hours per project in wireframing. The business case for craft is always a time savings argument. It's never "because it's better." Better doesn't have a billing code.
G train home. Stand because there are no seats, which is fine because I'm thinking and thinking is better standing. Think about the insurance project and the nonprofit project and how different they are and how the core skill is the same: understand what people need, design it, present it, negotiate the compromises, document everything, hand it off. The medium changes. The screen changes. The client changes. The process doesn't. After six years, the process is the part I trust. Everything else is variables.