Make a Contributor Recording Guide for a Video-Diary Test

If you are asking someone to record a video diary for a pitch test, send four things: what you are asking for and why, one workable way to capture it, a request for a short sample before the real recording, and clear instructions for sending the file and for stopping. Keep the technical guidance in one lane and the person's account in another. You can be very specific about where the phone sits, name the subject you want covered, and still leave the telling of it — the wording, the angle, the manner — to the contributor.

That is the whole shape. The rest of this is how to write each part, what to leave out, and what to do when the sample comes back with a problem.

The distinction to hold onto is that an editorial prompt and a capture instruction are different instruments. "Tell us about your morning" is an editorial prompt: it names a subject and, in a pitch, it is a hypothesis about what might be interesting. "Hold the phone horizontally and prop it at eye level" is a capture instruction. The guide you send is made mostly of the second kind, with one bounded piece of the first: the line that names the subject the diary should cover. Naming the subject is part of the request, and that is as far as the editorial side reaches. It stops short of framing the subject, choosing an angle on it, or saying how the contributor should sound while covering it. The contributor already knows their own account; what they may not know is which file to send you, and whether the fan in the corner is a problem.

Write the request before the camera instructions

Open with the request in ordinary language. What is this recording for, roughly how long should it be, who will see it, and what happens to it afterwards. A pitch test is not a broadcast, and saying so plainly removes a real source of hesitation. If the material might be shown to a commissioner or included in a document, say that too. People manage uncertainty badly when it is left unnamed, and the uncertainty they will invent is usually worse than the truth.

This is also where the subject belongs, stated as plainly as you can manage and then left alone. A sentence that names the topic is the request doing its job; a paragraph that explains what the contributor should notice about it, or how they ought to come across while describing it, has crossed into direction. Give them the subject and stop.

Then state what the contributor does not need to record. Other people. Anyone else's room. Anything they would have to negotiate access to, or ask someone to leave the house for. Sensitive events, medical or otherwise. That list does useful work offline as well: it is what keeps a small agreed diary task from quietly expanding into something larger between the first message and the fifth.

Say where questions go. One named person, with a route to reach them. "Reply to this email and I'll answer the same day" is better than a general invitation to get in touch, because it tells the contributor that asking is expected rather than tolerated.

One boundary belongs here rather than in a footnote. This guide implements a request the team has already agreed with the contributor. It does not establish permission, and it does not replace whatever consent, release or welfare arrangements the production has made. Those are separate documents with separate owners, and a capture guide that implies otherwise is doing something it has no authority to do. If the contribution is for a factual series, the arrangements around it will be more involved than a diary test — the guide is simply the practical part someone actually reads before pressing record.

Explain one workable setup, not every possible device

A guide that lists six ways to record has transferred the decision back to the contributor, which is the opposite of the point. Pick the device and the destination you genuinely intend to use, and describe one setup clearly.

That means naming the specifics: framing (head and shoulders, or full frame, whichever you need), orientation (and this is your choice, driven by where the footage will be used — a preferred orientation is a production decision, not a universal rule), how the phone stays still (propped on something, not held), and what the room should be like. A quiet space with the door closed. A window or lamp in front of the contributor, not behind them, so the face is not a silhouette. The phone roughly an arm's length away at about eye level, front camera switched on so the contributor can see that they are actually in frame.

Then build in the check that catches most problems before they matter: play the recording back once before sending it. Can you hear every word? Is anything blocking your face? It takes fifteen seconds and it saves a re-recording of a personal account.

You can draw on other people's published guidance here, as long as you keep its scope. Shelter's design framework publishes a practical self-shooting guide with concrete contributor-facing advice on a stable picture, intelligible sound and deliberate preparation before recording. It is a useful model for exactly this kind of plain instruction and a reminder that "make the picture stable and the speech audible" carries more weight than any list of camera features. It is also, by its own context, a UK campaign-production guide. Its preferred orientation and procedures are that organisation's practice, not a universal TV standard, and reading it establishes nothing about permissions or participant arrangements in your own production.

Finally, leave the door open. If the prescribed setup is not possible — no quiet room, no stand, shared space, low storage on the phone, a shift pattern that leaves no daylight hour — say so in the guide and give a route to discuss it. A clean frame is not worth making the contribution impossible to produce, and the contributor who quietly cannot meet the instruction is the one who sends nothing at all.

Ask for a small sample and give usable feedback

Before the complete account, ask for a brief, non-sensitive recording. Twenty seconds. Reading the first paragraph of the guide aloud, or describing the room they are sitting in. It is the same setup and the same kind of speech, without asking anyone to perform a piece of their actual account so you can critique it. That separation matters more than it first appears: if the thing you diagnose is also a passage the contributor cared about recording, a technical note arrives as a comment on the content.

When the sample comes back, check the returned original file rather than a preview inside a messaging app. Previews are often re-compressed in transit, so the thing you are diagnosing may not be the thing you will work from — you can end up chasing a problem the original does not have, or missing one the preview introduced.

Give feedback as one observable issue and one adjustment. "The fan is louder than your voice at the end — can you switch it off, or move to the other side of the room?" "Two files arrived with the same name, so I can't tell which is which — add the date to the filename." Each of those tells the contributor what you heard or saw, and exactly what to change.

The failure mode is converting a technical problem into an editorial one. "We can't hear the ending" is a capture note. "Try to sound more excited at the end" is a direction, and it teaches the contributor that the recording is being judged on performance rather than on content. From there, everything they send is a guess about what you want. The same applies to any request to re-record. A second take to fix the fan noise is a technical retake, and it is fine. A second take because the first was not enthusiastic enough is scripting with extra steps.

Make delivery and stopping clear

Naming and transfer go together. Give a filename pattern — diary-firstname-YYYYMMDD, with whatever extension the phone produces — and name the route: this upload link, that folder, this messaging thread. Then name the person who acknowledges receipt, and roughly when. An unacknowledged file is a contributor wondering whether they got it wrong.

Keep the original capture separate from anything compressed or edited. If someone on the team makes a rough selection later, it should not be confused with the source file the contributor sent, and the contributor should know that the original is what is being stored.

State how to pause. If the contributor gets halfway through and decides they would rather not say the rest, that is allowed, and the guide should say so before they start rather than in a reply afterwards. Give the alternative route too: if the diary form does not fit, what else could they send. Then, finally, keep any reconstruction or repeat identified. A retake that fixes audio, or a passage re-recorded on a different day, is labeled as such when it is passed along. A technical retake must not become apparently spontaneous first-person evidence, because the moment it does, the pitch is misrepresenting its own material.

A constructed example

What follows is invented to show the method. No contributor has been recruited, recorded or asked anything, and no file has been sent or received. The task is fictional and deliberately non-sensitive: describe arranging a desk before starting work.

A one-page guide for this test might read:

What this is. A short self-recorded test for a pitch. About eight to ten minutes of you talking, in one file. It is not broadcast. It will be seen by me and the producer, and may be included in a pitch document. You can stop at any point.

What to describe. How you set up your desk before you start work. That is the whole subject. You do not need to record anyone else, go into anyone else's room, or cover anything you would rather leave out. If your usual routine involves someone else being there, skip it or just mention that it happened.

How to record. Phone, horizontal, propped upright on something stable at about eye level, an arm's length away. Front camera so you can see yourself. Head and shoulders in frame, you in the middle. Window or lamp in front of you, not behind. Quietest room, door closed. Before you send anything, play it back once: can you hear every word, is anything blocking your face?

If that doesn't work. No quiet room, no stand, shared space, not enough storage — tell me and we'll find another way. There's no single required setup.

Sample first. Record about twenty seconds — read this paragraph out loud, or describe the room you're in. Send it and I'll reply about the sound and framing only. Then record the longer piece.

Sending. Name the file diary-mara-20260304, with whatever extension your phone produces. Upload to the link below. I'll confirm receipt within a day.

Stopping. Pause, stop or withdraw whenever you like. Questions to me — [name], [contact]. Consent and release are handled separately.

Two replies to the returned sample. In the first, the sample has audible fan noise and arrived with a filename that does not match the pattern, so the team cannot tell it apart from an earlier file.

Thanks — got it. Two things before the longer recording. The fan is coming through louder than your voice across the whole clip, so please switch it off or move to the other side of the room; everything else about the framing is fine. And the file arrived as VID_0341, so could you rename it to the pattern in the guide — diary-mara-20260304 — before you send the main one. If you want to confirm the fan fix first, just send a fifteen-second clip with the fan off and I'll check it. No need to re-record anything you've said.

And the second:

Got it, thanks. It's a bit flat — could you do another one with a bit more energy, and really get into how the desk setup makes you feel about the day ahead? Also the fan's audible and the filename's wrong.

The second reply reads as helpful. It names the same two problems. But look at what the contributor now has to do. "A bit flat" is a judgment on their delivery. "How the desk setup makes you feel about the day ahead" is a supplied interpretation — an angle on the subject, attached to it before the contributor has had a chance to find their own, and one they will now try to match. The two technical problems that were actually blocking the file are buried at the end of the sentence, as an afterthought.

The first reply has a different effect. The contributor knows precisely what to change and precisely what to keep. Nothing in it touches what they said, so the longer recording stays theirs. It also leaves the content alone in a way that will matter later: when the pitch shows this material, the team can describe it accurately, because nobody was told what to produce.

Notice what neither reply does. Neither evaluates whether the account was interesting, true or emotionally complete. A fabricated diary has no correct answer to grade, and a real one does not either. The questions worth asking about a returned sample are whether the file is usable and whether the contributor is clear about what happens next.

What to send

The sendable artifact is three short parts on one page: the request, with its limits; the capture instructions, with one alternative route; and the send-and-stop details, with a named person. A sample step sits between the instructions and the real recording, and it is what makes the rest of it work, because it means the first thing you diagnose is never the thing the contributor cared most about saying.

Test the route on yourself before you send it. Take the guide, record the twenty seconds, follow your own transfer instructions, and see which line produces a question. You will usually find one, and it is cheaper to find it in your own kitchen than in a contributor's first reply. The device and export route you can only confirm by walking through them, since what a phone names its files and how a platform compresses an upload are specific to the equipment in front of you.

Then keep the line intact. You can name the subject and be exact about framing, sound, filenames and where to send the file. Helping someone record is not the same as directing what their experience should sound like, and a guide that stays on its own side of that line produces something more useful than a script — it produces an account the contributor actually chose to give.

Frequently asked questions

What four things should a contributor recording guide send?

It should state what you are asking for and why, give one workable way to capture it, request a short sample before the real recording, and provide clear instructions for sending the file and for stopping.

What is the difference between an editorial prompt and a capture instruction?

An editorial prompt names a subject, such as 'tell us about your morning,' while a capture instruction governs the recording setup, such as holding the phone horizontally and propping it at eye level. The guide is made mostly of capture instructions, with one bounded editorial piece: the line naming the subject. Naming the subject is part of the request, but the guide should stop short of framing the subject, choosing an angle on it, or saying how the contributor should sound.

What should be said about what not to record and where questions go?

State that the contributor does not need to record other people, anyone else's room, anything requiring negotiated access, or sensitive events, medical or otherwise. Give one named person and a route for questions rather than a general invitation. The guide also should not imply that it establishes permission or replaces separate consent, release, or welfare arrangements.

Why ask for a short sample first, and how should feedback be given?

Ask for a brief, non-sensitive recording, such as twenty seconds reading the guide aloud or describing the room. Check the returned original file rather than a messaging-app preview, since previews can be re-compressed. Give feedback as one observable issue and one adjustment. Do not convert a technical problem into an editorial direction, such as telling the contributor to sound more excited.

How should delivery and stopping be handled?

Give a filename pattern and the route for transfer, name the person who acknowledges receipt and roughly when, and keep the original capture separate from compressed or edited versions. State that the contributor can pause, stop or withdraw, give an alternative route if the diary form does not fit, and label any reconstruction or retake as such when it is passed along. A technical retake must not become apparently spontaneous first-person evidence.