Present Web Designs Without Losing the Room or Scope

Run your first design review with a clear scope, a short user story and goal-based questions—then leave with decisions, actions and open issues recorded.

November 13, 2026 6 min read

Two people reviewing and discussing printed images laid out on a studio table.

You showed a client the new home page this week, and within minutes the conversation jumped from the hero to button colours, mobile behaviour and one director’s pet feature. The method is simple: frame the review before you show the interface, tell the design as a user story, test reactions against agreed objectives, and finish with a written record. This is published professional UX guidance, not proof that one meeting format will reduce revisions, protect margin or secure approval. Use it as a practical structure for the first design round, then judge it against what happens in your own client work.

1. Set the boundaries before the call

Your action: define the review’s scope, goal and agenda. State what you will discuss and what you will not discuss. Reserve the time, send the agenda and attach the designs early enough for individual review. NN/G recommends starting with material that can be covered in an hour and time-boxing the discussion so the whole agenda is addressed. For a first home-page round, send: “Goal: assess whether the proposed home page supports the agreed user journey and project objectives. In scope: hierarchy, content priorities and the main route to enquiry. Not in scope today: final copy edits, contract changes or additional page requests. We have 60 minutes; the design and agenda are attached.”

Expected output: everyone arrives knowing the purpose, the material and the boundaries of the conversation. Approval dates, revision allowances and out-of-scope requests belong in a separate commercial discussion if they arise.

2. Open with the user, not the interface

Your action: before sharing screens, establish the relevant user or persona, the scenario, the problem and the agreed objective. NN/G’s presentation guidance says to provide the background needed to understand a proposed interface and use visuals to tell the full UX story.

Try: “Before we look at the design, let’s return to the customer we agreed to prioritise. They arrive on this shop unsure which product fits their job. Today we’re reviewing whether the proposed path helps them understand the choice and move toward purchase.”

Expected output: a shared user and objective against which participants can evaluate the proposal.

3. Tell the design’s story

Your action: keep the walkthrough concise. Explain the problem, relevant inspiration, major decision points and meaningful trade-offs. Do not narrate every screen or every pixel. NN/G’s critique sheet explicitly recommends telling the work’s story to bring the audience into the problems, inspirations and decisions encountered.

NN/G illustrates the distinction with Alice. In one version, a team walks executives through screens, features and capabilities. In the alternative, it introduces Alice, what motivates her and a stressful travel scenario before revealing how the design responds. Treat this as an illustrative contrast—not a client case study or evidence of measured results.

On a shop redesign, you might say: “We considered putting every category above the fold. That improves immediate exposure, but it competes with the customer’s need to understand the range. We prioritised the guided entry point because the agreed objective is to help uncertain buyers choose a route.”

Expected output: the client understands why the important choices exist and where genuine decisions remain. You do not need to prescribe a universal order for responsive behaviour, visual systems or detailed polish; cover only what matters to this review’s scope.

4. Use principles to explain trade-offs

Product-specific design principles are value statements describing the most important goals a product or service should deliver for users. They frame design decisions; they are not general usability rules or instructions for individual interface elements.

Useful principles take a clear position, explain why the value matters to users, stay concise and memorable, and avoid conflict. If two values matter in different contexts, specify which takes priority in each context. NN/G also advises keeping the set limited: with 10 or more, many may be forgotten.

NN/G’s own example is “Clarity Over Popularity”: it prioritises clear, concrete guidance over trendsetting or unnecessary jargon. The broader pattern is what matters in your meeting: name the preferred value and the value it beats when the two compete.

Try: “This choice follows our project principle of clarity over popularity. Both matter, but for this customer and task, clarity tips the balance.” Or ask: “We have two valid goals here. Which one does our prioritised principle tell us to protect?” Use clear, non-conflicting principles to explain the choice.

Expected output: an explicit reason for the trade-off that the room can challenge against shared values, rather than against your personal authority.

5. Turn reactions into useful questions

Your action: ask why when feedback is reactive, and connect every useful comment to a persona, scenario, use case, goal or objective. Keep criticism directed at the work, not the designer.

Use these lines in the room: “Which persona or goal could this create a problem for?” “What specifically feels out of step with the objective?” “When you say there is too much blue, what user response or task are you concerned about?” “In which scenario would that choice fail?” “Let’s keep this round on hierarchy and the main journey; I’ll capture detailed copy changes separately.” “That needs its own discussion, so I’m parking it rather than rushing it here.”

Avoid “Why did you think that was a good idea?” NN/G contrasts that personal challenge with feedback aimed at the artefact, such as explaining why an element seems weak. A client saying “I love it” is pleasant; it still needs a job to do.

Expected output: feedback that identifies a user, context and intended result. You may still disagree, but at least you are now disagreeing about the work.

6. Moderate the clock and the edges

Your action: display or announce the time box, move each agenda item on when its slot ends, and circle back separately when an issue needs more discussion. NN/G recommends keeping time so the agenda is covered in full and arranging follow-up conversations for outstanding feedback.

Say: “We have eight minutes left on the home-page hierarchy. I want one decision and any open question before we move on.” Then: “That revision-limit question matters, but it sits outside today’s design critique. I’ve parked it for a separate conversation.”

Expected output: the stated agenda is completed, while deferred matters remain visible rather than hijacking the round or disappearing into the void where ‘quick questions’ breed.

7. Close with a shared record

Close with: “We agreed to keep the guided product entry, revise the heading against the stated objective, and defer the navigation request. Alex owns the heading revision. The unanswered question is whether returning buyers need a faster route, and we’ll open the next critique with it.”

Expected output: one shared account of what was decided, what happens next, who owns each action and what remains unresolved. A review is not complete merely because everyone has stopped talking.

Frequently asked questions

What should I send before a first design critique?

Send the goal, scope, exclusions, agenda, time box and designs in advance so participants can review the work individually.

How do I answer “I don’t like it”?

Ask which persona, scenario, use case, goal or agreed objective the design fails, then request the specific mismatch.