A product spec mind map that matches your mockups

Open the Product Spec template

The Product Spec template is one of the 13 starters Canvasola ships with, filed under business in the gallery. It arrives as a root called Feature Spec with five branches: User & Problem, Goals / Non-Goals, Solution, Metrics and Rollout Plan. Solution holds two children, User flow and Edge cases.

That structure is organized by aspect rather than by screen, which is how most teams write a spec and how almost nobody reads one. User & Problem, Goals, Metrics and Rollout Plan are shared background, while the part a designer and an engineer need is a screen-by-screen list.

Keep the shared parts and rebuild the rest. The mockup tutorial covers the App Builder side of this work, and the business model canvas guide shows the same technique on another template: keep the branches that frame the work, replace the ones that do not.

• Five branches, and only Solution arrives with children
• User & Problem, Goals and Metrics are shared across screens
• User flow and Edge cases are the two that need a home per screen
• The root label names the feature, not the words Feature Spec

Note: Choosing a template replaces the open map, so keep any earlier work in another workspace tab before you start.

One branch per screen or flow

A spec is a promise about what the user can do, and it is easier to keep when each screen has its own branch. Add a branch with Tab on the root for each screen, name it the way the user would describe it, such as "Home", "Pay" or "Receipt", then hold Shift and drop the template's User flow and Edge cases under the right screen.

Group the screens into a flow when the feature has a journey. A branch called Checkout with the children Cart, Address, Payment and Confirmation reads as one flow, and the person building it can see the order of the screens at a glance.

Keep the number of branches honest. A feature with twelve screens is usually two features, and a feature with one screen is usually a setting. Splitting the map early costs nothing, while splitting it after the mockups exist costs a week.

• One branch per screen, named the way the user names it
• A flow is a branch whose children are the steps
• Two features in one map is a sign to split the map
• Delete the branches the feature does not need

Write what the user must achieve

Every screen branch needs one sentence saying what the user must be able to do when they are on it. "Confirm the order and pay", not "the checkout screen". If the screen cannot be built to satisfy that sentence, the screen is wrong, and finding out on the map costs a minute rather than a sprint.

Put the sentence in the branch label, because the label is what everybody reads. The note under it holds the rules that make the sentence true: what happens to a saved card, what the timeouts are, which fields are optional. Rules that apply to the whole feature belong in Goals / Non-Goals.

A screen whose goal you cannot write in one line is a screen doing two jobs, and splitting it in the map is cheaper than splitting it later. The multi screen flow guide shows how the same list becomes a presentable sequence.

1. Write the goal in the label. One sentence saying what the user must be able to do, phrased as an action.
2. Move the rules into the note. Timeouts, defaults and edge cases go in the note under the screen they affect.
3. Check the non-goals. Keep the Goals / Non-Goals branch to what the whole feature refuses to do.

List the states and the empty ones

A screen is never one screen. There is the normal case, the loading case, the empty case, the error case and the case where the user lacks permission, and the spec has to name all of them. The template's Edge cases child is the right place, so move it under each screen branch.

The empty state is the one teams forget, and it is the one users meet on day one. Write what the screen shows when there is nothing yet, and what the single action is that fills it. The App Builder has an Empty state component, so the mockup and the spec can use the same words.

Give each state a child node rather than a line in a note, so the screen branch shows how many states it has. A branch with one child has a happy path, and a branch with five has a product somebody has thought about.

• Normal, loading, empty, error and permission for every screen
• The empty state is what a new user meets first
• One child node per state, so the count is visible
• State names match the component names in the mockup

Pair each branch with a mockup frame

A spec that describes a screen nobody has seen is an argument, and a frame is the answer. Switch to App Builder, add a frame, and name it after the branch it belongs to: Pay for the branch called Pay. New frames open at 390 by 844 for mobile and 1280 by 800 for web, and the frame inspector offers device presets from iPhone SE up to Desktop.

Build the frame from the goal sentence rather than from the wireframe in your head. One frame per screen branch, and if a branch has five states, one frame per state or one frame with the states in the note.

Keep the naming identical on both sides. A branch called Pay and a frame called Payment screen will drift apart within a week, and the spec will describe a screen that no longer exists. Build the frames after the branches, not before.

• Frame names match the branch names exactly
• 390 by 844 mobile and 1280 by 800 web by default
• One frame per screen branch, one per state if needed
• Build the frame from the goal sentence, not from habit

Keep the spec and the prototype together

The spec and the mockups drift apart the moment they live in different places, so keep them in one project. A .canv project file is JSON with a CANV1 header holding the canvas elements, the style, the mind map, the App Builder project, the camera and the layout mode, so one file carries both halves of the feature.

Save it with Ctrl/Cmd+S and reopen it with Open Project…. Undo and redo are shared across the canvas, the mind map and the App Builder, and the history keeps 20 versions, so an accidental drag in a frame can be undone.

To look at both at once, use split view, which shows a second canvas tab side by side with a draggable divider. Put the spec in one tab and the frames in the other, and you can check a screen branch against its frame while the meeting is still running. The project file guide covers keeping that file safe.

• One .canv file holds the map and the App Builder project
• Ctrl/Cmd+S saves, Open Project brings it back
• Undo is shared across the canvas, the map and the builder
• Split view shows the spec and the frames side by side

Note: Prototype links are set per frame with On tap go to, and Present mode is keyboard driven with no hotspots inside a frame. A flow in the spec is therefore a list of frames rather than a tappable prototype.

A checklist you can reuse

• The root names the feature rather than the words Feature Spec
• Every screen has its own branch, named as the user names it
• Each branch label holds one sentence about what the user achieves
• Loading, empty, error and permission states are listed per screen
• Goals and Non-Goals stay at the level of the whole feature
• Every screen branch has a mockup frame with a matching name
• The map and the App Builder project are saved in one .canv file
• Split view was used to check the spec against the frames

Common mistakes to avoid

• A spec with no screen list. The template arrives organized by aspect, so it can stay a general description forever. Add one branch per screen early, while it is cheap.
• Describing a screen instead of a goal. A branch called Checkout screen tells the team nothing to build. Write what the user must be able to do there, in one sentence.
• Forgetting the empty state. New users meet the empty screen first and nobody designs it. Name it in the spec and add an Empty state component.
• Separate files for the spec and the frames. Two documents drift apart within a week. Keep both in one .canv project so a single save captures the map and the builder.
• Promising a tappable flow. Frames have no hotspots and Present mode is driven from the keyboard. Describe the sequence of frames rather than promising taps that do not exist.

Frequently asked questions

Should a product spec be a mind map?

The map is good for the structure and bad for prose. Use it for the screen list, the goals and the states, and keep the long reasoning in the rich notes, which hold up to 80,000 characters each of their own.

How do I keep the spec and the mockups in step?

Keep them in one .canv project file, which stores the mind map and the App Builder project together, and name every frame after the branch it belongs to. When a screen changes, the branch and the frame change in the same session and the same save.

What should one branch of the map hold?

One screen, one sentence about what the user achieves there, and one child node per state that screen has. If a branch needs more than that, it is probably two screens, and splitting it in the map costs nothing compared with splitting it after the frames exist.

Can I present a product spec from the map?

You can present the map as slides, with the root first and then one slide per first-level branch, and pair that with the frames in split view. What you cannot get is a tappable prototype, because prototype links are set per frame and Present mode is keyboard driven.

This guide is part of the template guides collection. For the wider product tour, read the complete Canvasola guide, and keep the keyboard shortcut cheat sheet open while you work.