A policy presentation should help people make the right choice when the policy meets a real situation. It is not a shorter copy of the document. Start with the action the audience must take, then show the rule, the exception and the person who owns the next step. If the source is a PDF, convert PDF to presentation only after you know which clauses the audience needs.
Set the audience action before you select slides
Write one sentence beginning with “After this session, participants can…”. A sales team may need to know when approval is required; a manager may need to route a request; a new hire may need to recognize a restricted case. These are different presentations even when they use the same policy.
Name the audience, the decision and the deadline on the opening slide. Put the policy owner and the source version in a small reference line. That gives the deck a boundary: it teaches an approved process rather than inventing a new one.
A running example: sharing a supplier briefing
Consider a fictional company, Harbour Studio, preparing a ten-minute briefing for project coordinators. Its invented External Briefing Rule v1.0 contains four clauses. They are teaching material, not a real company policy or a statement of law.
- Clause 1: Before sending an internal project brief to a supplier, the coordinator records the purpose, named recipient and exact file version.
- Clause 2: The project owner must approve that recipient and version in the request record before it is sent.
- Clause 3: If the brief includes client-identifying information, the coordinator pauses the request and asks the information owner for a sharing decision. Project-owner approval alone is insufficient.
- Clause 4: A changed recipient or changed file requires a new approval. A delivery deadline does not waive these steps.
The audience outcome is specific: “Given a supplier request, coordinators can identify the applicable route and the approval needed before sending a file.” The deck does not need to explain the entire information-security program. It needs to distinguish an ordinary approved handoff from a request that must pause.
Extract rules, exceptions, and definitions
Create a working table with four columns: rule, trigger, required action and evidence. Add an exception column only when it changes the decision. Avoid copying every paragraph. Quote the shortest clause that resolves the question, and link the slide back to the section or page in the source file.
Definitions deserve their own check. A term such as “confidential data”, “material change” or “approved supplier” can change how a scenario is handled. If a definition is still under review, label it as an open point instead of presenting it as settled policy.
Build the rule table before the slides
| Source rule | Trigger | Required action | Evidence in the request |
|---|---|---|---|
| Clauses 1–2: normal route | An internal brief is ready for a named supplier contact. | Record purpose, recipient and version; obtain project-owner approval before sending. | The approved recipient, exact file version and recorded approval. |
| Clause 3: restricted content | The file identifies a client. | Pause and ask the information owner for a sharing decision. | The decision and any conditions attached to it. |
| Clause 4: changed request | A different recipient or version is proposed. | Seek new approval; do not reuse the earlier decision. | A new request linked to the earlier one. |
Notice the distinction between “get approval” and “get approval for this recipient and this version.” Removing those last words makes the slide shorter but changes the rule. Keep decision-changing qualifiers visible. Explanations and less common examples can go in speaker notes.
The GOV.UK guidance on plain English is a useful writing reference. Plain language should clarify an approved rule, not silently relax a requirement or replace a defined term with a broader synonym.
Teach the policy with scenarios
Replace abstract warnings with two or three realistic situations. Show the facts, the decision point and the correct action. Include one near miss: a case that looks ordinary but activates an exception. Ask participants to choose before revealing the answer.
Keep scenarios bounded. Do not publish personal information or claim that a fictional example is a legal conclusion. Mark the facts as illustrative and ask the policy owner to review any scenario that could be interpreted as advice.
Two slides made from the same source
Slide 1 — “Before you send: match the file to the approval.” Use three steps: identify the recipient and version; check for client-identifying information; obtain the approval required for that route. Beneath them, write: “Changed recipient or version? Start a new approval.” The reference line is “Harbour Studio fictional rule v1.0, clauses 1–4.”
Slide 2 — “The supplier asks for one more file. Can you send it?” Give these facts: version 3 was approved for Alex at the supplier; Alex now asks for version 4, which adds a named client. Offer three choices: A, send because the supplier is already approved; B, ask only the project owner; C, pause, seek the information-owner decision and obtain the required approval for the changed version. Reveal C after the audience chooses. Clause 4 invalidates the old approval for this version; clause 3 adds the restricted-content route.
A normal case prevents the lesson from becoming “always escalate.” If version 3 contains no client identifiers and is sent to Alex exactly as approved, the coordinator may proceed under clauses 1–2. The skill is selecting a route from the facts, not guessing the most cautious answer every time.
Make ownership and escalation visible
A policy is useful only when someone can answer the next question. Add an owner for approval, an owner for interpretation and a channel for urgent escalation. A simple flow works well: request → check → approve or escalate → record.
Separate responsibility from consultation. The person who collects evidence may not be the person who can approve an exception. Showing that distinction prevents a training deck from promising authority that the policy does not grant.
Write the handoff as an action, not a department name
For the changed-file case, the request could read: “Supplier Alex needs briefing v4 for layout work. The earlier approval covers v3 only. The new file names a client. No file has been sent. Please decide whether v4 can be shared and record any conditions.” This is more useful than a box marked “Legal / Security,” which does not explain what question to resolve.
Here, the coordinator gathers details, the project owner approves the ordinary handoff, and the information owner decides the restricted-content question. Do not combine those roles into a single approval badge. In a real deck, use approved role names and the internal request route, and ensure that reviewers can access the supporting record.
Close with a check and a rollout plan
End with a short comprehension check: three situations, the expected route and one reason. Record where the answer key lives and how questions will be tracked. If the policy changes, the deck needs an owner and a review date.
A practical final slide lists the source version, the effective date, the policy owner and the next update trigger. That makes the presentation safer to reuse than an undated summary and gives the audience a clear route when the rule does not cover their case.
A handout that survives the presentation
The one-page companion needs the three-row rule table, a link to the current approved policy and the internal request route. Keep the full policy outside the slides so readers can examine clauses in context. The handout and deck should identify the same version; a deck is not the authoritative source simply because it is easier to read.
Use three final questions: “Same recipient and approved version, no restricted content?” Proceed through the normal route. “Same recipient, new version?” Obtain new approval. “A client name appears?” Pause for the information-owner decision. Ask participants to name the clause as well as the action. A correct answer for the wrong reason needs another explanation.
When preparing the visual draft in Presenti, keep the table as the source of truth and compare each generated slide against it. A polished summary is not enough if it omits the version condition. The finished deck should make the choice faster without changing who can authorize it.
