Surface Techniques

Surface techniques help teams get clear on what is actually wrong before reacting to the work. Most design reviews move too quickly into feedback. People start sharing opinions, but they are not always responding to the same problem.

This step creates a shared starting point. Before the team reacts to the design, they need to understand the challenge behind it.

Why this matters

When the problem is unclear, the review gets noisy. That usually shows up when:

  • Feedback becomes scattered

  • People react to details instead of what matters

  • The same questions come up later

  • Decisions feel weak or get revisited

When the challenge is clear, the rest of the conversation becomes easier. Feedback gets sharper. Decisions form faster. The team has something real to respond to.

Most requests are just a starting point. The goal is to move from a general ask to something more specific:

  • What is breaking down

  • Where users struggle

  • Why this matters now

  • What happens if nothing changes

You are not solving anything yet. You are making sure everyone is looking at the same problem.

When to use these techniques

Use Surface techniques when the review starts reacting too quickly. That usually happens when:

  • People jump straight into opinions

  • Feedback spreads in different directions

  • The goal of the work is unclear

  • No one has named what is actually breaking

  • The room is discussing the design before agreeing on the problem

The goal is to slow the conversation just enough to make the problem visible. Surface is working when the group can name the problem in plain language. By the end of this step, the team should be able to say:

  • What is not working

  • Who it affects

  • Why it matters now

  • What consequence the team is trying to avoid

This gives the rest of the review a shared starting point. Use the technique that matches what is happening in the room.

  • If the room lacks background, set context before feedback begins.

  • If people are reacting to the design, reframe the request into the problem.

  • If the issue feels vague, ask what is not working today.

  • If urgency is low, make the consequence visible.


**

Techniques**

1. Set context before feedback begins

When people see work for the first time in a meeting, they react to what’s in front of them instead of what it’s trying to solve. They don’t know the background, what decisions were already made, or where uncertainty still exists. Because of that, feedback often stays shallow or unfocused.

Setting context gives the room a shared starting point. It helps people understand what they’re looking at and why it exists.

What to watch for

  • Confusion or basic questions late in the discussion

  • Feedback focused on small details

  • Slow or hesitant start to the conversation

What this does

  • Creates shared understanding

  • Improves the quality of feedback

  • Helps the conversation start at the right level

**Example
**“Here’s what we explored, why we made these choices, and where we’re still unsure.”

2. Reframe the request into the problem

If a conversation starts with the design itself, people interpret it in different ways. Feedback spreads in multiple directions because there is no shared understanding of what the work is solving.

Reframing brings the group back to the problem. It makes clear what the work is trying to fix and why it matters.

What to watch for

  • Feedback pulling in different directions

  • People reacting based on preference

  • Lack of clarity on the goal

What this does

  • Aligns the room

  • Focuses feedback

  • Reduces noise

**Example
**“Before we react to this, we’re trying to reduce drop-off at this step.”

3. Ask what is not working today

Teams often avoid naming what is actually broken. The conversation stays polite, but it also stays shallow. Asking directly about what is not working brings real issues into the discussion. It reveals where users struggle or where expectations are not being met.

What to watch for

  • Vague statements about improvement

  • No clear problem being described

  • Low urgency in the room

What this does

  • Surfaces real friction

  • Creates urgency

  • Grounds the conversation

**Example
**“Where is this breaking down right now?”

4. Make the consequence visible

A problem without consequence rarely creates urgency. Without urgency, feedback feels optional and decisions take longer. Making the consequence visible helps the group understand why the issue matters. It connects the problem to real impact.

What to watch for

  • Low energy or passive agreement

  • Slow decision-making

  • Unclear importance of the issue

What this does

  • Raises the stakes

  • Focuses attention

  • Encourages action

**Example
**“If this doesn’t improve, what happens?”


Start with the problem, not the work.

When the challenge is clear, feedback improves, decisions form faster, and the conversation moves forward with more confidence.

Related links

Chris McCumskey

Explains how to define a clear, measurable problem before doing root cause analysis. Useful when a team jumps to solutions before they really understand the issue.

Marija Dimović

Shows how design implementation reviews keep designers, developers, and testers in sync so designs ship as intended. Useful when handoff goes wrong and the final build doesn't match the design.

Natasha Mortimer

Storytelling shapes experience design by tapping memory, emotion, and shared understanding so brands connect with people in lasting ways. Useful when teams need to make a product or brand feel meaningful instead of just functional.

Identify where decision quality breaks down

The Glare Design Assessment helps teams spot weak validation, stakeholder friction, alignment gaps, and assumptions that scale without measurable learning—so you have a clearer starting point for improvement.

About 5 minutes · Team-based · Diagnostic snapshot you can act on

Take the Design Assessment