When Prototypes Turn into Pitfalls: Testing the Wrong Things at the Wrong Time

Not all prototypes are created equal - and not all of them are used the right way.

In Part 2 of this MVPF InnoSanity Podcast series, Baby Jessi Parker and Daniel Westerlund return to explore the most common misconceptions around prototypes. If you missed the first part, you can tune into that here.

From using polished clickthroughs as sales tools to skipping critical learning opportunities, Jessi and Dan break down how misplaced expectations can lead to wasted time, biased feedback, and weaker products.

If you're building, or asking for, prototypes and want to avoid the usual traps, this honest conversation is a must-listen.

Baby Jessi Parker: Mic check—now we’re good. Cool. Alright, welcome back, Dan! Lovely to have you again.

Daniel Westerlund: Thank you, Baby Jessi. Very happy to be here.

Baby Jessi Parker: Fantastic. This is a continuation from Part 1, so if you haven’t listened to that yet, please go back and listen. Last time, we talked about what a prototype is. We focused heavily on UI and visual prototypes, because that's one of the types we interact with the most—but of course, there are many other kinds. We also talked about how you can test prototypes, when to test with small groups versus large groups, and the pros and cons of both.

Today, we're diving into misconceptions about prototypes—how people tend to use them wrong.
You made a great point last time when I said design is very subjective, and you reminded me that, well, there are some wrong answers.

Daniel Westerlund: Yes, there are wrong answers. There are situations where you have to stop and ask, "Why are we doing this?" But that's okay—it's part of the learning process.

Baby Jessi Parker: Exactly. So, let's dive right into it. What are some common misconceptions or wrong ways to use a prototype?

Daniel Westerlund: The biggest and most common one is using prototypes to test desirability. It happens all the time—and it’s understandable. If you’re a stakeholder, founder, or responsible for a product’s success, of course you want to make sure it’s desirable. And a prototype is often the first tangible thing that brings an idea to life. Naturally, you get excited. You want to show people: "Isn’t this great? Doesn’t it solve the problem?" And in that sense, prototypes become a sales tool.

I’m not saying you shouldn’t test for desirability—you absolutely should—but doing it with a prototype isn't always the best way.

Baby Jessi Parker: Yeah.

Daniel Westerlund: Usually what happens is: you build a full flow, or key flows, from an interface perspective. You show it to potential customers and ask, "Do you like it? Would you buy it?" But by doing this, you miss a lot of opportunities. There could be many other directions you could have explored—different solutions, different concepts. You’re taking one shot and hoping it’s right, instead of iterating in small steps to find a better version along the way.

Baby Jessi Parker: Exactly. I think that's something we missed in the last episode: Prototypes are meant to be iterated and improved upon. If you come out of the gate calling your final polished product a prototype, you’ve invested so much effort into something that's now hard to change based on feedback.

Daniel Westerlund: Correct. And the key takeaway is: by doing that, you miss learning very important lessons. It often results in an inferior product—not a bad product, necessarily—but one that's not as good as it could have been. You're taking one big swing instead of giving yourself room to explore, refine, and improve.

Baby Jessi Parker: Exactly. And people also need to realize: it takes time. The six months you spend building a perfect prototype could have been spent refining your concept, achieving better problem-solution fit, doing usability testing along the way...You’d save a lot of headaches instead of spending another six months fixing a fully built product.

Daniel Westerlund: Yes. And I think that's the real challenge. People outside of product and design don't always understand the value of something that doesn’t look polished. They expect to see something beautiful, something finished. And it’s hard to sell the idea of an early, messy prototype—to both stakeholders and users.

Users often expect something close to the real product before they feel comfortable giving feedback.

Baby Jessi Parker: Yeah, for sure.

When I work on projects, I look at the whole idea or concept and break it down:

• What do we need to test?
• What do we need to learn?
• How can we best achieve that?

If the prototype already exists, I find ways to use it properly. If it doesn’t, I push back: "Building it this way won’t help us learn what we need to learn." And it's a balance—you need to present things in a way that doesn’t lose users or stakeholders along the way. Everyone wants the shiny diamond. But testing desirability doesn't necessarily mean you have to put something shiny in front of users.

Daniel Westerlund: Exactly. A good approach is asking: are you testing one idea—or are you testing five different ways to solve the same problem? Testing multiple ideas always leads to stronger outcomes. It gives you the opportunity to pick the best approach based on real feedback instead of betting everything on one shot.

Baby Jessi Parker: And if you’re doing that—testing five approaches—you’re really using the prototype the right way.

Daniel Westerlund: Exactly. And it can apply to usability, visual design, even technical prototypes. It’s all about communicating clearly:

• What are we testing?
• What should users expect?
• What feedback do we actually want?

Baby Jessi Parker: Because if you don't frame it properly, users expect a finished product. And if the prototype is shiny and polished, it biases the results. People love pretty things. They might say, "Yeah, it looks great," but they’re not telling you whether they’d actually use it.

Daniel Westerlund: Exactly. The shinier the prototype, the less valuable it is for answering real product questions. It becomes a sales tool, not a learning tool.

Baby Jessi Parker: Right. You’re no longer asking, "Is this solving the right problem?" You're just asking, "Can we sell this?" And shiny prototypes can mislead you—people might say they love it, but when it comes time to actually use or pay for it, it’s a different story.

Daniel Westerlund: And stakeholders often push for this because they already have a vision in mind. They’re not always interested in exploring other ideas or testing whether there might be a better solution. It’s about confirming their vision—which can lead to inferior products.

Baby Jessi Parker: Agreed. And once you polish that prototype, you reach a point of no return. It becomes really hard to question it anymore—resources are locked in, teams are shifting toward visual design and engineering, and you lose the early flexibility you had.

Daniel Westerlund: Exactly. In my opinion, any prototype you build should be something you're willing to throw away. It should exist purely for learning—not to become the final product itself.

Baby Jessi Parker: That's a strong point. And a really important one.

Daniel Westerlund: Yeah. Because when you start treating prototypes as production-ready artifacts, you lose the ability to iterate properly. You skip all the messy, necessary steps that real innovation requires.

Baby Jessi Parker: And if you look at other industries—like automotive—they do this so well. They spend years prototyping, perfecting things, and learning before ever releasing a final product. Even giants like Apple—they went through countless ugly iPhone prototypes before landing on the final design. We don’t see that because they don’t show us the ugly stages—but they definitely exist.

Daniel Westerlund: Exactly. Design is so many steps of ugliness before you get to beauty. And in our industry, we often skip those steps because of budget pressure or because stakeholders want quick wins. But if we don’t explore different paths—even just a few steps down them—we end up with products that are okay, but not great.

Baby Jessi Parker: And honestly, there’s nothing more dangerous—in a good way—than a product team that really knows their product. The only way you get there is by exploring, prototyping, learning from failure, and building that deep understanding over time.

Daniel Westerlund: Absolutely. And you can’t just trust the process—you have to trust the people. Processes are commodities—you can look them up online. It’s the people, their experience, and their judgment that make the difference.

Baby Jessi Parker: Exactly. Trust the people—not blindly, but trust the people who know how to navigate the process the right way.

Daniel Westerlund: Yes. And one final thought: If you’re considering a weird, risky, or different idea—that’s the perfect time to prototype. Prototype early, prototype ugly, and prototype to learn, not to impress.

Baby Jessi Parker: Agreed. Thanks again, Dan. It’s been a fantastic two-part series—and honestly, this is the kind of conversation we have all the time behind closed doors. Glad we finally recorded one.

Daniel Westerlund: Thank you. It’s been a lot of fun.

‍