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.

‍