UX research must enter the loop of AI-powered development, NN/G proposes

When an AI agent can implement a feature in an afternoon, the classic research model (study first, only then build) loses practical sense. That's the problem the Nielsen Norman Group (NN/G) raises in an article published on November 13, 2026 by Tony Alicea, who names the proposed solution research-in-the-loop.

The starting point is a shift in economics, not in tooling. For much of software history, building was expensive and fixing a bug after launch cost even more: money, time, customer trust. That's why formative research came before code. With AI agents writing much of the implementation, that math has changed: many teams today pick a direction, ship it, watch what happens, and adjust, because iterating has become cheap.

The problem speed creates

NN/G's text uses a simple analogy: film photography required care with every click, because each exposure cost money and the result only showed up after development. Digital photography replaced that with dozens of clicks, an adjustment, and another click, at almost no cost. Software development with AI agents is going through the same kind of shift: build, ship, watch the dashboard, fix.

The problem is that a dashboard shows what happened, not why. A team might see that users abandoned a flow without seeing what they were trying to do or what confused them. That's the question research has always answered, and it doesn't disappear just because the delivery cycle got shorter. Building the wrong thing quickly is still a failure, just a faster one.

Unlike a bad photo, a bad release reaches real people.

Tony Alicea, article author, Nielsen Norman Group

What is research-in-the-loop

NN/G's proposal starts from an inversion: instead of research always preceding development, it enters the feature's own specification. Before building, research helps define what that release needs to capture. During building, the coding agent implements that capture alongside the feature. After launch, researchers analyze what happened, and the learning feeds the next requirements.

The article organizes this activity into three types, which complement but don't replace one another:

Instrumentation makes evaluation and investigation more efficient, but it doesn't replace independent discovery: it only reveals what it was designed to measure.

What a spec with embedded research looks like

The article offers a concrete example: a help desk product where departments previously had to route tickets through a central queue and now allows direct transfer between them. Because the feature will be built quickly by an AI agent, the team writes, alongside the product spec, a research section that the agent itself reads to instrument the code. Translating NN/G's example:

## Research

What we expect: direct transfer between departments gets the
ticket to the right team faster, with fewer handoffs.

Signs it worked: less time between opening and resolution; fewer
tickets passing through three or more departments; lower average
support cost per ticket.

Signs of trouble: more tickets sent back for review or reopened by
the customer.

What to track: each handoff (who sent it, who received it, wait
time, whether it was sent back), in a simple dashboard grouped by
department, to guide who to talk to.

When to talk to people: if a department sends back a high fraction
of tickets, or they get stuck there, schedule a contextual
interview with that department's team.

With this section, the same agent that implements ticket transfer also builds the event log, the dashboard, and the return-rate question. Research stops depending on a separate queue of engineering time.

It's worth noting the limit NN/G itself draws: this spec isn't a complete evaluation design. It states what to measure, not whether the observed change was caused by the new feature or by seasonality, a staffing change, or another factor. Isolating cause from correlation still requires a comparison group, sample size, and observation period, decisions that remain the researcher's job, not the agent's.

Where qualitative work comes in

Instrumentation only covers what the release was designed to capture: it shows what people did, not why. The article describes three ways to fit qualitative research into the loop, which can run in parallel:

• Cadence: sessions on a fixed rhythm (weekly, for example), not tied to a specific release, to check critical flows and the overall health of the experience.
• Signals: release data or feedback that points to something odd (a department where tickets get stuck, a group that behaved unexpectedly) triggers a round of investigation.
• Decisions: choices that are hard to reverse (pricing, a promise to the customer, handling of sensitive data, a new mental model) deserve evidence before commitment, often via a prototype the agent itself builds quickly.

A team that only follows signals ends up studying only what it decided to instrument, and that's where open discovery remains irreplaceable.

What changes for people who do product and design

For people who design the experience or decide what gets built, the research section now lives alongside UX context and product requirements, as part of what the team builds, not as a stage that delays the build. This requires researchers to be fluent in specs and markdown, have basic knowledge of Git, understand analytics instrumentation (events, cohorts, feature flags, gradual rollout), and know who has access to which data via API or MCP.

The article is clear that this doesn't replace the backbone of the profession: asking good questions, avoiding bias, designing solid quantitative experiments, synthesizing with judgment, and maintaining ethical research practice. An agent can build a study in minutes; the person responsible for the right questions is still the researcher.

Although the article doesn't address accessibility directly, the logic applies to that ground without strain: if instrumentation is born in the spec itself, nothing stops accessibility criteria (screen reader use, keyboard navigation, contrast in new components) from entering as a signal to track from day one, instead of becoming a standalone audit after launch. That's a reading the material suggests, rather than states.

What remains open

NN/G itself admits the model is a proposal, not a closed playbook. Among the unanswered questions: who owns the research section (researcher, PM, both?); how to avoid excessive instrumentation turning into a feeling of surveillance for product users; and what happens to generative and longitudinal research, which don't clearly fit into any of the three types (evaluation, investigation, discovery).

The article ends by suggesting a small first step: map where user signal already exists, write a single research section (hypothesis, success and harm criteria, what to track, when to talk to people), and bring it to the team that will build the next release, before trying to reorganize the company's entire research process at once.