How to prototype an app without code

Decide how interactive the prototype has to be

A no-code prototype is only worth building if it answers a question, and the question decides how much interaction you need. Asking whether people understand the structure of an app needs linked frames. Asking whether one interaction feels right needs the frames around it to be convincing.

In Canvasola App Builder the interaction you can build is frame-level. You select a frame and set On tap go to in the frame inspector, and that whole frame points at another frame. There is no way to attach a link to a single button, so the finest grain of a prototype is the screen.

Name the level you are working at before you start: a static set of frames, a linked walkthrough, or a linked walkthrough with the reasoning written beside it. Most people who ask for an interactive prototype want the second one, and saying so saves hours of building.

• Static frames answer questions about structure and wording
• Linked frames answer questions about order and flow
• Frame-level On tap go to is the only link App Builder offers

Note: If a prototype needs to show a small interaction, such as a sheet sliding up or a toggle changing state, that has to become its own frame. There is no component-level linking to fall back on.

Choose which transitions get a link and which stay linear

Not every transition needs a link. If your frames are already in the order a user would meet them, Present mode advances through them on its own, and a link adds nothing. A link earns its place where the order is not obvious or the flow branches.

Set the link on the frame the user is leaving. Select that frame, open the frame inspector, and set On tap go to to the destination. Turn on Show prototype links and the links appear as arrows between frames, which makes a wiring mistake obvious at a glance.

Keep a written list of the links as you make them. A jump from the cart straight to the receipt is a decision you will want to explain, and a list of frame, target and reason is the cheapest documentation you will produce for a prototype.

1. List the jumps. Write the frames in reading order and mark the transitions that are not obvious from that order.
2. Set the link. Select the frame the user leaves, open the frame inspector and set On tap go to to the destination.
3. Show the links. Turn on Show prototype links so the arrows appear and you can check the wiring.

Run the flow in Present mode

Present mode is where a prototype earns its keep, and it is keyboard driven rather than pointer driven. ArrowRight or Space takes you to the next frame, ArrowLeft steps back, and Esc leaves the mode. You are the one advancing the screens.

Forward follows the link when a frame has one and otherwise advances linearly. Backward is always linear. Going back does not retrace the path you took, so the frames should still make sense when someone walks them in a straight line.

Do a dry run before the session. Press through the whole thing at speed and write down the sentence you would say at each frame. The frame where the story stops making sense is much cheaper to fix in the editor than in front of a room. The shortcut sheet lists the keys.

• ArrowRight or Space for the next frame, ArrowLeft for the previous one, Esc to exit
• Forward follows a link when the frame has one, backward is always linear
• A dry run at speed before anyone else sees it

Know what a frame-level link cannot do

A frame-level link moves the whole screen. It cannot open a sheet, dismiss a dialog, toggle a control or change what is inside a button, because App Builder has no component-level links. If the moment depends on a small interaction, show it as a separate frame.

There are no pointer-driven hotspots in Present mode either. A reviewer cannot press the primary action in your frame and watch the next screen arrive; you press the key and the next frame takes over. Narrate around that, because someone reaching for the mouse will get no response.

The workarounds are honest and they hold up. Build the interaction as its own frame, use a Dialog or Bottom sheet component to represent the moment, and put a short label in the frame that says what a tap would do.

• Links move frames, never individual controls
• No tap targets inside a screen during Present mode
• Dialog and Bottom sheet components carry the moment instead

Note: This is the honest boundary of a browser prototype without code. It tests sequence, wording and hierarchy, and it does not test the feel of an interaction. Treat that as the limit of the method rather than a missing feature.

Hand the prototype over as files you can send on

A prototype that only lives in your browser is one only you can show. App Builder exports to PNG at 2×, JPG, JSON and static HTML with CSS. The HTML export is absolute-positioned divs with inline styles and a small embedded stylesheet, with no JavaScript and no interaction.

The JSON export is the one to keep. It is re-importable, so you can send it to a colleague, they open it in Canvasola and the frames, the links and the layout come back. That makes JSON the handover artifact and PNG the thing people look at. The export guide covers the formats in full.

App Builder work is stored inside the .canv project file, so saving the project and sending that file hands the work over intact. Pick one format per audience and say what each one is for: images to look at, JSON to keep editing, HTML to open in any browser.

• PNG at 2× for images, JPG when a smaller file matters
• JSON when the recipient will keep editing
• Static HTML and CSS for a browser view with no interaction

Separate what you test from what you build

A prototype answers questions. It is not the product, and treating it as the product produces the wrong kind of feedback, because people start commenting on corner radius and color instead of on the flow. Say what the prototype is for before you show it.

Keep it honest about its limits. There is no real data, no real loading time, and no error states beyond the ones you drew, and any of those can be mistaken for finished work. Realistic content helps, and so does naming the gaps in a short note beside the frames.

After the walkthrough, write down what you will change and what you will not. A list of decisions with the frame each one belongs to turns a prototype into a specification. The mockup tutorial covers the build side, and presenting a multi screen flow covers the session.

• Name the question the prototype exists to answer
• Say what the prototype cannot show before the session
• Record decisions and deliberate omissions after it

A checklist you can reuse

• The question the prototype has to answer is written down in one sentence
• Every link is frame-level On tap go to, set in the frame inspector
• Show prototype links is on and the arrows point where you expect
• The flow has been dry run in Present mode with ArrowRight, ArrowLeft and Esc
• No claim is made that a reviewer can tap a control inside a screen
• An export exists in the format each audience needs: PNG, JSON or HTML
• Decisions and deliberate omissions are written down after the session

Common mistakes to avoid

• Linking a button to a frame. Only frames carry an On tap go to link. If a specific control has to lead somewhere, build the interaction as its own frame and link the frame.
• Expecting pointer navigation in Present mode. Present mode advances with the keyboard, so a reviewer pressing a button in your frame gets no response. Narrate the interaction instead.
• Linking every transition. A link on every frame makes the flow harder to read and hides which jumps matter. Link the branch points and let the rest advance linearly.
• Handing over only images. A PNG set cannot be edited and carries no links. Send the JSON export as well so the recipient can keep working on the frames.
• Presenting a prototype as a finished product. Comments then land on styling instead of the flow, and the feedback you need gets lost. State the purpose before you press a key.

Frequently asked questions

Can a reviewer tap through a Canvasola prototype?

Not in the sense of taps on individual controls. App Builder links are frame-level, set with On tap go to in the frame inspector, and Present mode advances with the keyboard rather than with pointer input. What you can build is a linked walkthrough where one frame hands over to the next.

What is the difference between the HTML export and the JSON export?

The HTML export is a static page of absolutely positioned divs with inline styles and a small embedded stylesheet. It has no JavaScript and no interaction, so it shows the screens and nothing else. The JSON export is re-importable, so it brings the frames, the layout and the links back into Canvasola for editing.

How many frames should a prototype have?

Enough to answer the question you set out to answer, which is usually three to six. Extra frames make the walkthrough long and dilute the point. If you cannot say which question a frame serves, it probably does not belong in the prototype yet.

Can I test a real interaction with a Canvasola prototype?

Not the feel of one. A prototype can show that a sheet exists and what it contains, because that is a frame with a Bottom sheet or Dialog component in it, but it cannot show the sheet sliding, the timing or the scroll behavior. Test those in code, and use the prototype for sequence, wording and hierarchy.

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.