All articles

How to storyboard a SaaS product video before animating it

Plan a SaaS video storyboard around visible product states, scene transitions and missing evidence before committing to animation.

A script can read clearly while leaving the person making the video with a lot of unanswered questions. Which screen are we looking at? What changes after the click? Does the result appear beside the input or replace it? Those decisions belong in the storyboard.

You don't need polished illustrations to make it useful. A few rough frames, current screenshots and notes about what changes can expose a missing step before anyone spends time animating it. The goal is to agree on the explanation you can see, not just the words you'll hear.

Start with the states the viewer needs to connect

Imagine a fictional scheduling product that turns a list of interviewers into an available interview slot. Your script says, 'Choose the panel and find a time everyone can make.' That line contains at least two visible states: the people selected and the available times returned. A storyboard should account for both.

Write those states down before choosing transitions. For each one, identify the screenshot, recording or verified product information that supports it. If you only have a picture of the final calendar, you don't yet have enough material to show how the panel was chosen.

This scheduling example is hypothetical, not an output we've made or reviewed. Use actual states from your product for production. A missing reference is a question to resolve with the product owner, rather than an invitation to invent a plausible screen.

Give every frame a reason to exist

For each frame, write what someone should notice first and what they should understand before it changes. In the panel-selection frame, that could be the selected interviewers. In the next frame, it could be the available slot that corresponds to those people.

Then ask what can disappear without changing that explanation. A sidebar full of unrelated settings may be accurate but distracting. You can crop the view while preserving the relationship you're demonstrating. Record the crop in the storyboard so it isn't rediscovered halfway through production.

Avoid giving every element equal emphasis. If the headline, cursor and new result all move at once, the viewer has to decide what matters. Sketch the order you want them to notice things, even if your drawings are just boxes with labels.

Describe what carries across the cut

A transition is also a change in context. If one frame shows a selected panel and the next shows a calendar, leave enough continuity for someone to connect them. That could mean keeping the panel names visible briefly, or repeating a clear label above the results.

Write down what stays, what leaves and what appears. This is more useful than asking for a 'smooth transition,' because the designer can see which relationship the movement needs to preserve. The exact effect can come later.

Check whether a change in scale could look like a change in product state. A zoom into a date should still show the same date, selection and availability. If the storyboard silently swaps the data between frames, a polished transition will only make the inconsistency harder to notice.

If you are deciding how two related frames should connect, compare the match-cut example in the Motion Library before choosing the transition.

Compare a match cut

Separate the real interface from an explanatory diagram

Sometimes the product doesn't show the relationship you need to explain in one place. You might use a simple diagram showing the selected people feeding into a shared availability check. Label it as an explanation rather than styling it to look like an actual product screen.

Mark that distinction in the storyboard itself. A designer joining later should know which frames need to match the current interface exactly and which are conceptual. Otherwise an attractive diagram can accidentally become a claim that a particular dashboard exists.

Give narration space to explain important visual information as well. W3C describes integrated visual description as something you can plan into the main audio. Deciding what the audience needs to understand while storyboarding helps you avoid relying on an unexplained visual later.

W3C: planning descriptions of visual information

Use a frame record that exposes unanswered questions

Here's a hypothetical record for one point in the scheduling sequence. Make one record for each meaningful change rather than assigning an arbitrary number of frames to every sentence.

Frame: Available interview times.
What the viewer already knows: Three interviewers have been selected.
What must be visible: The selected panel and one available time.
Source: Current product capture, still needed.
What changes: Availability results appear after the check completes.
What remains: Panel names, so the result has context.
Narration: Choose an available time for this panel.
Accuracy question: Does selecting a time book it, or open a confirmation step?
Next frame: Depends on the confirmed product behavior.

Approve the sequence before polishing its appearance

Walk through the frames in order with the product owner and someone who doesn't know the workflow. Ask the second person to explain what happened, and ask the first person whether it matches the product. Those are different checks, and both can reveal changes worth making.

Resolve questions that change the story before treating the storyboard as approved. In the scheduling example, whether a selection immediately books the interview changes the ending. Choosing an accent color doesn't resolve that problem.

Once the sequence is clear, keep a copy with the approved source references and date. Animation can refine the pacing and presentation, but the storyboard gives everyone a shared record of the product behavior they agreed to show.