警惕AI合成研究带来的虚假进度，主张先做人类发现再让AI加速

When speed disguises itself as progress.

I distinctly remember my father driving the speed limit down a two-way street in the Bronx when a car swung out from behind us and cut into our lane with a few feet to spare. It wasn’t the first time, and whenever it happened, I’d anticipate his favorite phrase, delivered with zero road rage, “Going nowhere fast.”

Twenty seconds later, we rolled up to a red light, with the car that cut us off sitting right next to us. One question that stayed with me as a curious 12-year-old: “Did they notice?” Did the driver notice that, after all that effort to get ahead, their reward was a red light? Did speed feel like progress to them?

Speed that feels like progress

Drivers act on the information they have and make quick decisions. Empty lane. I can go around and make the next light. The reality is that many traffic lights run on a timed sequence. Beating one light will often get you to the next red light sooner. The driver who cut us off will almost always remember the pass, not the light. The cost will not appear where the shortcut was taken, but will show up later. By then it’ll be easy to miss what caused it.

Today, product teams are in that lane. For decades we’ve leaned on a tidy rule, GIGO (garbage in, garbage out). It assumed the garbage was obvious. With AI, it isn’t. Garbage goes in and comes out polished, making “beating the system” look like winning. AI can’t weigh what’s true for your users; it predicts what’s likely. Feed it your own data (interview notes, support tickets, instrumentation data), and the polish has truth underneath it. Feed it a guess, and it’ll output a guess with confidence.

Atlassian’s State of Product 2026 report found that product managers gain nearly two hours a day with AI, yet most still feel stuck in reactive mode, and 84% have concerns their products won’t succeed. Speed increased. Confidence did not. Faster output isn’t the same as assurance that you’re building the right thing.

When AI takes the wheel

Drivers who cut through traffic are under pressure, and an opening looks like an opportunity. Starting with AI works the same way. Ask it for user needs, customer experience maps, and personas, and you’ll have results in minutes. Results that can leave you with false confidence that you’ve found the exact problem you’re solving for. Defining a problem solely within an LLM’s capabilities lets AI do the heavy lifting based on averages, preexisting biases, and general patterns of what’s been written about the thing you’re trying to solve. And the output is often opaque, forcing teams to trace back why conclusions emerged or what assumptions shaped them, frequently hitting a dead end.

This is top-down thinking, and it doesn’t address your customer’s pain today. Relying on AI before meaningful design discovery can be tremendously costly. It eats up engineering and design time, causes organizational toil for product teams, and creates disruptions that show up much later. In high-stakes areas like hiring, fintech, lending, and healthcare, it can cause great harm.

Bottom-up thinking begins with humans. It involves research to define a problem and understand the systems connected to it, with all of their interdependent parts. It’s messy work, like mapping how a need links to complex networks and processes orbiting around it. It let’s teams be wrong early, when it’s cheap. It’s a route that unpacks what’s unique and specific to your users. This is where AI becomes useful, by processing your users’ needs once you’ve observed them.

The synthetic research trap

In Thinking in Systems, Donella Meadows unpacks a trap called ‘rule beating’, following the letter of a rule to circumvent its purpose.

She highlights this with a Calvin and Hobbes strip by Bill Watterson:

In the comic strip, Calvin tells Hobbes he’ll do ten good deeds daily until Christmas so Santa goes easy on him. When Hobbes points out Susie (his nemesis) is “coming this way,” Calvin decides he’ll start tomorrow and do twenty a day.

Calvin isn’t trying to be benevolent. He hopes to catch up on a year of bad behavior to look good for Santa.

Synthetic research (AI-generated) participants can work the same way. One of the most widely cited principles in UX and human-centered design is to understand your users before you build. Synthetic personas let teams check the research box without meeting a single user.

“Research isn’t just about avoiding the average. It’s the only way to get the newest answer.”

When NN/g re-ran three of its own studies using AI-generated participants, it found the answers were too shallow to be helpful. In one study, the synthetic participants claimed they had completed each course. The research looked complete, but the answers were too good to be true.

In a 2026 User Interviews survey of 150 researchers, 81% used AI regularly in their work, but only 8% used it to simulate participants. Their biggest concerns were the quality and accuracy of insights (88%) and stakeholders overly trusting AI-generated findings (79%).

The newest answer lives in the field.

Your users’ behavior is the newest and truest information that you have. Their workarounds from last month, the rage clicks that began after the last release, net new needs that started to bubble up this quarter after industry shifts. They exist only in the field. Your product’s newest nuances won’t reliably surface in any training data. Research isn’t just about avoiding the average. It’s the only way to get the newest answer.

Meadows’ way out isn’t adding more rules. It’s redesigning them so that people’s efforts go toward the goal instead of around it. For product teams, it means measuring whether we understand our users, not whether we produced a persona or archetype. A research finding can trace back to something tangible, an interview or a support ticket.

What discovery can reveal

Consider a product team asked to speed up the permissions workflow in an admin console. To move quickly, they prompt AI to create an admin persona. The persona is convincing; busy, technical, and frustrated by too many clicks.

The obvious solution follows:
1. Bulk actions
2. Fewer confirmations
3. Single click to apply changes across the organization

Then a designer, PM, and developer spend a week with five real admins, and a completely different theme emerges. They want to move faster, but speed isn’t their biggest worry. Mistakes are. One wrong change can lock hundreds of people out of their tools or give the wrong group access to sensitive information.

They don’t need fewer steps. What they need is confidence:
• A preview of who a change will affect
• A record of what changed and when
• An easy and clear way to undo

With these in place, bulk actions stop being a risk and become the speedup that the team asked for.

The AI persona wasn’t wrong that administrators are busy. It was average. It described what admins in general say, not what these administrators risk. Building on personas alone, the team would have shipped a faster way to make costly mistakes, and found out months later through support escalations and lost trust.

Discovery did not slow the team down. It gave AI detail to work with. Once the team had transcripts and a quarter’s worth of support tickets, the LLM ranked failure scenarios, drafted audit-log requirements, and generated concepts for previews and undo flows. With the same LLM, the input was now grounded in what actual customers are experiencing. As a result, they built something the admin (at the center of their product) actually values.

“…your competitors don’t have exactly what your users told you”

Discovery and research first, then accelerate

Speed is never the problem. Rule beating is. Once humans have begun the work, AI becomes a powerful accelerator. It synthesizes interview notes, spots patterns, generates concept variations, and sharpens questions you can bring to the next round of research. The difference is that it’s working from your users.

Discovery gives you two advantages over teams racing toward the next light:

1. You stay out of their pileup: Unvalidated work drains teams with costly rework, organizational toil, and disruption after shipping a feature. Teams doing discovery aren’t in that collision.
2. You expose their blind spot and see what they can’t: Every competitor has access to the same models, and anyone can quickly spin up a product spec and render an outcome in seconds. The real advantage is that your competitors don’t have exactly what your users told you.

To this day, my father has never won a race to a red light. He’s also never been in an accident. Decades of driving throughout the metro area, and not a single pileup. He isn’t slow. He just knows how the road works.

Real leverage today doesn’t come from flooring it with every new AI capability. It comes from anchoring the tool to what you’ve learned from your users and understanding the road beneath you. That’s how you get where you’re actually trying to go, and take your customers with you.

They will notice.

Originally published October 19th, 2026
Over the past decade, I’ve focused on designing product experiences for developers within multidisciplinary teams. I’ve led design for IaC adoption, incident management, and observability within socio-technical environments.

Resources:

APA: Meadows, D.H. (2008). Thinking in Systems: A primer. Chelsea Green publishing.

https://www.nngroup.com/articles/synthetic-users/

• State of Synthetic Users | User Interviews
• State of Product Report 2026 | Atlassian
• State of Product 2026: Key findings from 1000+ product teams
• Four things we learned from Atlassian's State of Product 2026

Illustrations remix with Rounded bevel icons by Tristan Free: Figma Community