# Hunches AI Skill Measure Area · Hunches Move · Decision Map --- ## 1. What the Skill Does The Hunches skill helps teams turn instinct into something they can actually test. It is the second move inside the Measure area of Glare's Decision Map. This is where teams take a shaped feeling about what might be wrong — or right — and write it down as a clear, falsifiable hypothesis. Every team has hunches. The problem is most hunches stay vague. They sound like opinions, not bets. They cannot be confirmed or disproved because they were never specific enough to test. The Hunches skill fixes that by giving instinct a structure — a template that forces teams to name the change, the audience, the expected impact, and the reason why. A good hunch has four qualities. | Quality | What it means | |---|---| | Tied to a user problem | It starts from friction, not a feature idea | | Clear and specific | It names the change, the audience, and the expected impact | | Linked to a metric | Results can be measured, not just observed | | Falsifiable | It could be wrong — and that is the point | The hunch template: **"We believe that [this change] for [this group] will [have this impact] because [supporting reason]."** Weak: "We believe users like shorter forms." Stronger: "We believe removing two steps from the signup form for first-time users will increase completion rates because users drop off at step 3." The difference is specificity. The stronger version names exactly what to change, who it affects, what should happen, and why. That means it can be tested, confirmed, or disproved. **The Falsifiability Rule** Teams often write hunches that sound testable but are not. The sign is that no result could actually change the team's mind. If the hunch is framed so that any outcome confirms it, it is not a hunch — it is an opinion dressed up as a hypothesis. The rule is simple: before moving to questions, ask what behavior would prove the hunch wrong. If the team cannot answer that, the hunch needs to be rewritten. A hunch that cannot be disproved cannot produce a signal. --- ## 2. Business Benefit Strong hunches keep teams moving without waiting for perfect data. They replace open-ended debate with a specific bet that research can confirm or kill. This helps teams: - stop building features based on assumptions nobody has named out loud - align the team around one specific belief before testing begins - move faster because the research question is already inside the hunch - reduce the cost of getting it wrong by testing early - keep a learning loop alive after launch by treating results as input, not final verdicts Hunches make instinct useful. --- ## 3. Skill Output When used correctly, the skill produces a clear hypothesis for a design effort. The hypothesis shows: - the change being proposed - the audience it is designed for - the expected impact and the reason for it - the metric that will confirm or disprove the result The example below shows how this works for a mobile banking dashboard. | Field | Example Output (Mobile Banking Dashboard) | |---|---| | Belief Statement | We believe users need to see their balance and recent transactions immediately so they can feel in control of their money without extra navigation | | Design Hypothesis | We believe that surfacing balance and the last three transactions on the home screen for habitual users will increase session completion because users currently abandon within 30 seconds when they cannot find this information quickly | | Metric to Track | Session completion rate and first-click success on balance | | What Would Disprove It | Session completion rate does not improve after the change, or users still abandon at the same rate despite the new layout | | Failure Mode to Watch | Writing a hunch so broad it cannot be tested. "Users want a better experience" is not a hunch. A hunch names a specific change with a specific expected result. | | Next Step Handoff | → glare-measure-questioning to turn this hypothesis into specific, testable research questions | The output connects directly to the other Measure moves: - Concepts provides the user need and business goal the hunch is built on - Questioning turns the hunch into specific research prompts - Findings checks whether the data confirms or disproves the hypothesis --- ## 4. Prompt Strategies The prompts below show different ways to use this skill. Each example uses a mobile banking dashboard update. --- ### Prompt 1 — Diagnostic Entry: Strengthen a weak hunch "Our team believes the mobile banking dashboard needs to be simpler. Users have said they find it confusing. Using the glare-measure-hunches skill, apply the hunch template to this belief and rewrite it as a strong, falsifiable hypothesis — naming the specific change, the audience, the expected impact, the reason why, and the metric we would track to confirm it." **Why this works:** "The dashboard needs to be simpler" is an opinion, not a hunch. It cannot be tested because nothing is specific enough to change or measure. This prompt uses the template to force the team to name exactly what simpler means and who it is for. **Best for:** - sprint planning where the problem feels obvious but undefined - any belief the team keeps repeating without testing - turning stakeholder feedback into something researchable --- ### Prompt 2 — Evidence Entry: Build a hunch from existing data "Our session data shows users abandon the mobile banking dashboard within 30 seconds. Drop-off is highest on users who are trying to find transaction history. Using glare-measure-hunches, help us write a design hypothesis that ties this behavior to a specific design change, names the expected impact, and identifies the metric we would track to confirm it." **Why this works:** Existing data is one of the best inputs for a hunch because it names the friction point precisely. This prompt uses the behavioral evidence to build a hypothesis that is already grounded in real user behavior, not assumption. **Best for:** - teams that have analytics data but have not turned it into a research direction - connecting session or funnel data to a design decision - starting a test sprint from a known problem --- ### Prompt 3 — Pressure-Test Entry: Check a hunch before testing "We have written this hypothesis: 'We believe that adding a summary card to the mobile banking dashboard home screen for new users will reduce time to find balance because users currently have to scroll to find it.' Using glare-measure-hunches, pressure-test this hypothesis for falsifiability — tell us what would prove it wrong, whether the metric is strong enough to guide a decision, and whether anything needs to be rewritten before we move to research questions." **Why this works:** Teams often move from hunch to testing without checking whether the hypothesis is actually falsifiable. This prompt uses the falsifiability rule to catch problems before research is run, saving time and avoiding results that cannot guide a decision. **Best for:** - quality-checking a hypothesis before a research sprint - any hunch the team feels confident about but has not stress-tested - preparing for a research review where findings need to hold up to scrutiny --- *Glare Framework · glare-measure-hunches · Measure Area* *Handoffs: glare-measure-concepts · glare-measure-questioning · glare-measure-findings · glare-design-signals*