5 exercises on narrating a live demo, drawing attention to key elements, handling errors gracefully, and walking through code at the right altitude.
Key patterns for demos and code walkthroughs
"Let me walk you through..." — the canonical demo opener
"What you're seeing here is..." — orients the audience instantly
When something breaks: "Interesting — let me show you how the system handles it."
Code: give the big picture first, then zoom into the interesting parts
0 / 5 completed
1 / 5
You are about to start a live product demo for a group of stakeholders. Which opening phrase most naturally sets up what they are about to see?
"Let me walk you through..." is the canonical demo opener — it sets a clear route before you start moving.
Option B does three things:
Names the feature/flow: "the new onboarding flow" — tells the audience what they're watching
Sets the starting point: "I'll start from the landing page" — orients the viewer
Promises a journey and endpoint: "from sign-up to first action" — gives the demo a narrative arc, not just random clicking
Demo opening phrase bank:
"Let me walk you through..."
"What I'm going to show you is..."
"I'll take you through this step by step."
"Let me give you a quick tour of..."
"What you're about to see is [feature] — I'll narrate as I go."
Why option A fails: "I'll just start clicking around" signals no plan. In demos, uncertainty is contagious — if you seem unsure what you're about to show, the audience will be confused.
2 / 5
Midway through a screen-share demo, you navigate to a dashboard. The audience may not immediately understand what they're looking at. Which narration phrase best draws attention to the key element?
"What you're seeing here is..." is the most effective narration phrase for orienting an audience during a live demo.
Calls out the key metric: "the number in the top-right is our current p99 latency" — directs the eye to what matters
Explains the significance: "the metric we're optimising" — gives context, not just description
Narration phrase bank for demos:
"What you're seeing here is..."
"If I draw your attention to the [top-right / left panel / highlighted row]..."
"Let me zoom in on this for a moment."
"Don't worry about the [X] for now — focus on [Y]."
"This number here — [value] — is the one that matters."
Why option C ("all the important stuff") fails: Vague language ("all the important stuff") makes the audience do the work of deciding what to focus on. Your job as a presenter is to direct attention, not abdicate it.
3 / 5
During a live demo, something goes wrong — the API call fails and an error appears on screen. The audience can see it. Which response keeps the demo on track most professionally?
Reframe the error as a teaching moment — never panic, never over-apologise.
Option B is the professional response because:
"Interesting" as a pivot word: instead of "oh no," "interesting" signals that you're in control and curious, not flustered.
Describes what happened neutrally: "we've hit an error here" — factual, not panicked.
Reframes as a feature demonstration: "exactly the kind of thing our error handling catches" turns the failure into evidence that the system is resilient.
Keeps moving: "Let me show you the fallback behaviour" — pivots to demonstrating error recovery rather than dwelling on the failure.
Error-handling phrase bank for demos:
"Interesting — we've hit [X]. Let me show you how the system handles it."
"That's actually a useful thing to see — here's what happens next."
"Good timing — this lets me show you our fallback / retry / error message."
"Let me quickly fix that and we'll carry on."
Why "this always happens in demos" fails: It destroys confidence. Audience members think: "If it always fails in a demo, what happens in production?"
4 / 5
You are narrating a code walkthrough and want to explain what a specific function does without reading it line by line. Which approach is most effective?
Give the conceptual summary before diving into lines — audience needs the map before the territory.
Option B uses the zoom-out-then-zoom-in technique:
"Let me give you the big picture first" — explicitly tells the audience you're orienting them before the detail
A one-sentence function summary: "this function is the gatekeeper — it takes a request, validates the token..." — a mental model in under 20 words
"I'll point out the interesting parts" — signals you'll be selective, not exhaustive
Code walkthrough phrase bank:
"Let me give you the big picture first..."
"At a high level, this function [does X, Y, Z]."
"The key part to focus on is this section here..."
"This is the interesting bit — [explanation]."
"You can ignore the boilerplate at the top — let me jump to the logic."
"What I want to draw your attention to is..."
Why line-by-line narration fails: It forces the audience to build the mental model themselves, in real time, while also reading code. That's too much cognitive load simultaneously.
5 / 5
You are ending a live demo and want to hand back to the main discussion. Which closing phrase works best?
Close a demo the same way you close a talk: summarise what was shown, then bridge to the next action.
Option B has a clear three-part structure:
Signals the end: "So that's a quick look at the feature" — closes the demo chapter
Summarises: "to summarise what you saw: X, Y, Z" — reinforces the key messages while they're fresh
Offers a choice that moves forward: "Happy to drill into any part of that, or shall we move on to the decision?" — respects the audience's time while keeping momentum
Demo closing phrase bank:
"So that's the demo — to recap what you saw..."
"Let me stop there and check in — what questions does that raise?"
"That's the end of the walkthrough. The key things I wanted you to take away were [X] and [Y]."
"I'll hand back now — happy to go deeper on any of that."
Why option C ("I'll stop sharing my screen now") fails: It's a technical action, not a narrative close. The audience needs a verbal bridge from the demo back to the conversation, not just a screen disappearing.