English for Presenting Architecture Decisions During a Walkthrough

An architecture walkthrough is different from a written design document — you’re narrating a diagram live, answering questions on the spot, and adjusting your explanation based on what the room understands or doesn’t. This guide covers the English phrasing for doing that clearly, including how to explain trade-offs and handle pushback in real time.

Key Vocabulary

Narrating a diagram — describing the flow of a system out loud in a logical order (usually following the direction data or requests move), rather than jumping between boxes randomly. “I’ll narrate this left to right, following a request from the client through the gateway, into the service layer, and down to the database.”

Trade-off — a deliberate choice between two options where each has a cost, described in a walkthrough by naming both sides, not just defending the chosen option. “We traded consistency for availability here — in a network partition, this service keeps serving reads from a stale replica rather than returning an error.”

Zooming in / zooming out — moving between a high-level overview and a detailed explanation of a specific component, a common technique for managing audience attention during a walkthrough. “Let me zoom out for a second before I go deeper into the queue — at a high level, this whole subsystem exists to decouple order processing from payment processing.”

Deferred question — a question raised during the walkthrough that’s acknowledged but intentionally addressed later, to avoid derailing the current explanation. “That’s a great question about failure handling — I’m covering that in the next section, so let me hold it there and come back to you.”

Assumption (stated explicitly) — a constraint or expectation the design relies on, called out directly so the audience can challenge it if it’s wrong. “This design assumes write volume stays under 500 requests per second. If that assumption turns out to be wrong, the queue-based approach here would need to be reconsidered.”

Common Phrases

• “Let’s follow the request from left to right.”
• “I’ll zoom out here before going into detail on this component.”
• “We traded [X] for [Y] here, and here’s why that made sense for our constraints.”
• “Good question — I’ll cover that in a moment, let me hold it there.”
• “This design assumes [X]. If that’s wrong, we’d need to revisit this part.”

Example Sentences

Opening a walkthrough by orienting the audience before diving in: “Before I go through each box, here’s the one-sentence version: this system separates the fast, synchronous path a user waits on from the slow, asynchronous path that runs in the background. Keep that in mind as we go through the details.”

Explaining a trade-off honestly, including the downside: “We chose eventual consistency for the search index, which means a newly created item might not appear in search results for up to a few seconds. That’s a real trade-off — search will occasionally be stale — but it lets us keep the write path fast, which matters more for this use case.”

Handling a live pushback question without getting defensive: “That’s a fair challenge — you’re right that this adds a new point of failure. We accepted that because the alternative, doing this synchronously, would have added 200ms to every request. Happy to walk through the failure handling for this component specifically if that would help.”

Deferring a question smoothly without dismissing it: “That touches on retry behavior, which I’m covering two slides from now — let me park that for a second and come back to it, so I don’t get ahead of myself.”

Professional Tips

• Narrate diagrams in a consistent direction (usually following the request or data flow) — jumping around confuses an audience trying to build a mental model in real time.
• Always state trade-offs as both sides, not just the benefit of the choice you made — “we traded X for Y” is more credible than “this approach is better,” because it acknowledges a real cost.
• Use “let me zoom out” and “let me go deeper here” explicitly as verbal signposts — they help the audience track whether you’re giving an overview or a detailed explanation at any given moment.
• When deferring a question, name when you’ll address it (“I’ll cover that in a moment” / “let’s take that after the walkthrough”) rather than a vague “good question, later” — it reassures the person they’ll actually get an answer.
• When challenged live, acknowledge the valid part of the pushback before responding — “that’s a fair point” costs nothing and makes your explanation land better than an immediate defense.

Practice Exercise

1. Write a one-sentence orienting summary you’d give before diving into a hypothetical architecture diagram.
2. Write two sentences explaining a trade-off, naming both the benefit and the cost.
3. Write a sentence deferring a live question while naming exactly when you’ll return to it.