A low-fidelity (low-fi) prototype is not a product; it is a conversation starter. I have seen too many founders spend six months and $50,000 building a "perfect" app, only to find out upon launch that nobody actually wants the problem solved that way. The low-fi approach is your insurance policy against building the wrong thing.

2.1 The Psychology of the Sketch

There is a profound psychological difference between showing someone a polished, high-resolution design and showing them a rough sketch.

The "Finished" Trap: When a prototype looks like a finished product, the reviewer assumes the big decisions have already been made. They will give you feedback on the shade of blue or the placement of a logo because they don't want to hurt your feelings by criticizing the core logic.
The "Sketch" Invitation: When you show a low-fi mockup—something that looks like it was drawn on a napkin or built in a basic tool—you are signaling that the idea is still fluid. This invites the reviewer to be a co-creator. They feel safe saying, "This button shouldn't even be here," or "I don't understand why this step is necessary".
Speed to Failure: In the "Dr. VAX" philosophy, we want to fail fast. If an idea is going to die, I want it to die in a PowerPoint slide, not after three months of coding.

2.2 The Low-Fi Toolkit

You do not need to be a designer to build a world-class prototype. In fact, being "too good" at design can sometimes be a hindrance at this stage.

Balsamiq: This is my favorite tool for this stage. It intentionally uses "hand-drawn" styles to keep the focus on structure and flow rather than aesthetics.
Wondershare Mockit: Great for adding basic interactivity—allowing a user to click a button and see the next screen.
PowerPoint/Keynote: Do not underestimate the power of a slide deck. You can link slides together to simulate a user journey with zero learning curve.
Paper and Pen: If software intimidates you, draw it on a piece of paper. I have seen successful $100 million companies start with a stack of 3x5 index cards.

2.3 OEA Analysis: The Technical Blueprint

Before you move from a sketch to a developer, you need to perform an Object Event Action (OEA) analysis. This is a disciplined framework I used at Metamor to ensure technical clarity.

Objects: Identify every "thing" in your system (e.g., User, Invoice, Message).
Events: Identify every "trigger" that happens to those objects (e.g., User logs in, Invoice is paid).
Actions: Document exactly what the system does when an event hits an object.
Why it matters: This prevents "feature creep". If an action doesn't serve a core object/event pair, it doesn't belong in your MVP.

2.4 Finding Your "Truth Tellers"

The hardest part of prototyping is not the drawing; it is finding people who will tell you the truth. Your mom will tell you the idea is great; your best friend will tell you it's brilliant. Neither of them is helping you.

Define the Audience Specifics: Don't just look for "small business owners". Look for "small business owners with 5-10 employees who struggle with payroll taxes".
The Professional Referral: Tap your network and ask, "Who is the most cynical, no-nonsense person you know in this industry?". Those are your best reviewers.
Incentivize Honesty: Offer a $25 gift card for a 30-minute session. Explicitly tell them: "I am looking for reasons why this will fail. Please be brutal".
Social Media Recruitment: Use LinkedIn groups or Reddit subreddits dedicated to the problem you are solving. Post your low-fi link and ask for feedback.

2.5 Conducting the Review Session

When you sit down with a reviewer, do not "sell" the product. Your job is to observe.

The "Think Aloud" Method: Ask the reviewer to narrate their thoughts as they look at the prototype. "I'm clicking this button because I expect to see my profile... oh, it took me to the settings page. That's confusing."
Don't Explain: If they get stuck, don't help them. If they can't figure it out in the prototype, they won't figure it out in the real app.
The "Magic Wand" Question: At the end of the session, ask: "If you had a magic wand and could change one thing about this process, what would it be?"

2.6 The Dr. VAX Lesson: Learning from DialogTech's Early Days

When we were building the early versions of what became DialogTech, we were convinced that people wanted a voice-activated web browser. We built a low-fi prototype and took it to potential users.