Short answer: Prototype an app idea by naming the one question it must answer, building only the two or three screens that answer it, and putting the riskiest part first. In App Builder, walk the frames in Present mode and finish by writing down what each answer changes.
Write the question the prototype has to answer
An idea becomes testable when it is turned into a question with a possible answer. Not do people like this app, but would someone who wants to track their reading recognize this screen as the place to log a book. A question with a shape like that can be put to a person in ten minutes.
Write the question down before you open the editor, in one sentence, and write down what a good answer looks like. If the answer is that the person picks the wrong option, the prototype needs to make the options comparable. If the answer is that they do not understand the wording, it needs clearer words.
Then agree which question matters most. A prototype can hold several ideas, and showing all of them means nobody looks hard at any of them. One question per session is uncomfortable and far more useful than a tour of everything you have thought of.
- The question names who, what they would try, and what would count as success
- The expected answer is written down before any frames exist
- One question per prototype session, not a list of five
Note: If you cannot phrase the question in one sentence, the idea is still a pitch rather than a hypothesis. Split it until each half has a question you could actually ask someone.
Choose the smallest set of screens that answers it
The smallest set is usually two or three frames. Each frame has to earn its place by carrying part of the answer, and anything that does not is extra time in the walkthrough and extra risk of the review drifting away from the question.
The template gallery holds 54 app templates in 8 categories, and it is searchable and filterable by mobile or web. Templates are a fast starting point when you do not want to draw a screen from nothing, and they are a fast way to see how other products solved a layout you are stuck on.
Start from a template, then strip it. Delete the parts that do not serve your question, replace the labels with your own words, and keep only the screens you need. A prototype borrowed wholesale tests the template's idea rather than yours.
- Two or three frames, each carrying part of the answer
- 54 app templates in 8 categories as a starting point
- Search the gallery and filter by mobile or web
Note: The gallery is a source of structure, not a source of truth about your product. If the template's navigation pattern is wrong for your idea, change it before you show it to anyone.
Give each screen one message
One screen, one message, is the rule that keeps a walkthrough on the question. If a screen is trying to explain the pricing, the navigation and the sign-up at the same time, the viewer has no idea which of them you want judged.
Write the message as a single sentence and put it in the frame as a heading or a short label. If the sentence is the heading, the reviewer reads your claim before they read the layout, which is the order you want when you are testing whether the claim lands.
If you cannot write the sentence, the screen is not ready yet. A screen without a message is decoration, and decoration in a prototype produces opinions about color that you never asked for in the first place.
- One sentence per screen, written before the layout
- The sentence becomes the heading or a short label in the frame
- Two screens must not compete for the same message
Put the risky part in front of the user first
Order the frames by risk, not by habit. The screen you are least sure about should be the first one you show, because that is the screen you most need a reaction to, and a reaction given in the first minute is worth more than one given at the end of a long tour.
Present mode follows the links you set. Forward moves to the linked frame when there is one and otherwise advances in order, so a risky screen that sits third will be reached third. If you want it first, put it first and set the links to match. The no-code prototype guide covers the linking in detail.
Risk also means telling the truth about the weak part. If the app depends on people understanding a new idea, show the screen that explains it early. If it depends on data you do not have yet, show a plausible version and say plainly that the numbers are made up.
- Order the frames by uncertainty, not by the order you drew them
- Set On tap go to so the risky screen is reached early
- Say which part of the screen is still an assumption
Note: Present mode has no pointer navigation, so the order of the walkthrough is entirely down to you. That makes putting the risky screen first a deliberate act rather than something that happens by accident.
Prepare three questions for after the walkthrough
Most of the value of a walkthrough is in what you ask afterwards. Three questions is enough to get past the polite reaction and into the useful one, and asking more turns the session into an interview nobody remembers the next day.
Ask what they expected, what they tried to do, and what stopped them. The first tells you whether the structure matched their mental model, the second tells you whether the flow made sense, and the third tells you where the friction is. Ask them as open questions and then stay quiet.
Keep the questions on a note next to you, because a long silence feels awkward and people tend to fill it with agreement. Three written questions give you three real answers instead of a nodding session that tells you nothing.
- What did you expect to happen here?
- What were you trying to do?
- What stopped you?
Write down what the answer changes
A prototype that does not change anything is a wasted afternoon. When the walkthrough ends, write down the decisions: what you will build differently, what you will keep, and what you still do not know. One line per decision, with the frame it belongs to.
The list of what you still do not know is the most valuable part, because it tells you what the next prototype has to test. It also stops you from treating one friendly reaction as a settled answer. The mockup tool guide covers how to judge a mockup before you show it.
Canvasola keeps 20 versions of your work in the version history panel, so you can open an older snapshot if a change turns out to be wrong. Take a copy of the version you are happy with before starting the next round of edits. Workspace tabs hold up to 100, so two attempts can sit side by side, and the complete Canvasola guide covers the tab and history tools.
- Decisions recorded with the frame each one belongs to
- Unknowns listed separately from decisions
- Version history keeps 20 versions to fall back on
A checklist you can reuse
- The question the prototype must answer is written in one sentence
- The expected answer is written down before the first frame was built
- The prototype has two or three frames, each with one message
- The riskiest screen is the first one reached in Present mode
- Three questions are written down for the end of the walkthrough
- Any invented data or placeholder content is labeled as such in the frame
- Decisions and remaining unknowns are recorded after the session
Common mistakes to avoid
- Showing everything you built. A tour of ten screens produces vague praise and no usable answer. Build only what the question needs and leave the rest for later.
- Asking whether people like it. Nobody can answer a question with no failure condition. Ask what they would do, what they expected, or which of two options they would take.
- Starting from a template and keeping it. An unedited template tests the template's idea. Strip the parts that do not serve your question and put your own words in.
- Asking questions before the walkthrough. A question at the start tells you what you expected to find. Ask the three questions after the person has seen the frames.
- Ending the session without a decision list. Without written decisions the prototype changes nothing and the same debate returns in a month. One line per decision, with the frame it belongs to.
Frequently asked questions
How many screens do I need to prototype an app idea?
Two or three is usually right. Each screen should carry part of the answer to the question you set, and anything extra is time in the walkthrough and a chance for the review to drift. If a fourth screen keeps being added, the question is probably two questions and needs two sessions.
Should I use an app template for my prototype?
Templates save time when you are unsure how a screen should be arranged. The gallery has 54 app templates in 8 categories and can be searched and filtered by mobile or web. Use one as scaffolding, then remove what does not serve your question and replace the wording with your own.
Can I go back to an earlier version of my prototype?
Yes. App Builder shares the undo and redo history with the canvas and the mind map, and the version history panel lists snapshots with timestamps, keeping 20 versions. If a round of edits goes wrong, open an earlier snapshot rather than rebuilding the frames by hand.
What if the person testing says they like everything?
That is a sign the questions were too polite or the walkthrough was too long. Ask what they expected to happen and what they tried to do, and look for the moment they hesitated. A specific story about one screen is worth more than a general positive reaction.
Test the riskiest screen first.
Open App Builder, pick a template or a device frame, build the two screens that answer your question, and walk them in Present mode.
This guide is part of the app builder guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.