3 UX mistakes we see constantly in startups

CB Insights analyzed 111 startup post-mortems. 35 percent of founders said there was no market need for what they built. 8 percent said the product itself was poor.

Founders are far readier to conclude that nobody wanted it than that nobody could use it.

Mistake 1: shipping with bad UX

You needed signal, so you launched before the UX was ready. Now every number you collect is measuring two things at once, and none of them will tell you which one moved.

Low activation might mean nobody wants this. It might also mean your signup form asks for a company domain before the page has explained what the tool does.

When onboarding confuses people, activation drops. When activation drops, retention has nothing to measure. When retention looks flat, the roadmap gets rewritten around a problem that was never the problem.

Pivots get made on contaminated data more often than founders admit.

So how do you separate the two? Three checks, before you read a single chart:

• Watch five people attempt the core task with no help. Nielsen Norman Group's long-standing finding is that five participants surface around 85 percent of the usability problems in an interface. If most of them stall in the same place, you have an interface problem, not a demand problem.
• Look at what happens after the first success. People who finish the core task and never come back are telling you about value. People who never finish it are telling you about the interface.
• Find the exact drop-off step, not the drop-off rate. A 60 percent fall at one screen is a fixable defect. An even bleed across the whole flow is usually a positioning question.

Mistake 2: keeping designers out of roadmap decisions

Design gets run as a service desk. Work arrives as a ticket with the solution already written into the title, and the designer's job shrinks to rendering a decision somebody else made in a meeting they weren't in.

The real cost lands on the roadmap.

A designer who knows the company is chasing seat expansion this quarter makes different calls than one who's been told to redesign the settings page. The first will argue that the invite flow matters more than the feature that got requested loudest. The second will make the settings page look better.

Designers also hold information nobody else on the roadmap call has. They've traced the whole flow, so they can see when four requested features are actually one, when a "small" addition drags three other screens with it, and which two screens are generating most of the support tickets. That's prioritization data. It only helps if someone asks for it before the quarter is committed.

Plenty of seed-stage teams don't need a full-time designer, and a founder with taste can carry it for a while. Someone still has to hold the user's side of the argument while the roadmap is being set.

What to hand a designer if you want them contributing to what gets built:

• The commercial goal for the quarter, as a number. "Lift seat expansion 15 percent" produces different design decisions than "ship the integrations page."
• The cost of the problems you already have. Support ticket volume by screen, the objection that kills deals, the reason people churn. Designers can rank work by cost avoided once they can see the cost.
• A seat in prioritization, not a brief afterward. By the time scope is locked, the only question left is what it looks like.
• Permission to come back with less. A designer who finds that four roadmap items collapse into one flow has just returned you three weeks, and that only surfaces if they were asked early.

Mistake 3: handing design decisions to AI

A model will return a plausible screen for almost any prompt. Plausible is a low bar when you're building something that doesn't have an obvious precedent, and it's the bar most generated UI clears and stops at.

Generated UI defaults to convention. Convention is fine for a settings page and expensive for the one flow that makes your product different from the incumbent everyone already knows how to use.

The bigger risk is that generated work looks finished, and finished work gets approved instead of critiqued.

A rough wireframe invites discussion. A polished mockup invites a thumbs up. Teams generating UI tend to skip the messy conversation that would have caught the wrong decision, because the artifact in front of them doesn't look like it's still up for debate.

The bottom line

All three mistakes share a shape. A decision gets made on information that looked sufficient and wasn't: a metric measuring two things at once, a roadmap set without the user's side in the room, a screen that looked finished before anyone argued with it. None of these are expensive to fix. They're expensive to discover late.

If you're about to ship and you can't tell whether you'd be testing the idea or the interface, book a discovery call with Koi Studios and we'll help you pull the two apart.

‍