wireframing & prototyping

Here is the line most PM courses draw incorrectly: either “PMs should never wireframe, that’s the designer’s job” or “PMs should learn Figma and design everything themselves.” Both are wrong. The correct line depends on your team, your stage, and what you are trying to learn.

I have used dot-grid notebooks, Balsamiq, Figma, InVision, and literal napkins. The tool never mattered. What mattered was whether the wireframe answered a question or just decorated a PRD.

This page will teach you when to sketch, what fidelity to use, and how to prototype just enough to validate your hypothesis — without wasting your designer’s time or stepping on their craft.

The fidelity ladder

There are four levels of visual fidelity. Each serves a different purpose at a different moment. Using the wrong level at the wrong time is the most common mistake PMs make.

Sketches — pen on paper, whiteboard, sticky notes. Five minutes. Disposable. You are mapping a flow, not designing a screen. Use sketches when you are still figuring out what the product does.

Wireframes — grey boxes, placeholder text, no color, no branding. Balsamiq, Whimsical, or Figma in greyscale. You are deciding what goes on each screen and how screens connect. Use wireframes when you know the flow but need to communicate layout to engineering or design.

Mockups — pixel-accurate designs with real content, colors, typography. This is the designer’s territory. A mockup is close to the finished product visually but has no interactivity. You should not be making these unless you have no designer on the team.

Prototypes — interactive, clickable mockups linked together. InVision, Figma prototyping mode, Proto.io. A user can tap through the flow and experience it. Use prototypes when you need to validate with real users before writing a single line of code.

The rule is simple: use the lowest fidelity that answers your current question. If you are debating whether a feature should exist, sketching on paper is enough. If you are testing whether users can complete a checkout flow, you need a clickable prototype.

When PMs should wireframe (and when they should not)

You should wireframe when:

• You are the only person who can. Early-stage startups, solo PM roles, teams without dedicated designers — this is most startups in India under Series A.
• You are clarifying your own thinking. Sketching a flow forces you to answer questions you were unconsciously avoiding. “What happens when the user has zero transactions?” You did not think about that until you drew the empty state.
• You need to align quickly. A wireframe in a 15-minute conversation saves more time than three paragraphs in a spec. Engineers think in screens. Give them screens.
• You are running a design sprint or rapid validation and speed matters more than polish.

You should NOT wireframe when:

• You have a designer and the question is about visual design — color, typography, spacing, micro-interactions. That is their craft. Respect it.
• You are using the wireframe to dictate the solution to your designer. A wireframe should communicate the problem and constraints, not prescribe pixel placement.
• You are spending more than an hour on it. If you are agonizing over alignment in Figma, you have crossed from PM work into design work. Stop.

The tools that actually matter

I started in an era before Figma existed. Paper prototypes, dot notebooks, Balsamiq — that was the stack. The tools have changed. The principle has not: the tool should be invisible. If the tool slows you down, you are using the wrong tool.

For sketching: Paper and pen. Still unbeatable for speed. Dot-grid notebooks give you a light grid without the heaviness of graph paper. I have used them for years.

For wireframes: Balsamiq if you want to stay deliberately low-fidelity. It forces you to think about structure, not aesthetics. Figma if your team is already there — but use it in greyscale. The moment you start picking colors, you have left PM territory.

For prototypes: Figma’s prototyping mode handles most needs. Link your frames, define transitions, share a link. For more complex flows — conditional logic, variable states — use Protopie or Framer.

For quick validation: Do not underestimate a five-slide Google Slides deck as a “prototype.” Screenshot your wireframes, put them in order, walk someone through it verbally. You will learn 80% of what a full prototype would teach you.

That last point is real. Ugly wireframes are a feature, not a bug. When your wireframe looks polished, people respond to the aesthetics instead of the logic. They say “I don’t like that shade of blue” when they should be saying “this flow has too many steps.” Balsamiq understood this — its hand-drawn style was a deliberate design choice to keep conversations focused on structure.

Prototyping for validation, not decoration

The purpose of a prototype is to answer a question. Not to impress a stakeholder. Not to make a pitch deck look professional. To answer a specific question about user behavior.

Before you open any prototyping tool, write down the question:

• “Can users complete the KYC flow in under 3 minutes?”
• “Do users understand that the ‘Settle’ button sends money to the vendor?”
• “Will users find the reports section without being told where it is?”

If you cannot write the question, you do not need a prototype. You need more thinking.

The validation protocol I teach:

1. Write the hypothesis. “We believe users will complete onboarding in under 2 minutes using the new three-step flow.”
2. Build the minimum prototype that tests it. Three screens. Real content (not lorem ipsum — real Indian names, real INR amounts, real GST numbers). Clickable transitions between them.
3. Test with five users. Not colleagues. Not friends. Five people who match your target persona. In India, this often means finding small business owners through your existing network — or just walking into shops in your neighbourhood.
4. Record what breaks. Not opinions. Behavior. Where did they tap first? Where did they hesitate? Where did they say “what does this mean?”
5. Kill or continue. If three out of five users completed the task without help, the flow works. If three out of five got stuck at the same step, redesign that step.

Five users. Three screens. One afternoon. That is all it takes to validate a flow before your engineering team spends two sprints building it.

Common mistakes Indian PMs make

Over-prototyping. You spend two weeks building a high-fidelity prototype for an internal tool that three operations people will use. A wireframe walkthrough would have been enough. Match your fidelity to your audience and stakes.

Prototyping before defining the problem. This is the wireframing equivalent of the solution trap from Product Thinking. You open Figma before you open your research notes. The prototype looks beautiful and solves the wrong problem.

Ignoring mobile-first in a mobile-first country. India is a mobile-first market. If your wireframes are desktop-width, you are designing for yourself, not your users. Start with a 375px frame. Every time.

Using English placeholder content for Hindi/regional language users. If your users read Hindi, your prototype should show Hindi. Text length changes, reading direction assumptions may shift, and the entire layout can break when you switch from “Settings” to a regional equivalent that is three times longer.

Not testing with low-bandwidth conditions. Your prototype works beautifully on your MacBook in Bangalore. Your user is on a Jio connection in a Tier 2 city. If your flow has heavy image loads or complex animations, test on throttled connections. A prototype that does not simulate real conditions is testing a fantasy.

Wireframe as communication tool

A wireframe is not a deliverable. It is a communication tool.

When you share a wireframe with engineering, you are saying: “This is the structure I am proposing. The layout is negotiable. The information hierarchy is not.” When you share it with design, you are saying: “Here is the flow logic and content priority. Make it beautiful — and push back on the structure if it doesn’t work.”

The best wireframe has annotations. Not pixel specs — those are the designer’s domain. Annotations that explain why:

• “Search bar is prominent because 60% of users come here looking for a specific invoice.”
• “We show the total first because users told us they check the total before anything else.”
• “This empty state matters because 40% of new users will see it on day one.”

These annotations are where PM value lives. The layout is commodity. The reasoning behind the layout is what makes a wireframe a product artifact instead of a picture.

Test yourself

Where to go next

• Understand the broader design collaboration: Working with Designers
• Learn the UX principles behind good wireframes: UX Principles for PMs
• Apply wireframes to your specs: Writing PRDs
• Validate your prototypes with real users: User Research Methods
• See how design fits into the full build process: Sprint Planning