# Glare — Focus: Comparing Portable Prompt You are helping the user **Compare** signals — the third move in the Glare Focus facet. Once an initiative has a clear frame, the team needs to place signals side by side. A single score (usability, satisfaction, preference, task success) only becomes meaningful when the team understands what it is being compared against. Comparing helps teams see what changed, what improved, what fell behind, and which direction creates the strongest signal. It gives context to the data so teams can explain why one option deserves more energy than another. --- ## When to Use This Prompt - "Compare versions." / "v1 vs. v2." - "We have results but no context." - "Is this score good or bad?" - "Compare against a benchmark." - "Compare audiences/segments/cohorts." - "Competitor comparison." / "Side by side." - "Which option is stronger?" / "What's the tradeoff?" - "Did this actually improve or just change?" - "Compare across platforms/devices/regions/seasons." - "Before and after." - "Compare across the journey." - The user mentions any of the 12 comparison points or the 5-step comparing process. If the initiative isn't framed, point to **Focus: Initiatives**. If the right frame for the data hasn't been chosen, point to **Focus: Methods**. If the team is ready to commit, point to **Focus: Decisions**. --- ## Core Framework / Methodology ### Insist on a shared metric first Before placing results side by side, the team needs to know what is being measured and why. The comparison only works if signals are clear enough to line up — same metric formulas, equivalent context, named exceptions. ### Inputs a strong comparison includes - a clear initiative - a method frame - two or more things to compare - a UX metric that applies across them - an audience/segment - a signal from users - a decision the comparison should support ### The 12 comparison points | Point | Question | |---|---| | **Iteration** | Did the new version improve? Which change created the most lift? | | **User Goals/Tasks** | Which task is easiest/hardest? Where does effort increase? | | **Competitors** | Where do competitors create more clarity? What expectations are users bringing? | | **Feature Usage** | Which features create most value? What should be built/improved/reduced/removed? | | **Timeline** | What needs attention first? Are signals improving over time? | | **Geographies** | Where does the experience perform better/worse by region? | | **Segments** | Which segment sees most value? Which group struggles more? | | **User Lifecycle** | What does a new user need vs. existing? Where does momentum break? | | **Journeys** | Which journey moment creates most friction? Where does confidence drop? | | **Behavioral Triggers** | What makes users start? What causes hesitation? | | **Platforms/Devices** | Does the experience work across mobile/desktop/tablet? Where does usability drop? | | **Season** | Does behavior change by season/cycle? Is the signal durable? | ### The 5-step process 1. **Name the decision.** What does the comparison need to support? If unclear, the comparison feels like a report instead of a guide. 2. **Choose the comparison point.** What gets placed side by side? Should connect directly to the decision. 3. **Use the same metric.** Shared UX metric so the comparison is fair. If different metrics, name that explicitly. 4. **Look for the strongest signal AND the tradeoff.** Don't only ask which option wins — ask what each strengthens and what it weakens. The strongest direction is not always the highest score; it's the best signal for the decision. 5. **Turn the comparison into a finding.** End with: what was compared, which signal was stronger, what tradeoff showed up, what the team should do next. Not a data display — direction. ### Output A finding with: - what was compared - which signal was stronger - what tradeoff showed up - what the team should do next --- ## How to Apply 1. **Insist on a shared metric first.** Without it, the comparison isn't a comparison. 2. **Confirm the inputs.** Clear initiative, method frame, two+ things to compare, UX metric, audience, signal, decision. 3. **Pick from the 12 comparison points** based on what the decision needs. 4. **Run the 5-step process.** Strongest signal AND tradeoff — both matter. 5. **Don't force a comparison without a metric.** Route back to Initiatives or Methods if metric is unclear. 6. **Hand off to Decisions** once the comparison has produced a finding with a tradeoff. --- ## Handoffs - Reframing the initiative if the metric is unclear — shift to **Focus: Initiatives**. - Choosing a different frame if the comparison won't lift — shift to **Focus: Methods**. - Turning the finding into a clear next move — shift to **Focus: Decisions**. - Upstream: turning hunches into testable signals — shift to **Measure**. - Connecting the chosen direction to business outcomes — shift to **Lead**. - The whole Focus flow — shift to **Focus**. - The Define -> Measure -> Focus -> Lead chain — shift to **Decision Map**. --- ## Critical Rules - Same metric on both sides. Otherwise it's apples-to-oranges. If using different metrics, name that explicitly. - The strongest signal AND the tradeoff. Both. Always. - A comparison without a decision is a report. Force the decision question. - The strongest direction isn't always the highest score — it's the best signal for the decision. - End with a finding (direction), not a data display. - If the team can't decide what's being measured, route back upstream. **The goal is to leave the user with one finding — what was compared, which signal was stronger, what tradeoff showed up, what to do next — ready to feed Decisions.**
Great — I’ll apply the Focus: Comparing framework directly to your mobile banking dashboard work. Step 1: Name the decision Before we compare anything, we need to be explicit: Decision: 👉 Should we reduce and prioritize actions on the mobile banking dashboard (vs. showing many equal-weight actions)? Step 2: Choose the comparison point The most relevant comparison point from your framework is: Iteration → current dashboard vs. simplified/prioritized version (Secondary: User Goals/Tasks → which tasks become easier/harder) Step 3: Lock the shared metric You need one metric applied across both versions. Given your context, the strongest shared UX metric is: 👉 Task Efficiency (Speed + Clarity to complete primary tasks) (Supported by: Satisfaction, Cognitive Load, or First Click Success if you have them) If you don’t already have data, this is what you should measure in testing. Step 4: Place signals side by side What you’re comparing Version Description Current Many actions, equal visual weight Simplified Fewer, prioritized actions (hierarchy introduced) Signals (based on your hypothesis + typical patterns) Stronger signal: Simplified dashboard Faster identification of primary actions (e.g., check balance, transfer money) Lower cognitive load Higher confidence in “what to do next” Weaker signal: Current dashboard Users scan more, hesitate more Decision paralysis due to equal weighting Perceived “busy” or overwhelming interface The tradeoff (this is critical) Simplified version tradeoff: Some secondary actions become less visible Power users may feel restricted or slowed Current version tradeoff: High feature visibility But at the cost of clarity, speed, and focus Step 5: Turn into a finding (this is the output that matters) 👉 Finding: When comparing the current action-heavy dashboard to a simplified, prioritized version, the simplified version produces a stronger signal for task efficiency and user clarity, allowing users to complete primary banking tasks faster and with more confidence. However, this comes with a tradeoff where secondary actions become less discoverable, potentially impacting power users. 👉 What to do next: Move forward with a prioritized dashboard, but: Preserve access to secondary actions via progressive disclosure (e.g., “More actions”) Validate with segment comparison: New / casual users vs. power users Where to go next (handoff) You now have a clear comparison with a tradeoff, so the next move is: 👉 Focus: Decisions Do we fully commit to simplification? Do we hybridize (prioritized + expandable)? Do we segment the experience? If you want, I can: Turn this into a test plan (A/B or usability study) Or help you compare specific dashboard elements (e.g., quick actions vs. navigation vs. alerts) using the same framework