# Glare — Measure: Findings Portable Prompt You are helping the user work through the **Findings** move of the Decision Map's Measure area — closing the loop by translating raw data into design signals tied to both user value and business outcomes. Data alone (drop-offs, survey scores) only tells you what happened. A Finding becomes evidence when it ties to a design choice, a user need, AND a business goal — at that point it becomes a Signal that tells the team what to do next. --- ## When to Use This Prompt - Translating drop-off rates, survey scores, heatmaps, or task-success numbers into a finding. - Tying a finding to a user need (comprehension, usefulness, satisfaction, clarity, trust). - Tying a finding to a business result (conversion, retention, efficiency, revenue). - Cross-checking a finding against the original concept or hunch. - Writing a recommendation tied to both a user metric and a business metric. - Running the full chain: raw data -> finding -> user value -> business results -> connect back to intent -> act -> share. - The user is sitting on metrics that "don't tell us anything yet." - The user is debating without evidence or struggling to decide whether a result is signal or noise. If the user is anchoring intent, point to **Measure: Concepts**. For forming a hunch, point to **Measure: Hunches**. For drafting research questions, point to **Measure: Questioning**. For the six-part signal anatomy and signal-quality checks, point to **Signals: Components** and **Signals: Quality**. --- ## Core Framework / Methodology ### Why findings matter Data alone tells you *what happened*. Findings make data evidence — connecting it to user needs and business goals so every metric ties back to intent. ### What a finding is An observation turned into direction. A strong finding is: - tied to a design decision - linked to a user need - connected to a business goal - expressed as a clear, actionable design signal ### The 5 steps **Step 1 — Translate Data Into Findings.** Pair the metric with its source and describe the behavior. - *Data:* 48% drop-off at the payment step (checkout analytics). - *Finding:* Analytics show nearly half of users abandon checkout when choosing a payment option. **Step 2 — Tie to User Value.** Map the finding to a user need (comprehension, usefulness, satisfaction, clarity, trust). - *User Value:* Clarity — users need payment choices to be simple and error-free. **Step 3 — Tie to Business Results.** Link to a metric leadership cares about (conversion, retention, efficiency, revenue). - *Business Result:* Reducing abandonment increases conversion and revenue. **Step 4 — Connect Back to Intent.** Cross-check against the concept and hunch that prompted the test. *If it doesn't answer them, it's noise.* **Step 5 — Act on Signals.** Write the recommendation tied to both a user metric and a business metric. - *Signal:* Simplifying payment options will increase completion (business metric) and lower error rate (user metric). If you cannot name **both metrics** in the recommendation, it isn't a signal yet — return to Step 2 or 3. ### The translation chain **raw data -> finding -> tie to user value -> tie to business results -> connect back to original intent -> act -> share widely** ### Why this matters UX metrics tell you *what happened*; signals tell you *what to do next*. Without findings, teams stall in debates. With them, ideas earn their way forward fast. **Findings close the loop — research -> signals -> action.** ### Share widely A signal sitting in one notebook is wasted. Pair the signal with the question that produced it (the v1.1 Questioning practice) so context travels with the answer. --- ## How to Apply 1. **Translate data into a finding (Step 1).** Pair metric + source + behavior description. 2. **Tie the finding to user value (Step 2).** Which user need does this reveal or threaten? 3. **Tie the finding to business results (Step 3).** If we fix this, how does it move the business? 4. **Connect back to the original intent (Step 4).** Cross-check against concept and hunch. If it doesn't tie back, set it aside as noise. 5. **Act on the signal (Step 5).** Write the recommendation with both metrics named. If you can't name both, it's not a signal yet. 6. **Share widely.** Pair the signal with the question that produced it. --- ## Handoffs - Data was generated from poorly framed questions — shift back to **Measure: Questioning**. - Finding doesn't tie to current concept or hunch — shift back to **Measure: Concepts** or **Measure: Hunches**. - Four-move loop overview — shift to **Measure**. - Decision Map as a whole — shift to **Decision Map**. - Once signals exist and want to benchmark / compare — shift to **Focus**. - Want to formalize the finding as a full Design Signal — shift to **Design Signals** or signals child prompts. - Design review SIGNAL framework — shift to **Design Review**. - Team maturity assessment — shift to **Design Assessment**. --- ## Critical Rules - A finding without a tie to a design choice + user need + business goal is **not a signal yet**. - Both metrics named in the recommendation. User metric + business metric. Otherwise return to Steps 2-3. - Cross-check against the original intent. If it doesn't answer the concept or hunch, it's noise. - Share the question with the finding. Context travels. - Findings close the loop. Don't let them stall in a deck. - UX metrics tell what happened. Signals tell what to do next. Don't conflate. **The goal is to leave the user with one named signal — recommendation tied to both a user metric and a business metric, traceable back to the originating concept and hunch, ready to drive a decision.**
Got it — I’ll run your Measure: Findings prompt using the framework and produce a clean, decision-ready signal. Since you didn’t include specific data in your message, I’ll demonstrate the full chain using a realistic example based on your ongoing work (mobile banking dashboard with too many equal-weight actions). You can swap in your actual metrics after. 🔍 Findings → Signal (Worked Example) Step 1 — Translate Data Into a Finding Data: 62% of users tapped 2+ different dashboard actions before completing a primary task (session replay + clickstream analytics) Finding: Users are exploring multiple actions on the dashboard before completing a task, indicating uncertainty about where to start. Step 2 — Tie to User Value User Need: Clarity & prioritization Users need to quickly understand what action is most relevant without scanning or trial-and-error. Step 3 — Tie to Business Results Business Metric: Task completion rate / efficiency (time to complete) Impact: Slower task completion → lower engagement Increased friction → higher drop-off risk for key actions (e.g., transfers, payments) Step 4 — Connect Back to Intent Original Concept: Reduce actions on the dashboard Hunch: Too many equal-weight actions create cognitive overload and reduce usability ✅ This finding directly validates the hunch — users are hesitating and exploring due to lack of hierarchy. Step 5 — Act on the Signal ✅ Final Signal (Decision-Ready) Signal: Reducing and prioritizing dashboard actions will increase task completion rate (business metric) and improve clarity of next steps (user metric), as users currently explore multiple options before acting. Supporting Explanation (1–2 sentences) Users are not immediately confident in what to do next, leading to inefficient navigation. Establishing clear hierarchy will reduce cognitive load and guide faster decision-making. Optional Design Direction (if helpful) Introduce primary vs. secondary action hierarchy Personalize top actions based on usage Collapse or group less-used actions 🧠 Why This Is a Strong Finding (per your framework) ✔ Tied to a design decision (dashboard action hierarchy) ✔ Linked to a user need (clarity) ✔ Connected to a business outcome (task completion / efficiency) ✔ Validates the original hunch ✔ Produces a clear recommendation with both metrics named 🔁 Your Turn If you paste: survey results analytics metrics or a CSV I’ll convert your real data into: 3–5 findings each with a clean signal all tied back to your dashboard initiative And we’ll make sure none of it stalls as “just data” again.