Working with stakeholders

How to present progressive work effectively.

The challenge

When you design in the browser from day one, you’re working with something that looks real. This is both a strength and a potential problem.

Stakeholders seeing an early prototype might focus on the wrong things. They’ll notice the placeholder logo, the dummy text, the basic colors—instead of the layout, flow, and structure you’re actually presenting.

Different stakeholders need different things. Some are very comfortable going through a browser. Others want to see a screenshot, a PNG—something they can annotate or share easily.

The solution isn’t to abandon in-browser design. It’s to adapt your presentation strategy to match each stakeholder’s comfort level.

To top

Tech-savvy stakeholders

Some stakeholders are comfortable with technology. They understand that a prototype is unfinished. They can mentally separate structure from surface.

For these stakeholders:

  • Present in the browser. Share a URL. Let them click through, resize, test on their devices.
  • Walk through flows. Demonstrate the actual user experience, not static representations of it.
  • Show responsive behavior. Resize the window. Prove that layouts work across screen sizes.
  • Iterate in meetings. Make changes live while they watch. Show how fast refinement can happen.

The browser becomes a shared canvas. Changes are immediate. Feedback is concrete. There’s no translation layer between what they see and what will ship.

To top

Traditional stakeholders

Other stakeholders need a more curated experience. They’re used to receiving polished deliverables. A raw prototype might confuse or concern them.

For these stakeholders:

  • Take screenshots. Capture specific states at specific sizes.
  • Create presentation decks. Frame screens with context and annotations.
  • Add callouts. Draw attention to what you want them to notice.
  • Control the narrative. Curate what they see and when they see it.

This isn’t a step backward. You’re still designing in the browser. You’re just translating the output into a format they understand.

The hybrid approach

Many stakeholders start traditional and become more tech-savvy over time. Begin with screenshots. As trust builds, invite them into the browser. Let them experience the prototype directly. They often prefer it once they understand the benefits.

To top

Redacted wireframes

One of the most powerful techniques for early presentations is redacting the content. Live Wires includes a redaction mode that replaces text with abstract shapes.

Why redact?

  • Focus on structure. Stakeholders can’t get distracted by placeholder copy.
  • Show hierarchy. Typography and spacing relationships are visible without the words.
  • Avoid premature feedback. No one can wordsmith Lorem Ipsum.
  • Signal incompleteness. A redacted page clearly says “this is a wireframe.”

How to use it

Press R to toggle redaction mode, or click the Redact button in the design toolbar. This applies the Flow Block font to content areas, rendering text as abstract blocks while preserving size and rhythm.

Combine with other overlay tools:

  • B for baseline grid—show that everything aligns
  • C for columns—demonstrate the underlying structure
  • O for outlines—reveal layout primitive boundaries

To top

Stakeholder education

Part of working with stakeholders is helping them understand your process. When you design in HTML from the start, you need to explain why.

Key messages

“This is the real thing.”
Unlike a Figma mockup, this prototype works in real browsers. When you click, things happen. When you resize, it responds. This is the website, just at an early stage.
“Changes are instant.”
We can adjust spacing, swap colors, try different type treatments in seconds. There’s no handoff delay between “design” and “development.”
“Nothing gets thrown away.”
The code you’re looking at evolves into production. We’re not rebuilding from scratch after approval—we’re refining what already exists.
“Test on your device now.”
Share the URL. They can see exactly how it works on their phone, their tablet, their desktop. No simulation required.

Framing stages

Use clear language for each stage of refinement:

  1. Structure—“We’re defining how content is organized.”
  2. Skeleton—“We’re establishing proportions and rhythm.”
  3. Surface—“We’re applying color, typography, and polish.”

These terms help stakeholders understand where they are in the process and what kind of feedback is appropriate.

To top

Progressive reveal

Consider revealing complexity gradually. Don’t overwhelm stakeholders with everything at once.

First meeting: Structure

  • Present with redaction mode enabled
  • Focus on layout and flow
  • Discuss content hierarchy
  • Gather feedback on organization

Second meeting: Skeleton

  • Reveal actual content
  • Show baseline grid alignment
  • Discuss typography scale
  • Review responsive behavior

Third meeting: Surface

  • Apply color schemes
  • Refine component details
  • Polish interactions
  • Final adjustments

This mirrors the sculpture metaphor from the philosophy page—you’re revealing the form as you carve it, not presenting everything at once.

To top

Related