Record an Interface Walkthrough for a Commercial Treatment
Record an Interface Walkthrough for a Commercial Treatment
A treatment argues for a look, and sooner or later someone has to open the app, record the two or three seconds that carry the argument, and hand over a file. The clip's job is narrow and unforgiving: show the interaction the treatment needs to discuss, without exposing private material and without quietly promoting a staged interface into a working product.
Three habits do most of that work. Record a prepared interface that holds no real customer data. Capture one bounded path instead of touring the product. Then watch the exported file rather than the preview, because the preview is a guess and the file is the recording.
Everything below follows one rule of thumb: a screen recording is evidence of exactly what it shows and nothing else. It does not establish that the interface works, that the response is fast, or that the data is real, and no amount of clean output changes that.
Name the action and the product state first
Before opening anything, write three sentences:
- The state the interface is in when the clip starts.
- The action the user performs.
- The visible response that proves the action did something.
Then say which of three things is actually on screen. Working software with real accounts and real data. Working software loaded with invented dummy data. Or a prototype: an interface with no engine behind it, returning static or scripted responses.
None of the three is automatically wrong. What's wrong is recording the third and captioning it like the first. A clip of a prototype is a clip of a prototype, and recording it in high resolution doesn't upgrade the category.
The example used through this article is invented for illustration, and no recording was made while writing it. It concerns a prototype called Northwind Shift Board, a local scheduling interface built for a treatment about filling open shifts. The screen is a week grid. Week 14 shows four dashed slots marked Open, and the header reads Open shifts: 4. Three chips sit on the bench: Alvarez, Okafor, Lindqvist. The path the treatment needs is one drag: Alvarez's chip onto Tuesday's open slot. The response is Tuesday taking the name and the header reading Open shifts: 3.
The rest of the run sheet is a list of what the prototype does not do. Other weeks render an empty grid. The Publish control is inert. The board takes roughly two and a half seconds to re-render after the drop. That list is the part people skip, and it's the part the caption will need.
Prepare the state you intend to capture
Invent the data. Real names and account details in a clip have a way of surviving the whole approval chain, and a treatment team that sees a plausible employee schedule will assume it is one. Dummy content also gives you a cleaner story: if the numbers are invented, nobody has to ask whose week this is.
Then sweep the frame for incidental information, which is rarely in the part of the screen you're thinking about. Signed-in email in a corner. An avatar. A recently-opened list. An autocomplete panel that drops down the moment you touch the field. A tab strip carrying another project's name. In the Northwind case, the browser window holds a second tab titled with a different project, and it is sitting in frame.
Silence notifications before the take, not during it. A calendar reminder arriving mid-clip is annoying; a reminder that arrives while desktop audio is recording and speaks a client's name out loud is worse.
Here is the distinction that matters most in this section. Window capture narrows the frame to one window, and that is all it does. It does not audit the contents of that window. If the window is displaying an account name, a customer record, or a client's project in a neighbouring tab, the recording captures exactly that. Choosing a source is a framing decision, not a privacy measure.
Set up the capture source and check it
This walkthrough stays on Windows, because the OBS project's window-capture documentation describes platform-specific behaviour and notes that the older macOS window source is deprecated. A recipe that claims to work everywhere is a recipe nobody has checked. Write down the OBS version and the OS build you actually used, because a capture that worked on someone else's machine isn't a claim you can repeat.
In OBS, a scene holds sources, and one of those sources is the window capture. The window-capture documentation covers four properties worth checking deliberately:
- Which window the source is pointed at.
- How the window is matched when the source looks for it again. This is the setting that decides what happens when two windows share a title, which is exactly the case that ruins first takes.
- The capture method.
- Cursor capture, which is a separate toggle from everything above and determines whether the viewer can see the pointer perform the drag.
The quick-start guide handles sources, audio, and testing in that order, and it treats audio as its own setup problem rather than a property of the picture. That separation is not pedantry. Checking the picture source does not check sound, and muting one does not mute the other.
So decide the audio before recording anything. For a clip destined for a treatment, silent is usually right: the treatment will carry its own voiceover and music, and a stray system chime is a defect. If a director wants the reasoning spoken, record narration as its own pass rather than talking over the live action, where a fluffed sentence costs the whole take. Then go through each audio input separately and disable the ones you don't want. Desktop audio is the one people forget, and it keeps recording whatever the machine plays.
Take an eight-second test and watch the file
Perform the action once, stop, and play the saved recording. Not the preview window — the file. The preview shows you a reconstruction; the file shows you what was encoded, at what dimensions, with what attached to it. The OBS guide asks you to test your settings for the same reason.
Three failures show up in this test, and each has a different remedy.
The clip is attached to the wrong window. The Northwind test came back showing an empty grid, because the prototype was open twice and the source had reattached by title to the other window. The remedy lives in the window-selection and window-match settings: reselect the window you mean, and make sure the match setting won't drift to a sibling. Then test again, because the whole point of a match setting is that you can't predict it by reading the label.
The framing includes chrome you didn't mean to show. The Northwind test carried the tab strip and the second project's title. Crop the source itself rather than zooming the recording later. A later zoom throws away resolution, and it leaves the leaked frames inside the file you're about to send someone, where they have to be remembered rather than avoided.
The cursor is missing. Without a pointer, the chip appears to move by itself, and a reviewer can't tell whether the interface responded or the recorder waited. Two answers are legitimate: switch cursor capture on, or record clean and let the treatment draw its own pointer. Pick one deliberately and note which you chose, because a treatment team that expects a pointer and gets none will ask, and the answer should not be a surprise.
While you're watching, check legibility at the size the clip will actually be seen. Full-screen text on your monitor can be unreadable in a quarter-frame thumbnail on a storyboard, and the board is where someone decides whether the interface is worth the shot.
Record the path without improving the product
Reset to the documented start state before the real take. If you don't, the second attempt begins at three open shifts and ends at two: the same interaction with different numbers, and now the clip and the run sheet disagree about what the interface does. Reloading the prototype returns it to four. Whichever state you record, make the clip and the sheet say the same thing.
Then hold the line between trimming and claiming.
Cutting ordinary setup is fair. Nobody needs to watch the app load, the recorder sign in with dummy data, or the window get resized. A stray click on the wrong tab is not part of the product's behaviour either, and removing it costs nothing. None of those cuts touch what the treatment is promising about the interface.
Trimming something the treatment is actually promising is a different act. If the drop takes two and a half seconds to re-render, that wait is a property of the interface. Speed it up to a snap and the clip implies response times the prototype does not have. Leave the wait in, or leave it in and label the change on the clip: something like prototype — render accelerated, actual ~2.5s. The label belongs next to the affected shot, not in the recorder's memory.
The same rule applies to errors and to state the interface never reached. Publish is inert in the Northwind prototype, so a clip cannot click Publish and cut to a confirmation screen as though the click produced it. Either end the clip before the click, or cut and label it plainly: the prototype does not act on Publish, and this state was advanced by hand. Stitching two real states together with an unmarked cut is the quietest way to manufacture a capability, because every individual frame in the clip is genuine.
Review the handoff at its intended viewing size
Play the export outside the preview, in whatever container the treatment team will use — a review page, a timeline, a deck. Confirm the action still reads, and confirm the numbers in the clip match the run sheet you wrote at the start.
Then recheck incidental data, because the interface changed state during the recording and something new may have become visible: a panel that opened, a field that populated, a status line that names an account. The Northwind clip gains a populated Tuesday and a changed header; those are the intended changes, and they're worth comparing against the sweep you did before recording.
Label the clip with its product state and any material edits, and keep the original file where policy permits, so a collaborator can tell captured behaviour from edited presentation. If the prototype is what's on screen, say prototype. If the data is invented, say so, briefly. If a wait was shortened, name the wait.
The reviewer should be able to answer one question from the clip and its label alone, without asking: did the product do that, or did the recording? A clean file that leaves that question open isn't a finished deliverable. It's a liability with good lighting.
Frequently asked questions
What is a screen recording evidence of?
Exactly what it shows and nothing else. It does not establish that the interface works, that the response is fast, or that the data is real.
How should I prepare an interface before capturing it?
Use invented dummy data, sweep the frame for incidental information such as signed-in emails, avatars, autocomplete panels, or other project tabs, and silence notifications before the take. Window capture narrows the frame but does not audit the window's contents, so choosing a source is not a privacy measure.
Why watch the exported file instead of the preview?
The preview is a reconstruction, while the file shows what was encoded, at what dimensions, with what attached. The test can reveal a wrong-window capture, unwanted chrome, a missing cursor, or text too small to read at the clip's intended viewing size.
Which edits are fair, and which can mislead?
Cutting ordinary setup such as app loading, sign-in, resizing, or a stray click on the wrong tab is fair. Speeding up or trimming something the treatment promises, like a two-and-a-half-second re-render, implies response times the prototype does not have unless the change is labeled. Stitching two real states with an unmarked cut can manufacture a capability even though every frame is genuine.
What should a reviewer be able to answer from the clip and its label?
Did the product do that, or did the recording? Label the clip with its product state and any material edits, say prototype and invented data when true, and name a shortened wait. Keep the original file where policy permits so captured behavior can be distinguished from edited presentation.