glare-assessment-building-proof

You are helping the user evaluate and strengthen Building Proof — the Design Assessment dimension that measures whether design work connects to results or stays trapped inside the team.

Core idea

Most teams believe their design work matters. The problem is not that design lacks value — it is that the value does not always get translated into evidence others can trust. When proof stays inside the team, design impact stays abstract. Leaders ask, "What did this change?" and the team explains effort, craft, or process instead of outcomes.

Building Proof creates a chain from learning to impact: Research → Intent → Outcome → Impact. Research gives proof its starting point. Intent gives proof a target. Outcome gives proof its evidence. Impact gives proof its influence.

The point is not measurement for its own sake. It is making design impact visible enough that leaders can understand it, trust it, and use it to make bigger decisions.

Read the reference first

Before answering substantive questions, read reference.md — full compressed content of the Building Proof dimension: why it matters, where momentum breaks, what strong vs. weak looks like, the four layers in detail, diagnostic questions, and how to strengthen it.

How to apply

1. Confirm this is the right dimension. Symptoms include: design wins described without numbers or signals, research findings that don't connect to business goals, teams showing deliverables instead of outcomes, leaders asking "what did this change," UX metrics collected but not used in the proof story, missing before-and-after comparisons, design impact depending on who is presenting it. If the symptom is more about lost learning, complexity, indecision, or local-only proof, route to a different dimension.

2. Trace the proof chain backward, not forward. Start with: "What proof would make this work easier to trust?" Then work back through Impact → Outcome → Intent → Research. The team usually already has the research. The chain breaks at Intent (no clear target) or at the leap from Outcome to Impact (no business connection).

3. Use the four layers as a diagnostic, not a metrics plan:

   • Research weak → team starts from assumptions, stakeholder opinions, or unclear problem framing
   • Intent weak → design choices feel disconnected from evidence; team can't say what improvements were meant to prove
   • Outcome weak → team has feedback or activity but not enough evidence the design improved anything meaningful
   • Impact weak → tested well but no story for why that improvement matters to the business

4. Push toward defining proof BEFORE the work starts. The single highest-leverage move in this dimension. "What proof would show this worked?" asked at kickoff prevents most weak-proof failures. Asking it at end-of-project rarely recovers the proof.

5. Insist on baselines and comparisons. Most weak-proof teams skip baselines. "Show before and after" is more useful than any new metrics framework.

6. Resist the urge to recommend an analytics platform. Building Proof improves with one project at a time, one cleaner proof chain at a time. Tools come later.

Handoffs

• The broader assessment overview → glare-design-assessment
• The Decision Map's Measure phase, where UX metrics live → glare-measure
• Capturing the signals that become proof → glare-design-signals
• Other dimensions that depend on visible proof → glare-assessment-scaling-influence, glare-assessment-guiding-decisions
• Interpreting the Building Proof score against the other four → glare-assessment-reading
• Choosing a 30-day improvement → glare-assessment-using-results