Testing the hard parts first

Most usability testing happens on the easy parts of a product. This is not a failure of intent. It is a consequence of what a clickable prototype could affordably contain.

A designer could wire a linear happy path through a flow in an afternoon, and the interactions that genuinely decide whether enterprise software works, which are the bulk edits, the conditional forms, the filtered tables and the multi-step approvals, cost days of prototyping effort each. So those got tested after they were built, when the cost of changing them was highest.

Nielsen Norman Group published on this shift in September 2026, and the observation is a scheduling one. AI prototyping tools now make fully interactive versions of complex interfaces cheap enough to produce during discovery. The interactions that used to be deferred can move to the front of the process.

Prototyping the interaction rather than the screen

The distinction matters more than it sounds. A screen prototype answers whether a person understands what they are looking at. An interaction prototype answers whether a person can complete a task when the system responds with real behavior.

Enterprise workflows fail almost exclusively in the second category. A user understands a data table perfectly well and then cannot work out how to apply a filter to a selection rather than to the whole set. A user reads an approval screen correctly and then cannot tell whether their submission went to their manager or to compliance. None of that surfaces in a static walkthrough, because the participant is narrating what they expect to happen instead of finding out.

Watching recovery instead of guessing at it

Three things change once participants are working with real behavior during discovery.

Recovery becomes observable. A participant who makes a wrong selection and then has to undo it will reveal whether the undo path exists and whether they can find it. Static prototypes hide this completely, because a wrong click in a static prototype simply does nothing.

Error and empty states get tested. These are the states enterprise users spend a substantial share of their time in, and they are almost never included in a hand-built prototype because each one is a separate artifact to produce.

Quantitative measures become available earlier. Time on task and completion rate only mean something when the task can actually be completed or failed. Moving working prototypes into discovery moves those measures ahead of build, which is where they can still change the design.

Controlling for what the tool generated

The method carries one discipline requirement. A generated prototype arrives with defaults that nobody chose, and participants will react to those defaults as though they were decisions.

The practical control is a pass over the prototype before the session, separating the things that are part of the test from the things that are incidental. Interface copy is the usual offender, because generated microcopy is fluent and non-specific, and a participant's confusion about a label that nobody intended to ship is a wasted session. Layout density, default sort order and pre-filled field values need the same check.

Moving the schedule

The sequencing argument is straightforward on cost. An interaction problem found during discovery is a prototype revision. The same problem found after build is a sprint, a regression test and a release.

On a six week discovery engagement, building working versions of the three most complex interactions in a product and testing them with eight participants is a realistic scope. That was not true two years ago. The work to do this month is picking those three. They are usually the ones the engineering team argues about, the ones with the most conditional logic, and the ones that generate the most support tickets in the current product.