A complex topic becomes a clear presentation when the audience can follow one useful line of reasoning through it. You don’t have to remove every difficult detail. You need to decide what listeners are trying to understand, which ideas depend on other ideas, and what evidence they need before accepting your conclusion.
The hardest part is often choosing what to leave outside the talk. If you know the subject well, every qualification can seem essential and every branch can lead to another interesting explanation. The audience, however, needs a route through that knowledge before it can appreciate the branches.
Turn the subject into a question the audience recognizes
“Our approval process” names a subject but doesn’t tell you what the presentation must accomplish. “Why do requests take two days when the actual review takes twenty minutes?” gives the talk a problem to explain. That question helps you choose relevant evidence and decide where the explanation should end.
Use a question that belongs to the audience’s situation. A technical team may need to understand the mechanism behind a failure, while a manager may need enough evidence to choose a next step. The same underlying work can support different presentations because the listeners have different tasks.
Write a one-sentence answer before creating slides. Your first version can be provisional, but it should state something specific. For the approval example, the answer might be that requests spend most of their time waiting between reviewers rather than being actively examined.
Separate essential knowledge from useful background
List what someone must understand to follow your answer. Then distinguish those prerequisites from facts that are merely related. This is where a presentation stops being a tour of everything you know and becomes an explanation designed for a particular audience.
For the approval example, listeners need to distinguish active review time from elapsed time. They may need to know the sequence of handovers and how requests enter each queue. They probably don’t need the history of every form field or a description of every team that has ever used the process.
Keep additional material somewhere accessible for questions. Moving detail into an appendix or supporting document doesn’t make it unimportant. It gives the main explanation enough room to be understood while preserving the information for people who need it.
Build the explanation around dependencies
Ask which idea must come first for the next idea to make sense. A listener cannot evaluate a proposed change to a queue until they understand where waiting occurs. They cannot interpret a comparison until they know what was measured and whether the two cases are comparable.
A useful order for this example is to define the two kinds of time, follow one request through the process, show whether the pattern appears more widely, and then consider a change. Each section answers a question raised by the previous one.
Chronological order is useful when explaining an event or a procedure, but it isn’t automatically the best order for explaining an argument. You may have spent weeks collecting information in a sequence that would be confusing to a listener. Present the reasoning in the order the audience needs, not in the order you did the work.
Use one example as a reference point
A concrete example gives listeners somewhere to attach an abstract distinction. Imagine a hypothetical request submitted on Tuesday morning, reviewed briefly that afternoon, and approved on Thursday morning. The elapsed time is much longer than the time spent actively reviewing it.
Label this as an illustration unless it comes from an actual record. Then use the example to explain the parts of the process: arrival, waiting, review, handover, and final decision. Keep the same request in view as you introduce each part.
Changing examples too often can create extra work. Listeners must understand each new situation before connecting it to the concept. A well-chosen example can support several stages of the explanation, provided you don’t treat one case as proof of a general pattern.
Once the mechanism is clear, show what broader evidence supports it. Explain the sample, the period covered, and any important missing information. A useful illustration and a representative measurement have different jobs.
Give unfamiliar terms a reason to appear
A glossary slide at the start can leave the audience holding several definitions before knowing why they matter. Introduce a term when it helps explain something the listener is already considering. Define it plainly, then use it consistently.
You might first describe “the total time between submission and approval” and then introduce the term “lead time” if your field uses it that way. Check the definition used in your organization because familiar terms can carry different meanings in different settings.
Don’t alternate between several labels for the same concept merely to vary the wording. In a technical explanation, consistency can be more helpful than verbal variety. Natural speech still needs stable names for the ideas the audience is learning.
Make each slide support a message
The assertion-evidence approach associated with Penn State’s Leonhard Center recommends building technical presentations around succinct messages supported by visual evidence. This is a useful planning discipline even when some parts of your talk don’t need slides.
A slide titled “Process data” leaves the audience to work out the point. “Most elapsed time occurs between review stages” tells them what to examine, provided the evidence supports that claim. A timeline or appropriately designed chart can then show the relevant relationship.
Use a diagram when the audience needs to understand sequence or structure. Use a chart when a numerical relationship matters. Use a brief example when the idea is easier to grasp through a concrete situation. You don’t need to force every point into the same visual format.
Put the information needed to interpret the evidence on the slide, including units, labels, and relevant limitations. Keep secondary explanation in your notes or supporting material. A visually clean slide should still allow the audience to evaluate what it shows.
Explain the interpretation after showing the evidence
Don’t assume that a clear chart produces one obvious conclusion. Listeners may notice a different pattern, focus on an unusual case, or misunderstand the comparison. Tell them what the evidence supports and how it connects to the question you are answering.
In the approval example, showing long gaps between review stages doesn’t by itself establish why the gaps occur. Requests might be missing information, reviewers might work in batches, or the timestamps might reflect how the system records activity. Separate the observed pattern from your explanation of its cause.
State uncertainty at the point where it matters. “The records show where requests wait; interviews suggest batching is one reason” is clearer than presenting the suggested cause as a measured fact. You can still make a recommendation while being precise about what is known.
Use transitions to make the reasoning audible
Headings help you organize slides, but listeners also need to hear how the sections connect. A transition can summarize the question just answered and identify the next one. “We can now see where time is lost. The next step is to test which change would reduce that waiting” gives the audience a reason to follow you into the next section.
After a dense explanation, use a short recap before adding another layer. Return to the central distinction rather than repeating every detail. This gives someone who briefly lost track a way back into the argument.
For a fuller planning method, see how to structure a presentation from opening to closing. Clear transitions work best when the underlying sequence already makes sense.
Show what the audience can do with the explanation
A complex presentation should lead to a useful result: a decision, a better question, a prediction, or a practical next step. Make that result specific enough that listeners can tell whether they understand it.
For the approval process, the next step might be a small pilot that changes one handover while tracking both review quality and elapsed time. Explain why that test addresses the suspected cause and what result would make you reconsider the approach.
If the evidence isn’t strong enough for a decision, say what additional information is needed. A presentation can be successful when it prevents a premature conclusion. Clarity is about making the current state of the problem understandable, including its unresolved parts.
Rehearse with someone who doesn’t share all your knowledge
Ask a colleague or learner to summarize the main point after hearing the talk. Then ask what evidence they remember and where they became uncertain. These questions reveal more than asking whether the presentation was “clear.”
Listen for missing links in their explanation. If they can repeat the recommendation but cannot explain why it follows, you may need a better transition or a more concrete example. If they remember the example but draw the wrong general rule, the boundary needs more attention.
Our guide to explaining a difficult idea without oversimplifying it looks more closely at preserving those conditions. Use the feedback to revise the explanation before adding more slides.
Finally, rehearse within the actual time limit. Leave room for the audience to inspect important evidence and for you to finish without rushing. The clearest version is usually the one in which every included detail has an identifiable purpose and every major conclusion has a visible path behind it.
Source and further reading
Assertion-Evidence: Creating a Presentation — guidance from the Penn State Leonhard Center on building technical talks around messages and visual evidence. The approval-process scenario in this article is hypothetical.