All posts

Start with research, not another screen

A polished mock that feels falsely certain next to unfinished research notes.

A finished mock is not evidence

You can generate a plausible screen in an afternoon. That used to take a designer a week. The cost of looking finished collapsed. The cost of being wrong did not.

We already wrote about why context-right beats vibe-coded, and about the last mile after the demo. This is the chapter before both: research. Not another discovery-phase explainer. The cheap screen is the new way teams skip it.

Observed work and research notes against a screen that looks finished.

Why the screen feels like a decision

Kormoan, a product studio writing about discovery, puts the mechanism plainly: “Once an assumption becomes a polished prototype, it starts feeling more certain simply because people can see and interact with it.” A mapped workflow and a few customer conversations often reveal more than weeks spent making an uncertain idea look finished.

That is the vibe-coded failure mode. The UI looks like progress. Stakeholders stop arguing. Engineering starts quoting the last mile. Nobody has checked whether the work is the work.

Skipping research is not faster

Laura Klein, interviewed by Liliana Camacho for Userlytics (3 Jul 2026), put the speed argument backwards: “you’re not moving faster. You’re just shipping the wrong things faster.” Klein again: “Almost any kind of research will actually end up speeding you up.” Camacho’s writeup, not Klein, is the two-month feature that misses the need as a complete loss: research that stops that build is still a gain.

You still pay for discovery. You either pay it in interviews, or you pay it in production software: onboarding that has to be redesigned, a workflow that does not match how people actually work, a last mile built around the wrong exception. When you skip discovery, uncertainty does not disappear. It moves downstream, where changing your mind is more expensive.

What a first research pass actually looks like

It is not a six-week product. It is enough work to know which assumption would be expensive to be wrong about.

A first pass usually looks like this:

  • Watch the current job, not the imagined app. Month-end, the handoff, the exception that already lives in a spreadsheet.
  • Talk to the people who do that job. Not “what features do you want.” What they do when the happy path breaks.
  • Map the journey they already run. The tools they open at 8am. Where data actually lives. Who owns the write.
  • Write down the assumption the pretty screen is treating as decided. Then try to kill it cheaply.

User experience and user research at Sentral is that work: interviews, journey mapping, usability, before you commission the build. Custom software still starts with discovery and strategy on purpose. Generating the UI did not retire that step. It made skipping it look productive.

If you want to see the shape of the work, the pages are public: PremierGR, Mi, Atomic UXR. Read the pages. Do not take this article as their results.

When it is fine to skip

Skip a research pass when you are still throwing the prototype away, and you know it. A spike to see whether a library will talk to the thing you already run is not a product. A click-through to sell the idea internally is not a product either, as long as nobody treats the mock as the spec.

Do not skip it when the screen is becoming the system. When it has to sit in the tools people already open. When someone other than the builder will use it under pressure. That is when you are choosing a last mile. Research is how you know which one is worth running.

The cheaper place to change your mind

A finished mock is not evidence the work is understood. Research is the cheaper place to change your mind.

If the mock already looks like the product, talk to us before you spend the last mile on it.

Questions

Why not start with screens if generating them is cheap?

Because a polished screen makes an untested assumption feel decided. Generating the UI is cheap. Rebuilding the last mile around the wrong job is not.

What does a first research pass actually look like?

Watch the current work, talk to the people who do it, map the journey they already run, and write down the assumption the screen is treating as settled. Then try to kill that assumption before you hire the last mile.

When is it fine to skip?

When you are still testing the idea and you are willing to throw the prototype away. Once the demo is becoming the system, you are choosing a last mile. Research first.

How does this connect to last mile?

Last mile is architecture, QA, launch, and staying on. Those jobs are expensive. Research is how you decide which of them you are actually buying, instead of finishing a screen that never should have been the spec.