Killing the polish: Overcoming prototyping bias to get the strategic feedback you actually need

Summary

In this article, you'll learn:

• Prototyping bias happens when polished visuals make reviewers assume high confidence, shifting feedback away from strategic decisions and toward surface-level details
• AI has made prototyping bias worse, not better: a five-minute AI-generated mockup looks finished even when the thinking behind it isn’t
• The solution isn’t more polish. It’s intentional lo-fi work that signals “this is a draft” and creates space for the feedback that actually matters
• Joe McLean, Miro’s product lead for the AI canvas, explains why Miro’s internal culture of #badversion is one of the most powerful tools for faster, more honest collaboration
• Lufthansa Group’s Miles & More program used Miro Prototypes to create, validate, and align on the right solution in under a day, without waiting on design resources
• Miro Prototypes gives teams a way to prototype fast and intentionally lo-fi, keeping feedback where it belongs: on the problem, not the pixels

You’ve been in that meeting: the one where your team spends the first 20 minutes debating whether the button should be blue or gray, whether the header font is too bold, whether the spacing feels right on mobile, while the question of whether you’re solving the right problem entirely goes unasked. By the time the session wraps, everyone has opinions on the pixels, and nobody has challenged the concept underneath them — and despite feeling productive, nothing of strategic value actually got decided.

This is prototyping bias in action, and it’s one of the most quietly damaging patterns in product development. When a prototype looks polished, people respond to it as though the thinking behind it is equally settled. They stop questioning the direction and start refining the details, which means the strategic decisions that most need scrutiny, the ones that determine whether you’re building the right thing at all, slip through without ever being properly examined.

Prototyping bias is what happens when a visual looks finished, so people treat it as finished. They stop asking “should we build this at all?” and start asking “should this copy be shorter?” The polish signals confidence. And once confidence is signaled, the hard strategic questions get quietly taken off the table.

It’s always been a challenge for product teams. But right now, in the age of AI-generated mockups that go from prompt to pixel in five minutes, it’s becoming one of the most significant blockers to building the right things.

What prototyping bias actually costs you

The damage from prototyping bias isn’t always visible in the moment: you get feedback, the session feels productive, and people leave with action items. The problem is the feedback you didn’t get; the user flow assumption nobody questioned, the feature scope nobody challenged, the “wait, is this actually solving the right problem?” conversation that never happened because the prototype looked too sure of itself.

When strategic feedback gets crowded out by surface-level reactions, teams build things with confidence and conviction, in the wrong direction. And the further into development you get before that becomes clear, the more expensive the correction.

According to a Forrester Consulting paper commissioned by Miro, organizations lose the most momentum during the Discovery (38%) and Definition (35%) phases of product development, the exact phases where lo-fi prototyping and honest feedback are most critical. Getting this right early isn’t just good process. It’s where project success is determined.

Why AI is making this harder

Here’s the uncomfortable reality: the AI tools that are supposed to make product teams faster are also making prototyping bias significantly worse.

Joe McLean, product lead for Miro’s AI canvas, put it plainly in a recent episode of the How We Work podcast. If you want to go deeper on his thinking about AI, collaboration, and the future of product development, the full episode is worth your time:

“When you design something yourself or draw it yourself, it’s really easy to catch yourself and think, it’s day three — I should maybe share it now. But with AI, it takes five minutes and it’s beautiful.”

That’s the problem. When you labored over a mockup for three days, its roughness was honest. The imperfection communicated something true: “I’m still figuring this out.” When an AI produces something polished in minutes, that signal disappears entirely.

“When you present something with high fidelity, there’s the assumption that it’s also high confidence,” McLean says. The prototype isn’t just a visual anymore. It’s a statement of conviction. And that statement shuts down exactly the kind of exploratory, questioning conversation that discovery work depends on.

The #badversion mindset

Miro has been wrestling with this problem internally for years, and landed on something deceptively simple: a cultural norm called #badversion.

The idea is straightforward. When you share a draft, whether that’s a board, a slide, a sketch, or a prototype, you tag it #badversion. That tag does something important. It’s not an apology. It’s a social permission structure. It tells the people receiving your work: “The thinking is real, but the execution is deliberately rough. I need your reaction to the idea, not the artifact.”

McLean describes how this plays out at Miro: “Bad version is really powerful because it creates a social permission for it not to be finished yet. And especially as AI is collapsing the execution time on everything, building your rhythm toward faster, earlier check-ins is actually a profound aspect of building a more efficient way.”

The #badversion mindset isn’t about lowering the quality of your thinking. It’s about separating the quality of your thinking from the finish level of your output, so that the people giving you feedback can engage with the former rather than the latter.

For product teams, this is transformative. If your prototype looks rough by design, stakeholders and users understand their job. They’re evaluating direction, flow, and problem fit, not button radius.

Why lo-fi isn’t just a technique, it’s a decision

There’s an important distinction here that teams often miss. Lo-fi prototyping isn’t simply “making things rougher.” It’s a deliberate communication choice.

When you share a screen full of gray boxes and placeholder text with the words “this is a rough concept, we want to understand whether the flow makes sense,” you’re doing two things at once. You’re giving people something to react to. And you’re telling them exactly what to react to.

This framing changes everything about the feedback you receive. Instead of “the font feels too small,” you get “I’m not sure why I’d land on this screen before I’ve set my preferences.” Instead of “can we try a warmer color palette,” you get “does this step need to exist at all, or could we skip straight to step four?”

That second kind of feedback is what actually shapes better products. And it’s almost impossible to get once a prototype looks finished.

McLean’s observation extends further: as AI accelerates execution across the board, the decision of how much polish to apply becomes more strategic, not less. You can produce high-fidelity work faster than ever. The question is whether you should, and at what stage. “Building your rhythm toward faster, earlier check-ins is actually a profound aspect of building a more efficient way,” he says. The speed advantage of AI only pays off if teams use it to iterate more, not to produce more polished artifacts earlier.

How Miles & More killed the polish and aligned in under a day

The real cost of prototyping bias becomes obvious when you see what happens without it.

Lufthansa Group’s Miles & More loyalty program faced a challenge that many product teams will recognize immediately. Product managers were responsible for mocking up user journeys and gathering feedback from end users and stakeholders, but design resources were severely limited. Without any way to visually communicate flows and concepts early, alignment took weeks. Solutions moved into development without visual validation. And with development cycles stretching up to six months, discovering that something needed to change late in the process meant expensive rework.

The team adopted Miro Prototypes to fix this. Now, product managers generate mockups directly from website screenshots, gather feedback in real time, and validate solutions with end users before any code is written. The result: the Miles & More team can create, validate, and align on the right solution in less than a day.

Björn Ehrlinspiel, Product Owner at Miles & More and IT Consultant at Netlight, described the shift directly: “I’m way more confident that the things we are implementing for the product are the right things. And I’m way more confident to bring that also in front of management. Miro Prototypes helps me show my vision to the management team of the product.”

That confidence comes from a better feedback process, not just a faster one. By prototyping early and keeping the focus on direction and flow rather than finish, the Miles & More team gets the strategic validation they need before investing development time. Prototyping bias doesn’t get a chance to take hold because the conversation happens at the right moment, with the right level of fidelity.

How to get strategic feedback on lo-fi work

Killing prototyping bias isn’t just about making rougher visuals. It requires actively creating the conditions for honest, strategic input. Here’s how to do it.

Frame the artifact before you share it

Before anyone looks at your prototype, tell them what kind of feedback you need. “We’re testing whether the flow makes sense, not the visual design. Ignore anything that looks unfinished.” This framing does the work that #badversion does culturally: it redirects attention before prototyping bias can take hold.

Name the open questions explicitly

The most useful thing you can put at the top of a prototype review is a list of the specific decisions you’re trying to make. “We’re not sure whether this step belongs in the flow, or whether users would expect to find it somewhere else entirely.” When reviewers know what’s unsettled, they engage with those things.

Invite pushback on the concept, not just the execution

Ask directly: “Does this solve the problem we described? Is there a completely different approach we should be considering?” Many reviewers won’t volunteer this kind of challenge unless explicitly invited. They’ll assume that if you’ve built something, you’ve already decided to build it.

Use your prototype as a conversation tool, not a presentation

The most effective lo-fi prototyping sessions are dialogues. Share your screen. Walk through a user flow. Pause and ask “what do you think happens next?” when you reach a key decision point. You’ll surface assumptions you didn’t know you were making.

Give yourself permission to show bad versions

This is the mindset shift that makes everything else possible. If you’re waiting until your prototype is “good enough to share,” you’re likely waiting too long. The value of a lo-fi prototype isn’t in how it looks. It’s in how quickly it creates a shared object for the team to think around.

Where Miro Prototypes fits this workflow

The practical challenge for many teams is that prototyping has historically required either design skills or significant time investment. Both of those barriers push work toward higher fidelity by default, because if you’re only going to build one prototype, you want it to count.

Miro Prototypes removes that constraint. Product managers, researchers, and cross-functional team members can build clickable, interactive prototypes directly on the same canvas where their research, briefs, and roadmaps already live. There’s no export step, no tool switch, no waiting on a designer. That means teams can prototype earlier, more often, and at the fidelity that actually serves the conversation they’re trying to have.

As Jeff Chow, Miro’s Chief Product and Technology Officer, describes the shift: “Now you don’t have to tell the designers what you want — you can show them instead.” That capability matters not just for speed, but for the quality of conversation it enables. A rough, clickable flow that someone can tap through generates better strategic feedback than a static description of the same idea, every time.

When prototyping is fast and low-friction, teams can afford to start rough. And when you can afford to start rough, you stop triggering prototyping bias, because you’re not presenting your first prototype as a finished thing. You’re presenting it as a first attempt at an answer to a real question.

That’s the workflow that gets you honest feedback. Not later, after you’ve invested six months in the wrong direction. Now, while there’s still time to change course.

Get feedback on the ideas that matter

Your next prototype doesn’t need to be beautiful. It needs to be clear enough to test, and rough enough to invite challenge. Start building in Miro Prototypes for free and see how fast your team can move from idea to validated direction.

Prototyping Bias FAQ

What is prototyping bias? Prototyping bias is the tendency for reviewers to evaluate a prototype based on its apparent finish level rather than the underlying concept or problem it’s meant to solve. When a prototype looks polished, stakeholders and users often assume the thinking behind it is equally settled, which shifts feedback away from strategic questions (“is this the right problem to solve?”) toward surface-level details (“can we try a different font?”). The result is that teams get feedback on execution when they need feedback on direction.

Why is prototyping bias getting worse with AI? AI-powered design tools can produce visually polished mockups in minutes. This removes the honest roughness that used to signal “this is still exploratory,” a signal that invited strategic challenge. When everything looks finished regardless of how much thought went into it, reviewers default to treating it as finished. Teams need to work harder to counteract this by deliberately keeping prototypes lo-fi at the discovery stage.

What is the #badversion concept from Miro? #badversion is an internal cultural norm at Miro where team members tag early-stage work, including boards, slides, prototypes, and sketches, to signal that it’s intentionally rough and not yet finished. The tag creates social permission to share work earlier in the process, which leads to faster feedback loops and more honest strategic input. As Joe McLean, Miro’s product lead for the AI canvas, describes it: “Bad version is really powerful because it creates a social permission for it not to be finished yet.”

How do you get better feedback on lo-fi wireframes? Frame the artifact before sharing it, naming exactly what kind of feedback you need and what’s still open for debate. Use the prototype as a conversation tool rather than a presentation, walking reviewers through flows and asking questions rather than presenting conclusions. Explicitly invite challenge on the concept itself, not just the execution. And keep your own prototypes deliberately rough until the strategic decisions are settled: polish signals confidence, and confidence closes down the conversations you most need to have.

How did Miles & More use Miro Prototypes to improve their feedback process? Lufthansa Group’s Miles & More loyalty program used Miro Prototypes to create, validate, and align on the right solution in less than one day, a process that previously took weeks. Product managers generate mockups directly from website screenshots, gather real-time feedback from end users and stakeholders, and validate concepts before any development work begins. The result is that expensive late-stage rework is significantly reduced, and the team moves forward with genuine confidence that they’re building the right things.

Does lo-fi prototyping work for stakeholder presentations? Yes, and in fact presenting a lo-fi prototype to stakeholders with a clear explanation of what’s still being decided is often more effective than presenting something polished. It invites stakeholders into the decision-making process rather than asking them to ratify a conclusion. Björn Ehrlinspiel of Miles & More describes this directly: using Miro Prototypes to show his vision to management gave him greater confidence that what the team was building was actually right, because the feedback came earlier, when it was still possible to change course.

Author: The Miro Team Last updated: April 8, 2026