UX design didn’t get easier. It got easier to skip.

Shipping features isn’t the same as shipping UX

With the resources available now, teams often morph into feature production houses, and good user experience quietly drops off the list.

Good UX design, stated plainly: build something usable, that balances what the person needs against what the business needs, for the one actually using it. Product design, product management and engineering are merging into a single loop now that anyone can touch a prototype. That merge is real, and it’s fine. What can’t merge away is the judgment call underneath it, whether this is actually good for the person using it.

Design capacity used to be the bottleneck. Not any more. When a prototype can take minutes, depending on its scale, the backlog empties faster than anyone can work out whether it was worth building. The craft itself did not become less necessary. It became invisible. Skipping it feels like speed, and nobody files a ticket for the research you skipped.

The old cost was the frames and the legwork, not the thinking

For most of my career the expensive part came in two pieces. The first was the artefact: frame by frame in Figma, a prototype if the flow needed one, then an annotation pass so engineering knew what every state did. The frames were never the deliverable. They were the receipt.

The second was the legwork behind the frames, the research done by hand:

• searching tickets, wikis and old threads for what already existed
• finding out who owned an answer, then waiting on their reply
• validating a finding against a second source before anyone would trust it

Both got faster. AI prototyping removed most of the artefact cost: I describe a screen in a sentence and get back a clickable, on-brand version of it. So can everyone else. The legwork compressed too, once search and validation run as a pipeline instead of a manual pass; the pipeline section below shows one. What compressed least is the judgment: framing the problem and deciding what the evidence means, which moves a little faster when the research does but is never skipped. Building that pipeline is the actual skill now, not prompting well once.

Do the preliminary pass, scaled to the problem

I don’t jump straight to building, but the pass scales. Something small and reversible, a label, a default, a one-step flow, can go straight to a prototype and a live test. Anything touching money, stock, or a task someone repeats all day cannot. The cost of being wrong there is paid by people who can’t route around you.

“Good enough for a first version” stopped being a real excuse. If the pass is genuine and it runs fast, ship the version with decent UX already built in, not a placeholder for later. Complexity still sets the pace. Light and reversible work goes straight to a prototype and a live test. Anything with real stakes gets the fuller pass first.

The framework has to be one I actually run, not one I intend to have. On this project the design phases are literal folders, intake through to handoff, each holding that stage’s artefacts. A process you can’t point at is a preference.

Turn the thinking into a pipeline

The thinking all stays. I just stopped doing it by hand.

The signal is repetition. The third time I catch myself doing the same manual work is the sign: it’s not a task, it’s a missing pipeline, and the afternoon goes on the framework instead. I packaged my own research cycle that way, as a plugin I re-run on any new project. The research behind this portfolio came out of it.

Take a hybrid I run often, part product design and part product manager. The old way meant reaching out to a care or success team, asking who owns the answer, and waiting for a reply. Now the routing is written down once, and a single skill returns one linked document with:

• who is affected, and how many
• what they said in their own words, not my paraphrase
• which features it touches
• which tickets it links to
• what the wider user base looks like in the data warehouse

Several of these run while I’m reading the output of the last one, and depending on complexity the whole pass takes minutes to an hour. The debate about whether this just means working more misses the point. When something is running, you’re not idle, you’re free to look into something else: open a side session, ask a question you’re unsure about, learn a domain you’d never had time for before. That’s the reframe. The limit that’s still real: retrieval and linking are solved and the warehouse queries are written and traceable, but pulling fresh numbers still means I go and run them.

Add the layers that try to prove it wrong

Most frameworks stop too early. Take an agent that updates a team’s weekly roadmap sheet. It pulls from every connected tool and platform, audits the work actually done, and leaves the team to review and refine instead of compiling. The usual first build has about three layers. Then someone opens the sheet, calls it inaccurate, or finds one part entirely wrong, and trust in the rest goes with it.

The fix is not a better prompt. It is more layers. After the first pass come harnesses and reviews whose only job is to challenge it and try to prove it wrong. After those come checks that confirm it is right, or at least flag which findings were inferred rather than found. In my view that makes a framework of 6 to 8 layers minimum, not three.

The layers should fit the work. UX research through to a prototype can run lighter harnesses. Building and pushing to production needs different domains covered: security, safety, the users it affects, reliability. Each gets its own check before anything ships, so what reaches production is safe.

Curating, reviewing and refining are the job now

Throughput is not truth. Working this fast is only safe if verification is built into the loop rather than intended.

Curating, reviewing and refining are the core of the work now: curating what goes in and what deserves attention, reviewing what the harness let through, refining the output and the pipeline wherever it slipped. While something runs, I dig into related work, brainstorm improvement areas, read up on adjacent sections, and validate, instead of pushing ahead just because an initiative got written down. If it’s written, that’s a reason to check it, not a reason to build it.

Here is one run against myself. Reviewing nine initiatives, I made every research agent show the source text it was quoting. Some produced it. Others had returned confident summaries with nothing underneath. I graded all nine on that test and quarantined the failures.

Last, I take the findings to the people they’re about, written up so someone else can read them and act on them. Agents can review each other’s work, but a person still has to be the one who signs off. Otherwise the research never travels.