What UX Design Is Actually Like

Tell us what you actually do.

I design enterprise software that helps logistics companies manage their supply chains. Warehouses, shipping routes, inventory levels. That kind of thing. Our customers are operations managers at companies like Sysco and US Foods. People who are moving physical goods through physical spaces and need software to keep track of all of it. My job is to make that software usable, which sounds simple until you realize that "usable" in enterprise means something completely different than "usable" in consumer.

In consumer, usable means intuitive. You open the app and you know what to do. In enterprise, usable means "the person who's been using this for seven years can still do their job after we change it." That's a totally different design problem. I'm not designing for delight. I'm designing for minimal disruption. My success metric isn't "users love it." It's "users didn't call support."

Walk us through a recent project.

Last quarter I redesigned the notification settings page. I know. Glamorous. But this page was a disaster. It had been built incrementally over five years by three different engineering teams. There were 47 notification types organized in no discernible order. Some had toggle switches. Some had dropdowns. Some had both for no reason. Our support team, according to Janice who runs support, got about 30 tickets a month from people who couldn't figure out how to turn off the daily inventory summary email. Thirty tickets a month. For a settings page.

So I did research. Interviewed eight customers over Zoom. Watched them try to use the current page. One guy, Frank, who manages a warehouse in Memphis for a food distributor, stared at the page for eleven seconds and then said, "I don't even know what half of these are." Frank has been using our software for four years. If Frank doesn't know what the notifications are, nobody does.

I designed a new version. Grouped the 47 notification types into six categories based on how customers actually think about them: shipments, inventory, alerts, reports, billing, and system. Added a search bar. Used consistent toggle switches everywhere. Wrote plain-English descriptions for each notification type. Like, instead of "Inventory Threshold Breach Notification" I wrote "When stock drops below your minimum level." Tested it with five customers. All five completed the task in under a minute. The old page averaged three minutes and twelve seconds for the same task.

Sounds like a win.

It was a win in the prototype. Then it went to engineering. Our lead engineer on that team, a guy named Pavel, looked at the design and said, "We can do the groupings but not the search bar. The notification system doesn't have an API that supports search. To add search, I'd need to refactor the notification service, which touches the event bus, which is shared infrastructure." That's a two-sprint effort that his engineering manager, Diane, wouldn't approve because it wasn't in the quarterly roadmap.

So we shipped without search. Which, fine, the groupings alone were a big improvement. But then the product manager, Helen, got feedback from the sales team that two enterprise clients wanted the old layout because they'd built internal training documents with screenshots of the existing page and didn't want to redo them. So Helen asked me to add a "classic view" toggle. A toggle. On the settings page. To switch to the old settings page. I'm a UX designer and I was asked to design a button that undoes my own design.

I pushed back. I said, "If we ship a classic view toggle, nobody will ever use the new version because the path of least resistance is always the familiar one." Helen agreed in principle but said the two accounts were worth $400,000 in annual revenue combined and she couldn't risk them churning over a settings page. We shipped the toggle. Six months later, 68% of users are still on classic view. The redesign I spent three weeks on is used by 32% of customers. The support tickets dropped from 30 a month to 22, which is an improvement, but not the improvement it should have been.

Is that normal in B2B?

Completely. My friend Maren, she's a UX designer at a consumer fintech app, and when I tell her stories like this she looks at me like I'm describing a prison. At her company, they ship a redesign and the old version is gone. Done. Users adapt. In enterprise, users have contracts. They have procurement cycles. They have internal processes built around your current UI. You can't just change things. You have to negotiate every pixel with sales, customer success, engineering, and sometimes the customer directly. I spend maybe 30% of my time actually designing. The rest is meetings, Slack threads, and writing Jira tickets that explain why the design is the way it is, because three months from now a new PM will read the ticket and ask "why did we group it this way?" and if the rationale isn't documented, they'll undo it.

What is it?

Enterprise UX design is lonely. At a consumer company, designers are part of the product culture. Design thinking is celebrated. Figma prototypes get Slack reactions. At a B2B company that sells supply chain software, design is a support function. Engineering makes the thing. Product decides what to make. Sales decides who to sell it to. Design makes it look nice. That's how most people in my company think of my job. "Make it look nice." I've been here three years and the CEO has never once asked the design team for input on strategy. He asks product. He asks engineering. He asks sales. Design hears about the strategy in a company all-hands and then we react to it.

My manager, Oren, is great. He fights for design to have a seat at the table. He's been fighting for three years. The table keeps filling up before we get there. I'm not bitter about it. I've accepted it. But it's a thing that bootcamps and design programs don't tell you. At a lot of companies, especially B2B, UX design is not the creative leadership role you saw in the case study. It's a service role. You serve the product org. You serve engineering. You serve sales. You serve the customer, last.

Consumer app. That's the dream, right?

Depends on the dream. If the dream is "I design beautiful interfaces and ship them to millions of people," then yeah, sometimes. If the dream is "I do meaningful design work," then, I mean, some weeks yes and some weeks no. The speed is the thing nobody warns you about. At my company we ship something every two weeks. Every two weeks. That means my design cycle for any given feature is about five days. Two days to understand the problem, two days to design, one day to hand off. If the feature is complex I might get an extra week. Maybe.

I came from a health tech startup where my design cycle was four to six weeks per feature. I did research. I did prototypes. I tested with users. I iterated. At the fitness app, the cycle is: PM writes a one-pager, I design a solution in Figma, we review it as a team on Wednesday, engineering starts building on Thursday. If I want to do user research, I have to do it on my own time, before the feature is in the sprint, using whatever informal testing I can pull together. Our head of product, Bria, is supportive of research "in theory." In practice, research adds a week and she doesn't want to slip the sprint.

So how do you know if your designs are good?

A/B tests. Everything gets A/B tested. Everything. We'll ship a new onboarding flow and test it against the old one. We'll test a new color for the CTA button. We'll test whether the workout completion screen should have confetti or not. I'm serious about the confetti. We ran a two-week A/B test on confetti. The confetti version increased seven-day retention by 0.4 percentage points. It shipped. I now live in a world where my design decisions are validated or invalidated by numbers that are barely above the noise floor.

The hard part is when a design I believe in loses the A/B test. Last fall I redesigned the workout logging screen. The old one was a list of exercises with sets and reps in a table layout. Functional but ugly. Clinical. I redesigned it to be more visual. Each exercise was a card with a progress ring showing completion. The rep counts were bigger. There was a satisfying animation when you logged a set. I was really proud of it. It was the best design work I'd done at this company.

We A/B tested it. The new version had a 2.1% lower completion rate for logged workouts. Users were starting workouts at the same rate but finishing them less often. Bria's data analyst, Noor, dug into the session recordings and found that users were tapping on the progress rings expecting them to be interactive, like a button. They weren't. They were decorative. But the visual language of a ring in a fitness app says "tap me." So my beautiful design was confusing people and they were abandoning their workout logs in frustration.

We killed it. Two weeks of my best work, killed by a progress ring that looked too tappable. I went back to the list layout and just cleaned it up. Bigger fonts, better spacing, same table. The A/B test was flat. No improvement, no regression. We shipped it because it was cleaner. Bria said, "Sometimes flat is fine." Which is true. But "flat is fine" is not why I became a designer.

What does a typical week look like?

Monday is planning. I sit in a sprint planning meeting with the PM, the tech lead Ankit, and two engineers. We talk about what's shipping this sprint. I present the designs I did last week. Ankit asks implementation questions. Usually something like, "Can we use a standard component for this or does it need custom work?" I try to use standard components whenever possible because custom work means Ankit needs more time and Bria doesn't want to slip.

Tuesday and Wednesday I'm designing the next sprint's features. This is the actual design work. Figma, components, prototypes. I work fastest in the morning before Slack gets busy. My best design work happens between 7 and 10 AM. By 10 AM the meetings start and I'm in review mode for the rest of the day. Wednesday afternoon we do a design review with the other two designers on the team, Kim and Raj. They give feedback. I give feedback on their work. These reviews are genuinely useful. Kim caught a spacing issue last week that I'd missed because I'd been staring at the same frame for three hours.

Thursday is handoff. I add annotations to the Figma file, write spec notes for edge cases, and answer questions from engineering in Slack. Friday is a mix of research (if I have time), design system maintenance (the component library needs constant updates), and whatever Bria needs for the next week's planning.

Go.

Design at a consumer app is not a creative job. It's an optimization job. I'm not inventing new interaction patterns. I'm testing variations of existing patterns to find the one that moves a metric by 0.3%. The creativity happens in the margins. A micro-interaction here. A transition there. The stuff users feel but can't articulate. That's where the craft lives. But the job, the thing I'm evaluated on, is whether the screen I designed moved the number. If it moved the number, it was good design. If it didn't, it wasn't. Craft doesn't factor into the evaluation.

My portfolio from design school has these gorgeous conceptual projects. Speculative interfaces. Wild typography. Playful interactions. None of that is relevant to my job. My job is: make the button bigger, test it, see if more people tap it. I don't hate it. There's a satisfaction in the empiricism. But it's a different thing than what I thought I was signing up for.

Agency UX. How is that different from in-house?

At an in-house job, you're married to the product. For better or worse, you're in it every day. You know the codebase limitations. You know the users. You know the politics. At an agency, you're dating. You show up, you learn the product fast, you do your best work in a compressed timeframe, and then you hand it off and never see it again. Sometimes the client builds what you designed. Sometimes they don't. You usually don't find out which.

Our agency, Canopy Digital, has about 25 people. I lead the UX team, which is me, two mid-level designers named Kris and Ava, and a UX researcher named Tomás. We work on three to four client projects at a time. Right now I'm on a healthcare portal redesign for a regional hospital system, Kris is doing the UX for a B2B marketplace, and Ava is on a nonprofit donation platform. Tomás floats between projects doing research.

Walk us through the healthcare project.

So the client is a hospital system in New Jersey. Four hospitals, about 6,000 employees. Their patient portal is a nightmare. Built in 2019 on a custom CMS. It has appointment scheduling, bill pay, test results, messaging with providers, and a pharmacy refill feature. All of it looks like it was designed by someone who had never used a website. Which, when I saw the original vendor's portfolio, might actually be the case.

We won the project in a competitive pitch. $180,000 for the full redesign, which covers discovery, research, information architecture, wireframes, visual design, a component library, and a prototype for usability testing. My role is leading the UX strategy, doing the IA, and overseeing Kris on the wireframes. The project is sixteen weeks. We're in week nine.

The first four weeks were discovery and research. Tomás ran interviews with twelve patients and six staff members. He also did a heuristic evaluation of the existing portal and benchmarked it against MyChart, which is the Epic patient portal that most hospitals use. The findings were clear: patients couldn't find test results (buried under three navigation levels), bill pay required logging in twice because of a broken SSO implementation, and the messaging feature had a 72-hour response time that was never communicated to patients, so people were sending messages expecting a same-day reply and getting frustrated.

I presented the research findings to the client. The room had seven people: the CIO, the chief nursing officer, the VP of patient experience, two IT directors, the marketing director, and the project manager from their side, a woman named Claire. I walked through the data. Showed the task completion rates. Showed the benchmarks against MyChart. Showed quotes from patient interviews. The CIO, a man named Dr. Reddy, nodded through all of it. At the end he said, "This is very thorough. Can we also add a wellness content section? Our marketing team has been producing health articles and they need a place to put them."

A wellness content section. I just spent twenty minutes showing him that patients can't find their own test results and his first reaction is to add more content. This is agency UX. The research doesn't drive the decisions. The research is a thing that happens before the client tells you what they actually want.

What did you do?

I said, "We can absolutely explore that. Let's prioritize the core patient tasks first and then layer in the wellness content in a way that doesn't compete for attention." Which is designer for "no, but I'll find a compromise." Claire caught my eye across the table and gave me a very small nod, which in client management language means "I know, just go with it."

The wireframes are where it got really interesting. I redesigned the navigation to surface the four most common tasks: appointments, test results, messages, and bills. Put them in a horizontal bar at the top of the dashboard. Big, clear, labeled. Tested it with Tomás using a prototype and six recruited patients. Average task completion time dropped from 47 seconds to 19 seconds. That's a genuine improvement. I was proud of it.

Then the CIO's feedback came back. He wanted the wellness content section moved to the top of the dashboard, above the task bar. His reasoning: "We invested a lot in this content and we want patients to see it." I explained that putting promotional content above functional navigation would increase task completion time and likely frustrate patients who are trying to quickly check a test result. I had the data. Tomás had the recordings. It didn't matter. Dr. Reddy said, "Let's try it my way and see how it goes."

We revised the wireframes. Wellness content at the top. Task bar pushed below the fold on mobile. I documented my objection in the project notes because I've learned to always leave a paper trail. When the portal launches and the task completion times are worse than the prototype, I want there to be a record of why. Not to say "I told you so." To protect the agency from blame when the client's decision produces the outcome I predicted.

Is that common? Clients overriding research?

I've been at this agency for five years. We've had, maybe, 40 client projects in that time. I can think of three where the client followed the research without significant overrides. Three out of 40. The rest, the client took some of our recommendations and ignored others based on internal politics, executive preferences, or "we've always done it this way." And that's fine. It's their product. They're paying us. But the thing nobody tells you in design school is that the job isn't designing the best solution. The job is designing the best solution the client will accept. Those are different things. And the gap between them is where most of your emotional energy goes.

Tell me.

You never see the impact. In-house designers ship something and they can watch the metrics. They see if it worked. They see users using it. At an agency, we hand off a Figma file and a component library and a 40-page design spec, and then the engagement ends. The client takes it to their development team. Maybe they build it exactly as designed. Maybe they cut corners. Maybe they redesign half of it internally. I don't know. I have dozens of projects in my portfolio and for most of them I have no idea what actually shipped.

The hospital portal project will end in seven weeks. I'll hand Claire a beautiful prototype and a detailed spec. And then I'll move on to the next project and I'll never know if patients can find their test results faster or if Dr. Reddy's wellness section is blocking the navigation on every phone in New Jersey. I'll just never know. Ava, who's younger, she finds this freeing. "Not my problem after handoff," she says. I find it hollow. I want to know if the thing I designed made someone's experience better. Most of the time, I don't get to find out.