UX Failures at Three Years' Experience: What Training a Designer Who Was Already Good Taught Me

Here's what training a designer with three years' experience taught me about UX failures: they have almost nothing to do with how good you are in Figma. She was better in Figma than I am. I found that out on the first call, when she renamed one of my layers without comment. I didn't comment either. I noticed.

February to May this year. A B2B SaaS that tracks vendor compliance documents for logistics companies, 14 people, a Series A they were still slightly surprised about. Fourteen weeks, two calls a week, one designer called Sarah, and four UX failures I watched her ship with my name on the invoice.

Three years, two agencies, a portfolio you could show investors, auto-layout in her fingers the way I have typos in mine. The founder hired her in January and hired me in February to "make sure it goes well". Founder for: I can't judge design work and I'd like someone else to be responsible if it's wrong. I said yes because the rate was good and because I'd said that exact sentence myself, about a developer, in 2021.

Three years is the dangerous year for UX failures. Enough skill to make anything look finished, not yet enough scars to distrust finished. I was at my most dangerous at three years too. I have a settings page from that period with forty-one toggles on it, each one requested by somebody important, and it is still live somewhere, and I don't look.

None of the four UX failures below is a craft failure. Each came from something she didn't know about the people using the product, and from nobody telling her to go and find out. For the first fortnight that nobody was me, looking at her screens like everyone else and saying things like "nice". The numbers are roughly right. I round to the nearest one that still stings.

The vendor onboarding flow. Four steps, a prototype, five test users from the founder's network, which meant two investors, the founder's brother and two people who owed him lunch. All five finished, average two minutes fifty. Sarah shipped it on a Thursday with the confidence of someone whose work has just been validated by five people who wanted to be nice to her.

Production had different ideas about data. The first real vendor was "Müller & Söhne Spedition GmbH – Niederlassung Hamburg", 56 characters, and the vendor card truncated at 28, so the ops manager in Hamburg who added three Müller branches saw three identical cards and added them twice more to be safe. Five Müllers, three of them real.

The documents table on day one said "No documents", and about one new user in five read that as "the upload failed" and emailed support to ask. The server error state was still the Figma placeholder, a grey box that said "Error state – TBD". It went live and stayed live for nine days, eleven people saw it, and one of them replied to it, asking who TBD was. I have the email. I've thought about framing it.

Roughly a quarter of sessions in the first month hit a state Sarah had never drawn. Not one of those users filed a bug. They asked support whether the thing had worked. That's what users do instead of complaining, and from inside a dashboard it reads like silence.

Her first response was "but it tested fine", and it had, and I'd sat in on two of the five tests nodding, so this one has my fingerprints on it as well. The test had perfect data. My rule since, and hers now: the ugliest real record on screen before anything else gets drawn. If the export has a 56-character vendor with an umlaut and a branch in brackets, that vendor is your hero image. Placeholder content hides the problem, and lorem ipsum has never once had an umlaut.

The PM came with a ticket: "Users can't find their expiring documents. We need filters." Sarah built filters. Fourteen of them, grouped, with a Clear All and a little count badge, three weeks of work that looked like a product in its own right.

The PM was delighted. So was I, for about a day; it was a very good panel. The PM was not wrong, either. He was describing a symptom with the confidence of a man who had read it in a support ticket.

After six weeks the panel was opened in about 4% of sessions. Of those, nearly everyone used one filter, "expiring in 30 days", and nothing else. The other thirteen are still there, the way a hotel room has a Bible, and about as often opened.

The actual problem was the default sort. The documents list came up alphabetical by vendor name, because that's the order the database returned it in and nobody had argued. The user who logged in wanting to know what expires this week scrolled past Aardvark Freight to find it.

Changing the default to "expiring soonest" took a developer about 40 minutes. Tickets containing "can't find" dropped by around two thirds in the following month. The filter panel is still there. It's lovely.

What I asked Sarah to do, and what she now does before touching any ticket, is one question to whoever wrote it: what did the user do right before they got stuck? The PM thought for a moment and said "they scrolled". There was a short silence in which a three-week filter panel became a 40-minute sort order, the cheapest UX failure in this post to fix, and I did not say anything, because I have built the filter panel too. Mine was a date picker with eleven presets, one of them "last fiscal year", for a product whose users were wedding photographers.

Add-a-vendor. Nine fields, in a modal, because the design system said "quick create = modal" and the design system was written by someone with a two-field form in mind who is no longer at the company. Sarah followed it with the loyalty you only have to rules you didn't write. I'd have followed it too, at three years. These days I ask who wrote it, and then follow it anyway and feel better.

Desktop completion came in around 58%. Bad for a nine-field form, not a headline. Mobile completion was around 31%, and about 44% of the ops managers were on phones, on a warehouse floor, with gloves.

On a phone the modal scrolled inside the page scroll, so the Save button lived below a fold that was itself below a fold, and the gesture that should have reached it closed the modal instead. Nobody on the team had opened the product on a phone since the investor demo, which had been on an iPad, held sideways, by a man who was not going to add a vendor.

The fix for that UX failure was a page. Not a redesign, a page: the same nine fields with the floor under them. Mobile completion came up to about 52% in three weeks, and support stopped getting the message "I think I added it?", which had been arriving twice a day, question mark included.

What Sarah wrote down afterwards, in her own words, was "the design system is a dictionary, it doesn't know what I'm trying to say". I'm quoting it because it's better than my version. She said it in a review, in front of the PM, slightly too loud, and then looked across at me to check. I looked at my notes. That was the first time I thought the training might take.

The document review flow was Sarah's best work on the project. Clean, fast, three screens. She could finish it in about 40 seconds, and I watched her do it, and it was a pleasure, the way watching someone parallel park in one go is a pleasure.

The first 30 session recordings had a median of four minutes ten. The stall was the "assign reviewer" step, a dropdown of 212 names in alphabetical order, where the user wanted the same reviewer as last time and had to find her under K every time, on a phone, with the glove. One user typed the name into the search field above the dropdown, which was the vendor search, and reviewed the wrong document, and then reviewed it correctly, and then emailed to ask if the first one counted.

Sarah's reading of the recordings was that the users were slow. She said it with affection, the way you'd describe a parent on a new phone. I said the one sentence I have for this, which I've said to eight or nine designers and never easily: you are the only person on earth who has used this four hundred times. She said "three hundred and something". She was not wrong, and that is the whole problem in one correction.

The fix was remembering the last reviewer and defaulting to it, plus a search that searched the right thing. Median time to complete went to near enough one minute fifty.

That one is not a UX failure at three years' experience. It's a UX failure at any experience, mine included, and the only cure is watching strangers, or pretending to be one, which is what the fake persona test is for. On my projects "slow" is a word you earn by being Edith for an afternoon first. I don't announce the rule. People work it out when I don't answer.

Three of the four UX failures got fixed inside the fourteen weeks, because three of the four were habits, and habits fit in fourteen weeks.

The habits, in the order they stuck. Twenty session recordings before any redesign is allowed to open Figma. The first one she watched, she narrated like a nature documentary, "and here he's going for the filter, no, he's seen something", and by the twelfth she had gone quiet and started writing timestamps. That's the moment it works. It's also the moment I stop being needed, and I have never found a dignified way to feel about that.

The ugliest real record on screen from the first frame. One question back to the person who wrote the ticket. And a standing Friday where the flow goes to someone from sales, who is paid to be impatient, with no instructions beyond "add a vendor", and Sarah sits on her hands. The first Friday she lasted ninety seconds before explaining the button.

The fourth failure, the one under the other three, was that she said yes in reviews. A VP asked for the primary action moved into a menu "for cleanliness" and she moved it, in about twenty minutes, nicely, with a transition. It stayed moved for six weeks while the core action fell by about a fifth, and her Figma file looked immaculate the whole time.

That is the kind of UX failure that leaves data fingerprints and no Figma symptoms, and the file is the last place to look.

That one did not fit in fourteen weeks. The day she said "no, that puts the main action three clicks down, here's the recording" was in September. I had been off the project since May. I found out from a Slack message that said "I said no", then a screenshot, then nothing.

I was on a train. I read it four times, put the phone face down on the table and looked out of the window for a stop and a half. I didn't reply until the next day, and then only with a thumbs up, because anything longer would have been about me. It is the only message in this job you can't invoice for, and the one I'd keep.

The cost is real and nobody prices it. Around five hours a week for fourteen weeks, call it 70 hours, most of them spent watching recordings next to someone instead of doing the work myself. Doing it myself would have been faster. I haven't worked out by how much and I'm not going to. The founder paid for one designer and got about one and a third, and paid me at a rate that assumed I was designing, and for long stretches I was sitting next to someone, not saying anything, waiting for her to see the thumb.

The second cost is the one founders don't like hearing. Training only takes if the designer is allowed to ship failures. All four of Sarah's UX failures went live. A founder who wanted zero failures in those fourteen weeks could have had it, by having me do the work, and would have ended the quarter with the same designer he started with and a fourteen-week gap in her confidence.

I've seen that version. It's a UX/UI design engagement that looks cheaper on the invoice and costs a hire eighteen months later.

Training doesn't fix taste. She had that already and I had nothing to add except opinions about type sizes, which she ignored correctly. It doesn't fix a team that reviews pixels either. That's a team problem, it outlives any one designer, and if the review is "does this look right" it will keep passing the flow that tested clean with perfect data for as long as the company exists. No amount of coaching a three-year designer changes who is in the room.

Four questions that catch UX failures at three years before they ship. If the designer on your SaaS product design can answer all four about a flow before it ships, the pixels are the least of your problems, and they're the part she's already good at.

1. Has the ugliest real record been on screen, with its umlaut, since the first frame?
2. What did the user do right before the ticket got written?
3. Has anyone opened it on a phone since the demo?
4. How long does a stranger take, measured, not guessed, and what do they call "slow"?

Sarah passed all four by May. The fifth isn't on the list, because I don't know how to teach it in a sprint and I've stopped pretending I do: in September she said no to a VP and sent him the recording. I'd like to take credit for that one. I was off the project by then, and she'd stopped looking across at me to check somewhere around July.