Why discovery still matters in the age of AI
Historically, I used to pitch investment in early UX work as a cost-saving effort. Engineering time and resources were the most expensive assets a company possessed. You couldn’t afford to build the wrong thing, so you invested in discovery to ensure the target was correct before firing the arrow.
Today, the math has changed. With the rise of autonomous AI coding agents like Antigravity, Cursor, and Claude Code, the financial cost of engineering is plummeting. You can spin up a working prototype in an afternoon. The friction of going from idea to functional software has practically vanished.
But while the financial cost of building the wrong thing has dropped, the psychological cost has not. There is a hidden, cognitive toll to skipping the ideation and discovery phases. When we move too fast, we fall victim to design fixation. We harden our ideas too early and lose the ability to pivot.
The trap of Design Fixation
The psychological cost of speed is the cost of hardening your ideas early. When an idea remains on a whiteboard or in a Figma file, it is malleable. We are open to criticism. We are agile. But the moment an idea becomes solid, our brains shift.
Researchers examining the Role of Sunk Cost in Engineering Idea Generation use a brilliant term for this: Design Fixation. In an experimental study by Viswanathan et al., researchers tested how the time and effort spent building physical prototypes affected innovation. They divided participants into groups: one group only sketched ideas, another built models with easy-to-use metal materials (low time cost), and a third group built models with plastic materials that required high time and effort.
The results were striking. The participants who spent the most effort building the plastic models generated ideas with significantly less novelty and variety. The study concluded that prototypes themselves don’t cause fixation. It is the sunk cost of the effort invested that limits a designer’s willingness to explore alternatives.
Even when the financial investment of AI coding is low, the emotional and cognitive investment of seeing a functional prototype triggers this same sunk cost fallacy. We become subject to confirmation bias. We start looking for data that proves our creation is right, rather than data that proves our initial idea was wrong. At the exact moment a team needs to be accepting of new information, they dig in their heels.
Design Science: Prototyping as inquiry
We can look to the academic framework of Design Science to structurally enforce discovery when going straight to code feels frictionless.
At its core, as outlined by researchers like Paul Johannesson and Erik Perjons, Design Science is a process of “nested problem solving.” It distinguishes between solving practical problems (improving a situation for a stakeholder) and solving knowledge problems (learning something new about the world).
The framework offers clear advice for teams: treat practical problems as engineering tasks that require changing the world (building an artifact), but treat knowledge problems as research tasks that require observing the world (empirical testing). You cannot solve a knowledge problem just by building more code; you have to stop and measure.
In practice, Design Science relies on an iterative design cycle. You design an artifact to solve a problem, but you treat that artifact as a method of inquiry. The prototype is not the answer; it is the question. By adopting a design science mindset, teams use rapid prototyping to promote empirical, validated learning. You build quickly, but you do so explicitly to test and break your assumptions.
Speed to MVP = speed to confirmation bias
If we view it through this lens, the original Lean Startup philosophy was simply an extension of design science thinking. The concept of a Minimum Viable Product (MVP) was introduced as a means of maximizing validated learning about a business idea with the least amount of effort and time invested. The MVP was never the end destination in and of itself, rather a quick stepping stone to learning.
But teams trying to follow the MVP philosophy often fall victim to design fixation. Studies like Lean Startup Orientation: Empirical Evidence on Venture Success, show how rapid prototyping reduces uncertainty, but also warn that confirmation bias leads startups to misinterpret test results. When you view the MVP as the product, you twist user data to validate the code you already wrote.
Today, because AI can build an MVP so quickly, the problem is exacerbated. Teams are moving even faster towards something they feel is a solid product when in fact they are working with an untested, unvalidated, concept.
Repositioning the value of early UX
This increased speed of development also fundamentally changes the power dynamics of the modern product team. Historically, UX could gatekeep bad ideas because engineering was an expensive, scarce resource. Now, founders and product managers can bypass engineering entirely and build the prototype themselves in a weekend. Without the friction of engineering costs, UX must shift their value proposition. You can no longer pitch discovery as a way to save engineering time. You must pitch it as a way to save market and reputational risk. UX must advocate for discovery by showing that while building is cheap, launching something nobody wants still destroys brand equity and user trust.
This rapid onset of design fixation is exactly why the concept of the Minimum Viable Experiment (MVE) is so critical. The MVE helps reframe the purpose of the MVP. An MVE is not a product; it is a probe. It should be considered a strictly “codeless” way of testing an idea, an experiment designed to test the single, riskiest assumption with minimal setup. For example, at Intrinsic over the past year, our UX team has been helping product teams build out storyboards as a practice of mocking up ideas for product concepts. This allows us to get early feedback before any real prototype has been developed. By separating the experiment from the product, teams are forced to stay in the discovery mindset long enough to actually learn something. And when a teammate argues that building an MVP with AI is so fast that launching it should just be the experiment, we must remind them of the psychological toll: the MVE isn’t there to save us time anymore. It is there to protect us from falling in love with our own code.
Strategies for Design Science in the age of AI: Scenario-Focused Engineering
The very AI tools that push us into creating functional prototypes too soon also offer an unprecedented opportunity to practice good design science, if we use them right. Because iteration is now so cheap, we can run empirical tests and pivot faster than any previous generation of engineers.
To do this, we need frameworks that anchor us to the user rather than the code. Popularized by Microsoft, Scenario-Focused Engineering (SFE) is a customer-centric methodology that shifts teams away from building technical feature lists and toward designing end-to-end user experiences. SFE relies on fast feedback loops and scenarios. It is the perfect framework for modern AI development practices because when an AI agent can build a feature instantaneously, you need a system that forces you to define the human scenario before you unleash the AI on the technical execution.
Here is what a modern, AI-augmented SFE practice could look like:
- The Interrogation Prompt: Before generating any code, use AI agents to aggressively challenge your core premise. Ask the agent to play the role of a skeptical user or a competing product manager. Force the team to generate three alternative scenarios before writing a single line of code.
- The “Disposable” Milestone: Treat the first AI-generated prototype as explicitly disposable. Keep it outside the production environment entirely. Set a rigid team rule: “we always throw away the first one.” To enforce this, design the prototype with deliberate visual friction. Tell the AI agent to explicitly watermark the interface with “TO BE THROWN AWAY,” design it entirely in black-and-white, or use a generalized wireframe design system. By making it visually obvious that the prototype is not final, you add friction to any attempt to push it to production without proper review, directly combating design fixation.
- Bias-Check Reviews: Integrate methods of investigation at specific points in the product development lifecycle. We can systematically check for bias using the very tools that helped us build the prototype. After a user testing session, feed the raw transcripts to an LLM alongside your product team’s summary of the findings. Prompt the AI to act as an objective third-party auditor: “Identify any instances where the team’s summary dismisses negative feedback as user error, or highlight data points in the transcript that contradict the team’s conclusions.”
However, we must anticipate the messy human reactions to some of these strategies. When a team is dug in, having a machine tell them they are biased can spark hostility. Facilitating this requires positioning the AI not as an accuser, but as an impartial mirror. The AI can be impartial precisely because it is unaware of company politics and does not have any real desires in and of itself. To make this work, UX teams must establish this framing at the earliest possible time in development. Talk to the team about addressing confirmation bias and sunk cost fallacy as a core part of the way you work together. Pre-frame the review session by saying, “We know we are too close to the code, so we are having the AI stress-test our conclusions.” By shifting the critique to the AI, we can safely facilitate a discussion about uncomfortable data without triggering a defensive argument between teammates.
The enduring value of discovery
I have worked as a UX Researcher for a long time. In all those years, across countless projects and product teams, one truth has remained absolute: I have never conducted a study that didn’t get a reaction. However, depending on how built-out the product was, the team’s reaction to that research changed drastically. Teams who received disappointing results on a loose wireframe were grateful for the data and immediately got to work on the next idea. Teams who received disappointing results on something that was nearly fully built would react in ways typical of confirmation bias: denial, discomfort, sudden disinterest, and rationalizing away the negative feedback as “user error.”
My strategy for getting in front of team confirmation bias has always been to work with them earlier in the design process. Now AI has radically compressed that timeline, shrinking the window from weeks after initial product effort is launched down to just a couple of days. This is why we must continually reframe necessary product discovery work. It is no longer about saving engineering time. It is the only way to mitigate the massive market and reputational risk of building the wrong thing at warp speed.
The barrier to writing functional code has never been lower. But speed of execution is useless if we are running in the wrong direction. We must embrace AI for its ability to build quickly, but we must fiercely defend the discovery phase. If we don’t, we will just find ourselves building the wrong thing faster than ever before.
Recommended reading
- Lean Startup Orientation: Empirical Evidence on Venture Success (thesis) — Empirical evidence on how rapid prototyping reduces uncertainty, and the dangers of misinterpreting test results in early startups.
- An Introduction to Design Science (book)— A foundational overview of using artifacts and prototypes as methods of inquiry.
- Design Science Research: A Simple Introduction (article)— A great, mile-high overview and introduction to Design Science.
- Role of Sunk Cost in Engineering Idea Generation (article)— An experimental investigation into design fixation and the sunk cost fallacy in prototyping.
- Scenario-Focused Engineering (book)— Practical guidance on using early prototypes to facilitate course corrections and maintain customer-centricity.
- The MVE: Minimum Viable Experiment (article)— A breakdown of why shifting from MVP to MVE helps entrepreneurs test ideas without the pressure of building.
The psychological cost of moving too fast was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
This post first appeared on Read More