In this guide 6 sections
Start with paper sketches shown to three users. They settle the flow. Move to a Figma prototype for the investor demonstration, because it is quickest to produce and looks like a finished product on any screen. Build a coded prototype only when a pilot customer must enter their own data or you must test real integrations on a phone.
Paper sketches settle the flow in an afternoon
Draw each screen on an index card or an A5 sheet. Show the cards to three people who would use the product. Hand over the first card, ask where they would tap next, and then swap in the card that screen would lead to.
Three people are enough. The same stumble repeats, so the confusing step shows up fast. Paper cannot show animation, and it cannot impress an investor. It also cannot tempt you into polishing the wrong screen.
- Use one card per screen state
- Ask users to say what they expect before pointing
- Mark any hesitation longer than three seconds
- Throw cards away freely
Figma prototypes win on speed and polish
In Figma you link frames with tap targets and transitions, then share a link or open the Figma mobile app on a real handset. A designer can produce twenty linked screens in days. Investors see a convincing product without a line of code.
On a phone, the prototype gives the right screen size. It lacks the real keyboard, the camera and the scroll feel that decide whether a form is pleasant to use. A pilot customer can click your path. Typing their own data in does nothing. The illusion breaks there.
Coded prototypes feel real because they run
A coded prototype is a working front end, often in React or Flutter, wired to fake data or a test API. It runs in the phone browser or as an installable build. The pilot customer can type, attach a photo and watch the form validate.
It takes longer. Bugs appear that have nothing to do with your idea. The upside is reuse. A developer can keep the components and styles, though the data layer is usually rewritten.
- Real keyboards, camera and offline behaviour
- Pilot staff entering their own records
- Components a developer can keep
- Wiring to a test API when the integration is the risk
Choose by the question you need answered
Ask what you need to learn. If users must understand the flow, paper answers it. If investors must believe the product, Figma answers it. If a warehouse supervisor must work the scanner screen with gloves on, in poor light, only code answers it.
Work in that order. Stop when the question is answered. Each step reuses the thinking before it, so the paper round costs a day and saves rework in the other two formats, which cost far more.
A sensible sequence for a pilot demonstration
Begin with paper cards and three users. Then build a Figma prototype of the three screens that carry the story, and rehearse the walk through. If the pilot customer wants to try their own data, code only the one flow they need.
Resist building the whole product as a prototype. One that does everything is just a slow first release.
Write down the single question your demonstration must answer, and pick the cheapest format that answers it.
Prototype choice worksheet
Print this on a single sheet. Three rows cover paper, Figma and coded. Columns cover the question answered, people needed, time to build, devices tested, what a developer can reuse, and the decision with a date. Below the table sits one blank line for the single question this prototype must answer.
Open a blank worksheet to printQuestions owners ask
Is a Figma prototype enough for a pilot customer?
Often, if they only need to see and click the flow. It falls short when they want to type their own records, upload files or test on the device staff will actually carry.
Can a coded prototype become the real product?
Sometimes parts of it can. Components and styles carry over well. Data handling and security are usually rebuilt, so plan for that instead of assuming the prototype is a first release.
Are paper sketches too crude to show anyone useful?
They are ideal for the users who will use the product, because they invite honest correction. Keep them away from investors, who expect a polished screen to judge the product by.