Not Every Clickable Screen is a Prototype: How to Use (and Misuse) Prototypes in Design

Prototypes are everywhere in product design - but are we actually using them the right way?

In this episode of the MVPF InnoSanity Podcast, host Baby Jessi Parker sits down with Daniel Westerlund, Senior Strategic Designer at MVP Factory, to unpack what prototypes really are, when they’re useful, and when they’re just… a waste of time. From misunderstood Figma flows to technical testing tools, this conversation explores how teams can use prototypes to validate ideas, test risky concepts, and avoid building shiny but empty artifacts.

Whether you’re a designer, product manager, or stakeholder wondering if you really need a prototype, this episode will help you rethink what purposeful prototyping actually looks like.

Here’s what they talked about:

Jessi: Dan, it’s great to see you again! It’s been a while, but I’m really excited to dive into some design talk with you.

Dan: Likewise. And this is actually my first podcast ever, so I’m excited—and a little nervous.

Jessi: You’ll be great. So, the topic today is prototypes in design. It’s a bit of a buzzword lately. Everyone loves asking for them, building them, selling them. But not everyone uses them in the right way.

Dan: Definitely. And before we jump in, I want to call out one thing you said earlier—while design is subjective, there are still a lot of ways to do things wrong. There are many right approaches too, which is where the confusion often starts.

Jessi: Exactly. Before we dive into the details, just a quick disclaimer: everything in design is subjective. There’s no single right way to do things. What we’ll share today is based on our own experiences—what’s worked, what hasn’t, and what we’ve learned along the way. Why don’t you give a quick intro first?

Dan: Sure. I’m Daniel Westerlund, Senior Strategic Designer and Design Systems Lead at MVP Factory. I come from an agency background—mostly front-end and UX design agencies. Over the years, I shifted toward consulting and corporate work, and I’ve been at MVP Factory for about three years now.

Jessi: Three years! I remember our first project—it was also my first after my internship ended. Definitely felt like a “big designer” moment for me.

Dan: It was a great project. And I think a lot of the work we’ve done together since then shows how prototypes can help solve design problems—or even business problems—when used well.

Jessi: Let’s get into it. How would you define a prototype in simple terms?

Dan: There are many definitions out there, but for me, a prototype is about taking something you’re unsure about and testing it by building something tangible. It helps you answer a question. In digital product design—our focus here—people often think of prototypes as screen-based UI flows. But there are also technical prototypes to test engineering feasibility, or market prototypes to test go-to-market strategies.

The shape of the prototype depends on the problem you’re trying to solve. That’s where a lot of misunderstanding comes in—especially when stakeholders expect one thing and get another.

Jessi: Right. There’s often a universal expectation that a prototype should look shiny—like a nearly finished product. But sometimes that just isn’t necessary, especially early on.

Dan: Exactly. A lot of people expect a polished set of Figma screens that you can click through, even if that doesn’t help you learn what you need to know. And when you show them something else, they often push back.

It’s become almost default to equate “prototype” with “high-fidelity clickable Figma mockup,” but that’s not always the right tool.

Jessi: In my experience, people treat prototypes as a signal that something is ready to build. Like, “This looks great—let’s develop it.” But if you haven’t validated the idea behind it, what’s the point?

Dan: Exactly. You can spend a lot of effort creating something beautiful that ultimately tells you nothing new. It’s not that high-fidelity prototypes have no value—they absolutely do, especially for selling an idea. But at early stages, when you still have big open questions, they might be the wrong investment.

Jessi: So when is the right time to build a prototype?

Dan: When you’re trying to test a specific unknown—something risky. That could be a new UX concept, an unfamiliar user group, or even a technical challenge.

Let’s say you’re moving an old on-premise system to the cloud. You might build a technical prototype to see how authentication works in that environment. It’s not flashy. It won’t be reused. But it helps you test feasibility.

Jessi: Right. It’s not about polish—it’s about proof of concept.

And on the visual design side, people often throw in login screens just because they feel like they have to. But we already know how logins work. That screen’s not teaching you anything new.

Dan: Exactly. Unless you’re testing an unusual login experience, that screen is just noise. If you're not learning anything from it, why prototype it?

Jessi: So the first thing you should ask is: what do we want to learn?

Dan: Absolutely. What are we least sure about? What are the riskiest assumptions? Start there.

For example, if you're testing whether a very specific user group understands a novel navigation flow, that’s worth prototyping. But generic UI patterns that everyone knows? Probably not.

Jessi: Let’s talk about usability testing. Do you think testing a prototype with five or six people is useful?

Dan: It depends. If you’re testing a risky or unusual concept, then yes—five people can reveal a lot. But if you’re testing something standard, like whether users can navigate a typical SaaS dashboard, five people won’t tell you much.

Jessi: So it’s about the level of risk or novelty. If something’s very new or strange, a small sample can be valuable. But common patterns might require broader testing.

Dan: Exactly. The more nuanced the thing you’re testing, the larger the sample size you’ll need to get meaningful insights.

And if you're going to do large-scale testing anyway, you might not get extra value from a small-scale test beforehand—unless you're validating a very early-stage concept.

Jessi: Makes sense. But what about combining both? Use a small group to spot early issues, then validate them at scale?

Dan: That can work—but only if the small test gives you something you can’t get from the big one. If you're just confirming what you already know you're going to test at scale, it might not be worth it. Again, it comes back to your objective. If you’re testing a concept—something abstract, like “does this idea make sense to people?”—a small group is perfect. If you’re testing usability or interaction, scale matters more.

Jessi: So to sum it up:

• Use small groups to test concepts and ideas.
• Use larger groups to test usability and features.
• And always define your objective first.

Dan: Exactly. If you can’t clearly say what you’re trying to learn from the prototype, you probably shouldn’t be building it yet.

Jessi: Love that. We’ll wrap Part 1 here. We talked about how to use prototypes effectively, when they’re helpful, and why defining your objective is key.

In Part 2, we’ll look at what happens when prototypes are built without clear objectives—and the common misconceptions that come from that. Stay tuned!

Dan: Looking forward to it.
‍

‍
PART2:
‍

‍
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.

‍

‍

‍