Video discovery brief planning establishes what a video needs to explain, who will watch it, and which decisions must be resolved before production. The brief turns stakeholder conversations into a usable assignment, with sources, responsibilities, and limits that a production team can check.
Listening matters because an initial request often combines a communication problem with a proposed solution. Someone may ask for a short interview, an animated overview, or a new company introduction before the audience question has been agreed. Discovery tests the reasoning behind that request and records what is known, what is assumed, and what still needs a decision.
Decide what the video discovery brief must establish
A video discovery brief should establish the audience, the explanation, the intended use, and the conditions for approving the work. It should give the team enough information to propose a scope without inventing missing facts.
Start with the situation that prompted the request. A sales team may be repeating the same explanation, or employees may be uncertain about a new internal process. These situations suggest questions to investigate. They do not establish that a particular video format will solve the problem.
Record the difference between the business objective and the communication task. An objective might be to reduce confusion during onboarding. The video’s assignment could be to explain where a new employee submits a particular request. The second statement is specific enough to shape scenes and questions.
Keep the brief readable. Important decisions should be easy to find without reconstructing a meeting transcript. Supporting notes can sit separately, with references showing where a requirement came from.
Separate discovery conversations from filmed interviews
A discovery conversation investigates the assignment; a filmed interview supplies material for the finished video. Explain which conversation is taking place before asking someone to participate.
During discovery, a participant may describe a difficulty that should remain internal. Their comments can help define the project without becoming a public quotation. Agree how notes or recordings will be used and who will have access to them.
A discussion guide can help different interviewers cover the same topics. GOV.UK’s in-depth interview guidance recommends open, neutral questions and follow-up discussion grounded in actual experiences. Those principles are useful when investigating a video request, although a production brief needs its own questions about assets, review, and delivery.
Test the questions with a colleague before the session. Remove wording that implies a preferred answer, and leave room for an unexpected problem to emerge. The purpose is to understand the situation well enough to make a decision.
Listen for the task behind the first request
Ask what happened before someone decided a video was needed. A concrete incident usually gives more useful information than a general statement that communication should improve.
If the request is for a company overview, ask which conversation it will support. Find out what the audience already knows and where the existing explanation becomes difficult. An overview for new employees may need different context from a presentation for prospective customers.
Let the participant finish before proposing a format. Then summarize what you heard and ask whether the summary is accurate. Distinguish their account of a problem from your interpretation of its cause.
Request an example of the material currently used, where sharing is permitted. A slide, process note, or recurring question can help the team identify missing context. Check whether the material reflects the current situation before using it as a production source.
Ask questions that reveal missing requirements
Useful discovery questions connect the audience’s task with the information and conditions needed to explain it. Ask for examples and follow up where a term could mean different things to different people.
| Topic | Question to ask | What to clarify next |
|---|---|---|
| Audience | Who will watch, and what do they already understand? | Differences between viewers and the people commissioning the work |
| Problem | What happened the last time this explanation was needed? | The specific point of confusion |
| Use | Where will someone encounter the video? | Viewing conditions and surrounding context |
| Evidence | Which approved material supports the explanation? | Current revisions and unresolved claims |
| Approval | Who can resolve a disagreement about the content? | Authority and review availability |
| Delivery | What must the team receive and maintain? | Versions, accessibility needs, and update ownership |
Avoid treating a preference as evidence. A stakeholder’s request for a particular style may be useful, but it does not establish what viewers need. Ask which communication need the preference serves and record whether that relationship has been tested.
Give stakeholders specific decisions to make
Stakeholders should participate according to the decisions they can inform or approve. Inviting everyone to comment on everything can leave important disagreements unresolved.
The content owner can explain the message and intended use. A subject specialist can check factual details. Someone responsible for distribution can describe the viewing environment. The person approving the assignment needs a clear account of the scope and its assumptions.
Speak separately where people have different experiences or where a group setting may inhibit a useful answer. Bring the findings together afterward. A meeting with senior stakeholders does not replace listening to the people who actually encounter the explanation.
Identify who will consolidate feedback. When two reviewers ask for incompatible changes, the production team needs an agreed decision rather than two competing instructions. Record the reason for the choice so it can be understood later.
Reconcile requirements before expanding the scope
Reconcile requirements by checking each request against the agreed audience and task. Keep necessary information in the main assignment, and identify other useful requests as separate work.
Consider a fictional organization preparing an introduction to its internal maintenance-request process. Employees need to know where to submit a request and what information to include. A manager also wants the video to describe every maintenance priority, while another stakeholder wants detailed instructions for the software administrator.
These requests serve different audiences. The introductory video can explain the employee’s submission task, with links to the current policy where appropriate. Priority-setting rules and administrator training require separate decisions about content and review. This is a planning illustration, not a documented client project.
Do not settle the disagreement by adding every topic to the same script. Ask whether the additional information is necessary for the stated task. If it is necessary, revise the assignment and estimate its effect on production. If it serves another purpose, record that purpose separately.
Write a brief that can be checked
A usable brief states the assignment in terms a reviewer can accept, question, or correct. It identifies the evidence and decisions behind the proposed work.
For the fictional maintenance-request example, the audience is employees submitting a routine request. The intended outcome is that viewers can identify the submission route and the information required. Repair instructions and urgent-response procedures are outside this introductory explanation.
The source package would include the current employee procedure, approved interface examples, and the process owner’s corrections. Any screens used for illustration would need to avoid exposing actual employee information. The owner would also confirm how viewers should find instructions for situations outside the video’s scope.
The delivery request could include an introductory video with captions and a supporting still for an internal page. Runtime would follow a timed outline. The person responsible for the procedure would approve content, while the internal communications owner would confirm publication and future updates.
Open decisions should remain visible: whether interface recording is permitted, which language versions are needed, and how much context a new employee requires. A draft brief can be useful while these questions are unresolved, provided they are not presented as accepted assumptions.
Record assumptions and change decisions
An assumptions record identifies the conditions on which the scope depends. Update it when new information changes the assignment.
For example, the proposed approach may assume that an approved script exists or that one person can consolidate review. If either condition proves false, the work and schedule may need to change. Name the person responsible for confirming each assumption and the point at which a decision is needed.
Keep requested changes distinct from corrections. Correcting an inaccurate label is different from adding a new audience or an additional explanation. Describe what changed and which approved decision it affects before revising the scope.
Maintain a short decision log with the issue, decision, owner, and affected version. This helps a later reviewer understand why the brief excludes a topic or uses a particular source. It also keeps an old comment from returning as an apparently new requirement.
Check the brief before production starts
Check whether the brief gives the team a consistent answer about the audience, explanation, and required outputs. Resolve contradictions before detailed production begins.
- Ask the content owner to confirm the task and its boundaries.
- Check source revisions and assign unresolved factual questions.
- Confirm that reviewers understand their responsibilities and availability.
- Verify viewing conditions and accessibility requirements with the distribution owner.
- Review deliverables, assumptions, and changes with the person approving the assignment.
Where possible, ask someone resembling the intended viewer to describe what the outline would help them do. Use their questions to investigate missing context. That conversation is a check on the proposed explanation, not proof that the finished video will achieve a business result.
A brief is ready to guide production when its important decisions are explicit and its remaining uncertainties have owners. Listening continues during review, but the team has a shared record from which to make changes.
Frequently asked questions
What belongs in a video discovery brief?
Include the audience, communication task, intended use, approved sources, review responsibilities, deliverables, and assumptions. Identify open decisions rather than filling them with guesses. Supporting interview notes can remain separate from the brief itself.
Who should attend a discovery conversation?
Include people who understand the audience, subject, and planned use, along with someone who can approve the assignment. Separate conversations may help where participants have different responsibilities or cannot speak freely in a group.
How many interviews are needed?
The number depends on the questions and variation among the people involved. A single senior stakeholder may not represent every viewer. Record the limits of what was heard and investigate material disagreements before treating the findings as settled.
Should the brief choose a video style immediately?
Choose the style after identifying what must be explained and which source material is available. Early preferences can inform the discussion, but they should not conceal an unresolved audience question or a missing technical reference.
How should conflicting feedback be handled?
Ask the designated decision owner to resolve it against the agreed task and evidence. Record the choice and affected version. The production team should receive one approved instruction rather than independently choosing between contradictory requests.
Can the brief change during production?
The brief can change when new information or a revised requirement affects the assignment. Document the decision and its effect on scope, review, and delivery. Keep the approved version distinguishable from earlier drafts.
