Short answer: Presenting a multi screen app flow is a prepared walkthrough: order the frames as the story runs, decide which transitions you will talk over, rehearse the path in Present mode with ArrowRight and Space, and leave an exported set of frames behind.

Order the frames the way the story runs

Before you present, decide the order. Not the order the frames happen to sit on the canvas, and not the order the screens were designed, but the order the story runs: this is where the person starts, this is what they decide, and this is where they end up. If the frames are already in that order on the canvas, presenting is simple. If they are not, the order is a decision you make now.

Place the frames so that order is visible. Put them in a row or a column with even spacing, and number them if that helps. A row of frames numbered one to six tells a stakeholder there is a beginning and an end, which is more than a scattered set of screens does.

Decide where the flow branches. A flow that splits is worth marking, because a stakeholder looking at the main path will otherwise assume it is the only path, and they will read the branch screen as an extra step rather than a choice.

  • Order by the story, not by the order you drew them
  • Lay the frames out in a row or column with even spacing
  • Number them if it helps the viewer count
  • Mark the branches so nobody assumes one path

Note: Ordering the frames on the canvas is separate from the links between them. The user flow guide covers how the two work together.

Decide which transitions to talk over

Some transitions need words and some do not. Moving from a list to a detail screen can be a sentence, and moving from one step of a form to the next does not need one. Decide in advance which transitions you will talk over and let the rest pass quickly, because a walkthrough that narrates every frame loses the room by the fourth screen.

The transitions worth talking over are the ones where the user's decision happens: a choice of plan, a confirmation, a place where the product asks for something. Those are the moments where pausing for a reaction is worth it.

Show the prototype links so the transitions are visible to anyone watching the canvas rather than only to you, and check that the arrows point where you expect before the session starts. The no-code prototype guide covers how the links and the frame order fit together.

  • Talk over the transitions where the user decides
  • Let the routine steps pass quickly
  • Show prototype links so the path is visible on the canvas

Do a dry run of the whole path

Rehearse it. Present mode is driven entirely from the keyboard: ArrowRight or Space steps forward, ArrowLeft steps back, and Esc leaves the mode. Forward follows a frame's On tap go to link when one is set, and otherwise advances in order. A dry run tells you where the path is broken, where the wording falls flat and where you will want to say more than one sentence.

Do the dry run standing up and speaking out loud. Reading a script silently hides the sentences that are too long, and speaking reveals them at once. It also tells you how long the walkthrough runs, which is worth knowing before you book thirty minutes for it.

Fix the flow rather than the rehearsal if something feels wrong. If a screen confuses you, it will confuse the room, and the fix is a clearer label or a new frame rather than a better delivery.

  • ArrowRight or Space for next, ArrowLeft for back, Esc to exit
  • Rehearse standing and speaking the words out loud
  • Fix the flow rather than the delivery

Prepare one line per screen to say out loud

One line per screen is enough. Not a script, just a sentence saying what the screen is for and what reaction you want from it. People remember the shape of a walkthrough, and one clear sentence per screen is what lets them picture the flow afterwards.

Write those sentences before the session rather than during it. Twenty minutes with the frames and a notepad is enough, and it is the difference between a walkthrough and a tour that drifts from one screen to the next.

Keep the sentences on one page, in order. You will glance at it while you present, and the order doubles as a check that the flow makes sense from the top down, which is often the first sign that two frames are in the wrong order. The complete Canvasola guide covers the tools behind the presentation.

  • One sentence per screen: what it is for and what reaction you want
  • Written before the session, not improvised during it
  • One page, in order, easy to glance at

Export a set of frames to leave behind

People forget a walkthrough and keep the file. Export the frames as PNG at 2× and send the set after the session, so the conversation can continue in writing on something that looks like what you showed. One image per screen, named in the order you presented them, is easy to comment on and easy to file.

The static HTML and CSS export is the other option. It renders the frames as absolutely positioned divs with inline styles and a small embedded stylesheet, with no JavaScript and no interaction, so anyone with a browser can open it and see the screens. It is a good thing to leave with people who do not have Canvasola open.

App Builder work is stored inside the .canv project file, so saving the project and sending that file is how the frames travel with their links intact. The export guide covers the formats and when to use each one.

  • PNG at 2× for the screens people will comment on
  • Static HTML and CSS for anyone with only a browser
  • The .canv project file keeps the frames and their links together

Note: There is no published web page for a mockup. Exports are files you send, and the .canv file is the one that keeps the flow intact.

Ask for one specific piece of feedback per screen

Feedback on everything is feedback on nothing. Before the session, decide the one question each screen should answer, and ask it when you reach that screen. For the list screen it might be whether the right items are in it, and for the confirmation screen whether the wording of what just happened is clear.

Ask the question and then let the room answer without you explaining the design. The urge to defend the frame is strong, and every defense takes the answer away from the person who just gave it.

Close the session by saying what you will do with the answers. A short summary of which frames change and which do not gives the review a clear end, and it stops the conversation from carrying on over email for a week.

  • One question per screen, decided before the session
  • Ask, then stay quiet long enough for a real answer
  • Close with what you will change and what you will not

Note: The mockup tutorial covers the build side of the flow you are about to present.

A checklist you can reuse

  • The frames are ordered on the canvas the way the story runs
  • Branches in the flow are marked and the main path is obvious
  • You know which transitions you will talk over and which you will skip
  • The whole path has been dry run in Present mode, standing and speaking
  • One line per screen is written down in order
  • A PNG set at 2× is ready to send, named in presentation order
  • The .canv project file is saved so the frames and their links travel together

Common mistakes to avoid

  • Presenting in the order the frames were drawn. Design order is not story order, and the audience has to rebuild the story in their heads. Move the frames into the order the user actually moves through them.
  • Narrating every transition. A comment on every frame turns the session into a critique of details. Pause only where the user makes a decision.
  • Explaining the design while people answer. Defending the frame as you speak takes the answer away from the person who gave it. Ask, then wait in silence.
  • Walking through without a rehearsal. Unrehearsed walkthroughs stumble on broken links and thin wording at exactly the wrong moment. Run the path through Present mode first.
  • Leaving with nothing behind. A walkthrough that leaves no file is a conversation with no record. Export the frames as PNG and save the project file.

Frequently asked questions

How long should a multi screen walkthrough take?

Five minutes of presentation for a six-frame flow, plus the discussion. If the dry run takes longer than that, the flow is doing too much, and it is usually because a branch is being explained that could have been a note in the frame.

How do I move between frames while presenting?

Present mode is keyboard driven. ArrowRight or Space moves to the next frame, ArrowLeft goes back, and Esc exits. Forward follows a frame's On tap go to link when one is set, and otherwise advances in the order the frames are placed.

What should I send after the session?

A PNG export of the frames at 2×, named in the order you presented them, so people can comment on the screens they remember. The static HTML and CSS export is the option for anyone who does not have Canvasola, and it renders the frames with no JavaScript and no interaction.

Can stakeholders open the flow themselves after the meeting?

They can open the static HTML export in any browser, and that shows the screens but does not walk them, because it has no JavaScript. If they need the links, send the .canv project file, which keeps the frames and their On tap go to links together and can be reopened in Canvasola.

Rehearse the path, then present it.

Open App Builder, order your frames, set the On tap go to links, and walk the flow in Present mode before anyone else sees it.

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.