Decide what the walkthrough needs to accomplish
A walkthrough should help the client understand the finished deliverable well enough to review it and decide what happens next. It is not a tour of every file or a second project kickoff. Before scheduling it, revisit the brief, agreed scope, and review criteria. Identify the few outcomes you need to demonstrate: for a website, these might be a visitor completing a key task and the client updating a page; for a visual identity, they might be consistent use across several agreed formats.
Send a short agenda with the meeting link, an expected length, and any preview files or access instructions. State whether the session is for review, final approval, or handoff, since those calls lead to different decisions. Invite the people who can answer content questions and make approval decisions. If someone cannot attend, agree on how they will review the work afterward rather than assuming another attendee can approve it for them.
Prepare a reliable path through the work
Build the demonstration around two or three realistic scenarios instead of opening files at random. For a brand package, you might start with the primary logo, then show its use on a document and a social graphic before opening the usage guide. For an online course, you might follow a learner from the introduction through an exercise and its feedback. This gives the client a way to judge whether the parts work together.
Check the files, links, permissions, and presentation setup before the call. Open the exact version you intend to show and keep a backup copy or screenshots available in case a preview fails. Make a brief list of known limitations, agreed exclusions, and items awaiting client input. Separating these from defects helps prevent confusion when questions arise. If the deliverable includes editable files or a live system, be ready to show how the client will access them, but leave detailed training for a separate session if it would overwhelm the review.
Show the result before explaining the details
Begin by restating the goal in ordinary language: what was meant to be delivered, who will use it, and what the client is being asked to review today. Then show the finished experience from the user’s point of view. Let a page, asset, or workflow stand on its own briefly before explaining design choices. Refer to the brief when a decision needs context, such as why a navigation label was simplified or why a template offers only certain layout options.
Keep the pace deliberate and pause at natural checkpoints. Ask specific questions such as, “Does this approval step match how your team works?” rather than “What do you think?” Avoid defending every choice immediately; first make sure you understand the concern. If a participant raises an unrelated idea, acknowledge it and place it on a separate list so the walkthrough can continue. A client should leave knowing what was delivered, not merely remembering a long discussion of possible changes.
Capture feedback in a form you can act on
Record comments against the relevant page, file, screen, or section. For each requested change, clarify what problem it solves, who will confirm the answer, and whether it relates to the agreed scope. For example, “The download button is hard to find on mobile” is more useful than “Make this pop.” When a preference is unclear, offer to test or mock up a small alternative rather than interpreting it as an instruction to redesign the whole deliverable.
Do not force approval in the room if the client needs time to check details. Agree on one place for consolidated feedback and a reasonable review window suited to the project. If several stakeholders are involved, ask the client to resolve conflicting comments before sending a final list. Distinguish corrections, requested refinements, new work, and open questions in your notes. That distinction makes the next round easier to estimate, complete, and review without quietly expanding the project.
Close with decisions and a usable handoff
End by summarizing what the client accepted, what still needs review, and who owns each next step. After the meeting, send a concise recap with links to the reviewed version, the feedback list, any decisions made, and the planned route to approval. If changes are needed, say how the client will see and verify them. Keep version names clear so nobody reviews an outdated file.
Once the deliverable is approved, make the handoff practical. Provide the agreed final files or access, a short explanation of what each item is for, and any instructions needed for routine use. Note any remaining limitations or maintenance responsibilities without treating the walkthrough as a substitute for training or support. A good closing process gives both sides the same understanding of what is finished and makes the work easier to use after the call ends.
