How to record a Figma walkthrough stakeholders will actually watch

A good design walkthrough is mostly preparation. Ten minutes tidying the file and planning what to say saves your reviewers from a meandering tour of the canvas.

By the VeoRec team · Oct 3, 2026 · 11 min read

Most people who record a Figma walkthrough for the first time do the same thing: open the file, hit record, and start scrolling around the canvas while explaining. The result is eight minutes of zooming, "wait, where was it", and a frame the reviewer cannot read because it is a quarter of the size of their player. The design might be excellent. The walkthrough hides it.

Almost all of the fix happens before you press record: a tidy page, a decision about prototype versus canvas, a window size that keeps text legible, and five lines of notes. The examples use Figma because most teams do, but Sketch, Penpot and Framer users can follow along; only the menu names change.

Decide what this walkthrough is for

A walkthrough for a design critique, one for a client approval and one for a developer handoff look similar but need different emphasis. Settle this before you open the file, because it decides what you show and what you leave out.

If you are presenting work for review, our guide to presenting design work async covers the written brief and how to collect decisions. This post is about the recording itself.

Prepare the file before you press record

Design files are workshops: explorations, old versions, sticky notes, a component page, a frame called "Copy of Copy of Home v3". Viewers do not need to see the workshop. Spend ten minutes making a clean stage.

• Make a presentation page. Duplicate or link the final frames onto a page of their own, laid out left to right in the order a user meets them.
• Name frames by what they are. "Checkout / Payment / Error" is readable when it appears on screen; "Frame 1247" looks unfinished.
• Move explorations out of sight. Put them on a separate page. If you want to show a rejected option, place it deliberately next to the chosen one.
• Use real content. Placeholder text and perfect sample names invite the question "what happens with real data?" Answer it before anyone asks.
• Check the prototype. Click through the whole flow once. Make sure the starting frame is right and every hotspot you will use is wired up.
• Close what you won't need. Other files, other tabs, chat apps. Turn on Do Not Disturb so a notification does not land on top of your hero section.

Use the prototype for the experience, the canvas for detail

The canvas is good at showing many screens at once, comparisons, annotations and states side by side. It is bad at conveying what using the product feels like. The prototype is the opposite. Most walkthroughs benefit from both: play the flow first so viewers understand the experience, then return to the canvas to explain details and edge cases.

Figma gives you two ways to play a prototype, according to its help page on playing prototypes: Preview, which plays it inline on the canvas (Shift+Space), and Present, which opens it in presentation view in a separate tab (Ctrl+Alt+Enter on Windows, Cmd+Option+Return on Mac). Presentation view is usually the better one to record.

• Hide the UI. The options menu in presentation view has a Hide UI setting that removes the toolbar and footer, which keeps the recording clean.
• Choose the scaling. Without a device frame you can pick options such as Fit width or Fit width and height. Pick whichever makes text largest without cropping.
• Decide on hotspot hints. Show hints on click highlights clickable hotspots with blue boxes when you click. It is helpful in testing and distracting in a polished demo; turn it off unless you want viewers to see what is clickable.
• Know the restart key. Pressing R returns to the start of the current flow, which is handy if you click the wrong thing mid-take.

Set up the screen so viewers can read it

Reviewers will often watch in a small player next to their email, or on a laptop at 1.5x speed. Anything you show must survive that. The main enemy is small text.

• Record only what matters. If you use Figma in the browser, record just that tab. With the desktop app, record its window. Recording the entire screen shows your dock, other windows and every notification.
• Zoom with intent. On the canvas, Shift+1 zooms to fit everything and Shift+2 zooms to the current selection. Select a frame, zoom to it, talk, then move to the next. Avoid slow continuous scrolling around the canvas; it is hard to watch.
• Prefer a moderate window size. A huge 4K canvas scaled down to a 1080p recording makes text tiny. A browser window around 1440 or 1600 pixels wide often reads better than a full ultra-wide screen.
• Keep the cursor calm. Viewers follow it. Move it to what you are talking about and leave it there, instead of circling while you think.

Mobile frames need a closer zoom than you think

A phone frame is tall and narrow, so it gets small fast. Say you zoom to fit a 390 by 844 frame in a browser tab recorded at 1080p. After the browser's own toolbars, roughly 950 pixels of height are left, so the frame is drawn at a little over 1.1 times its size and 14px body text comes out around 16 pixels tall. Watched in a player half that height, which is common next to an inbox, the text is about 8 pixels tall. That is the edge of legible, and helper text in 12px is past it.

The fix is to show the whole frame once, for orientation, then zoom to the part you are discussing: the top half with the form, the bottom sheet, the error message. Select the group and press Shift+2. Talking about one region at a time at double the size is easier to follow anyway, because the viewer knows exactly where to look.

Sound matters as much as the picture. People will forgive a slightly blurry frame long before they forgive muffled or echoing audio. Use a headset or any microphone placed close to your mouth, record in the quietest room you have (soft furnishings help), and do a five-second test: record, play it back, listen for fans, keyboard clatter and echo. If you type during the walkthrough, a microphone that is not on the same desk as your keyboard makes a noticeable difference.

A browser-based recorder handles this well because it can capture a single tab. VeoRec's Chrome screen recorder records a tab, a window or the whole screen through Chrome's own share dialog, at up to 1080p, with your microphone and an optional camera bubble. The video uploads while you record, and the share link is copied the moment you stop.

Plan what to say in five lines

Do not write a word-for-word script; you will sound like you are reading, because you will be. Write five short lines instead and keep them visible while you record. Our guide to scripting a screen recording goes deeper, but this is enough for a design walkthrough:

1. Hook What this is and what you need. "This is round two of the team invite flow; I need a yes or no on the sidebar prompt by Thursday."
2. Context Who the user is and what problem they have. One or two sentences.
3. The path The screens you will play, in order, with the one thing to notice on each.
4. Decisions and questions The two or three choices that matter, an option you rejected, and what you are unsure about.
5. The ask Repeat what you need, from whom, and by when. Then stop recording.

Type your hook, context and ask into the planner below to see how long they take to say out loud. If the opening alone runs past half a minute, cut it down; reviewers decide early whether to keep watching.

Narrate the user's thinking, not your layers

Designers often describe construction: "this is an auto layout frame with a 16 pixel gap, and this component has a variant for..." That is useful in a handoff to other designers and nearly useless to a product manager or client. Narrate what the person using the product sees, thinks and does.

Compare "here's the empty state component" with "you've just created a workspace, there's nothing in it, so the first thing you see is a single prompt to invite your team, because that's the step new admins skip." The second one explains the design, the reason and the goal in one breath.

Pause on decisions. When you reach a choice that matters, stop moving the cursor and say why: what you tried, what you picked, what tipped it. These are the moments reviewers will comment on, so make them easy to find. A chapter marker at each one helps; in VeoRec you press M while recording and name the markers on the finish screen.

Describe what the person using it thinks at each step, and the design explains itself.

Point, draw and highlight, sparingly

Your voice says what matters; your cursor says where. When a detail is small, such as a badge colour or an icon change, the cursor alone may not be enough. Drawing a quick circle around it or using click highlights makes it unmissable.

Use these tools sparingly. One arrow on the thing you are discussing helps; a screen covered in scribbles hides the design you are trying to show. Clear drawings before you move on, and avoid frantic circling, which reads as nervous rather than helpful.

Keep the camera bubble small and in a corner that does not cover the interface. A face helps clients and stakeholders connect with the work, especially when you present to people who have not met you, but the design is the subject. Before you start, check which corner of your layout stays emptiest across the screens you will show, and put the bubble there.

Keep it short and split long walkthroughs

There is no ideal length, but there is a reliable rule: one recording, one purpose. A single flow usually fits in a few minutes. If you are walking through a whole product redesign, record one video per flow or per section and send them together, so each reviewer can watch the part they own.

Chapters make longer recordings bearable. Name them after what is on screen ("Checkout: payment error") rather than generic labels ("Part 3"). Viewers can jump straight to their part, and you can reference a chapter in follow-up messages. See how long a work video should be for guidance by purpose.

A sample walkthrough, minute by minute

A four-minute review recording of a redesigned checkout might run like this. The timings are a guide, not a rule; the order is the useful part.

Notice what is missing: no tour of the components page, no explanation of the auto layout settings, no apology for the file being messy. Everything on screen earns its place, and the ask appears twice, at the start and the end, so a reviewer who only catches the beginning or skips to the last chapter still knows what you need.

Fix mistakes afterwards instead of re-recording

Chasing a perfect take eats more time than any other part of recording. You stumble at minute three, start again, stumble at minute four, start again. Instead, keep going: pause for a second, say the sentence again, and cut the bad take afterwards. Most viewers do not mind a natural "let me go back to that" anyway.

In VeoRec you can trim the start and end, cut a section from the middle, split a clip and remove silences in the browser. If a client name, a private file in the sidebar or another customer's data was briefly on screen, draw a blur box over it and render to apply it before you share.

Share it where the feedback will happen

A walkthrough link pasted into a busy chat channel scrolls away within the hour. Put it where people will look for it: the ticket, the top of the design file, the project brief, or the email thread with the client. Include the questions and the deadline in the message itself, not only in the video.

Decide where comments go. If they go on the recording, reviewers can leave timestamped notes, reply in threads, and pin a note to a point on the frame, and you can resolve each thread when it is handled. If they go in the design file, say so. What matters is one place, not three. If the walkthrough is for a developer, link it in the handoff ticket alongside the rest of the design handoff package.

Clients and outside stakeholders often do not have, or want, a login for your design tool. A plain link that plays in the browser lowers the barrier. With a screen recorder built for design reviews, viewers need no account to watch, and when you have several walkthroughs for one project, a folder review link shares the whole set at once, either view-only or with comments allowed. Keep the file itself for the people who will actually work in it.

Finally, keep the recording findable after the review. Link it from the frame or page it explains, so that when someone asks in three months why the checkout became a single page, the answer is one click away instead of buried in an old thread.

What to do next

Before your next design review, make a presentation page with the frames in user order, write the five-line outline, and do a single sound check. Record one take in presentation view and on the canvas, trim the stumbles rather than starting over, and share it with the ask written in the message. Then watch it back once at the speed your reviewers will: if any text is too small to read, zoom in further next time.