An arrow, highlight or checklist can direct attention in a screen-based lesson. It can also look like part of the system being demonstrated. Before adding teaching graphics, decide how viewers will recognise which elements belong to the real interface and which have been added to explain the task.
Start with the purpose of each annotation. It may identify a field, explain a relationship or indicate an area to inspect. If the graphic supplies information that the actual system does not provide, make that difference explicit. A production overlay should not accidentally teach learners to wait for a prompt that will never appear in their working environment.
Give explanation a recognisable visual treatment
Use a consistent treatment for added teaching notes that differs clearly from the system's own controls. Avoid drawing an explanatory box that resembles a clickable button unless it is genuinely representing one. The design should help the viewer interpret the information, not mimic the interface so convincingly that the two become indistinguishable.
Ask the system owner to identify native warnings, status indicators and confirmation messages in the approved example. The production team should not invent an extra success badge because the real result looks visually understated. If the outcome needs explanation, describe the actual state rather than creating a fictional system response.
In a hypothetical resource-booking lesson, the editor proposes a large green tick after a request is submitted. The system owner explains that submission does not confirm allocation. The tick is replaced with a clearly styled teaching note identifying the submitted status and its meaning. The film then shows the real sample status without implying a stronger system decision.
Keep annotations from hiding the evidence
Place a highlight so the relevant label and surrounding context remain readable. An opaque callout can cover the detail the presenter is asking viewers to inspect. Check the annotation at the intended viewing size and during the actual moment it appears, rather than approving a large still image alone.
Do not let the graphic linger after the underlying state changes. An arrow pointing to a former position can become misleading when a window moves or a new screen appears. Match its timing to the approved action and remove it when its reference is no longer valid.
Review the unannotated and annotated versions together
Ask the subject owner what the plain screen shows, then what the added treatment implies. Any difference in meaning should be deliberate and approved. This comparison can reveal a graphic that makes an optional field look mandatory or a sample value look like a required entry.
Have an unfamiliar reviewer identify which elements they would expect to see when performing the actual task. If they name a teaching overlay as a system feature, change the treatment or explain it more clearly. This is a communication check, not a software validation exercise.
Annotations are useful when they make real information easier to interpret. Keep them visibly in that teaching role so the finished lesson does not turn explanatory design into an invented feature of the workplace system.
Discuss the production brief
Review Live Images services and ask about suitability for the filmed elements you need. Agree who owns the subject matter and any specialist review before booking.
Editorial basis
Original production-planning guidance with hypothetical examples. This article does not establish employment, safety, legal or assessment requirements. Search intent is an editorial hypothesis, not measured demand. AI-assisted unpublished draft.