---

title: "Using Prototypes and MVPs as Communication Tools"

module: 11

module_title: "Stakeholders & the Client Lifecycle"

order: 4

access: "paid"

summary: "Why a clickable prototype or stripped-down MVP creates shared understanding faster than weeks of documents and meetings. Covers matching fidelity to purpose, framing what feedback you need and what to ignore, and using tangible artifacts to surface misalignment before major investment."

related:

• "presenting-work-in-progress-vs-finished"
• "facilitating-productive-feedback-sessions"
• "setting-vs-managing-expectations"
• "bridging-gaps-between-client-vision-and-technical-reality"

---

Using Prototypes and MVPs as Communication Tools

Sometimes the best way to communicate an idea isn't through words at all. A clickable prototype or a stripped-down MVP can create shared understanding in minutes that weeks of documents and meetings couldn't achieve.

When people can interact with something, they give you better feedback, spot problems earlier, and get excited about possibilities they couldn't see in a specification.

Why this matters

Abstract discussions breed misalignment. Everyone nods along, imagining something slightly different. A prototype makes the abstract concrete. Suddenly the conversation shifts from "what do you mean by..." to "what if we moved this button here?" That's a much more productive conversation.

MVPs serve a similar purpose at a larger scale. Instead of guessing whether users want a feature, you build the simplest version and find out. Four weeks of real feedback beats six months of assumptions.

The principles

Show, don't just tell. Building something tangible, even a rough one, communicates more effectively than describing it.

Match fidelity to purpose. Rough sketches for exploring ideas. Clickable prototypes for validating flow. Polished mockups for final approval. Don't over-invest in fidelity before the concept is validated.

Frame appropriately. "This is to test the concept, ignore the visual design" prevents people from giving you feedback you don't need yet.

Use to surface misalignment early. Better to discover that you and the client have different visions during a prototype review than during the final build.

What this looks like

Using a prototype for alignment: "Before we invest in full development, I've put together a clickable prototype showing the core flow. Took a few hours instead of weeks of dev. Let's walk through it together. Focus on: does the flow make sense? Is anything missing? Visual design comes later."

Using an MVP to validate: "Rather than building all ten features, let's launch with the core three for 100 beta users. We'll learn in four weeks what we'd otherwise be guessing at for months."

Tips

1. Use prototypes early to align on approach before building
2. Match fidelity to the stage: sketches, wireframes, clickable prototypes, code
3. Frame clearly what you're testing and what to ignore
4. Walk through prototypes together rather than emailing them
5. Build the smallest thing that tests the key question
6. Iterate quickly based on feedback

How this connects

This combines presenting work in progress (proper framing), facilitating feedback (concrete artifacts to discuss), managing expectations (showing realistic progress), and bridging client vision with technical reality (making the abstract tangible).

Things to try

• For your next project, create a quick prototype before starting development.
• Learn a prototyping tool if you don't know one: Figma, InVision, or just HTML.
• Practice the framing: "This tests X, ignore Y for now."
• Use an MVP approach for your next risky feature instead of building the full vision.

Template: Prototype Walkthrough Framing

Use this when: you're sending or presenting a rough prototype and need to steer the client toward the feedback you actually need right now.

Channel: Email

```template

Subject: Clickable prototype for [FEATURE/FLOW] — let's walk through it

Hi [NAME],

Before we invest in full development, I put together a clickable prototype of [THE CORE FLOW]. It took [A FEW HOURS] instead of the weeks a real build would, which is exactly the point: it's cheaper to find misalignment now than after we've written the code.

Rather than email it cold, I'd like to walk through it together [DAY/TIME]. It's about [LENGTH].

When you look at it, here's what I need feedback on:

• Does the flow make sense? [SPECIFIC QUESTION — e.g. is anything missing from the checkout steps?]
• [SECOND THING YOU'RE TESTING].

And here's what to ignore for now: [WHAT'S NOT REAL YET — e.g. colors, copy, exact spacing]. All of that comes later, once we know the flow is right. If it looks rough, that's on purpose.

Sound good?

[YOUR NAME]

```