# Decisions

### **Choosing the Next Step That Reduces Uncertainty**

Decisions help teams recognize which situation they are in and identify the next step that moves the work forward with more confidence. Audience decisions are not about whether the audience definition is perfect — they are about whether it is clear enough to support what needs to happen next.

Each situation below maps to a next step. Some steps move forward into Collecting or Measure. Others loop back to strengthen the audience definition before proceeding. A few surface questions that belong with stakeholders before any design work continues.  

### **Recognizing the Complexity of Your Audience Situation**

  
**Not all Audience work is equally complex. The situation you're in shapes how much time and validation the definition needs before moving forward.**

**Simple:** One audience source, Helio-defined, High credibility, attributes clear. Move directly to Collecting. The definition doesn't need further refinement. Complicated: Multiple sources, mixed credibility, or two groups that need to be separated and compared. Requires structured work through the Playbook before Collecting can begin. This is where most Audience work lives. Complex: Conflicting sources pointing to a strategy question, audience drift detected, or no external data exists and the team is operating entirely from internal assumptions. Requires stakeholder alignment or a foundational Helio study before any design work proceeds.

When the situation feels more complex than the Primary Routing Table covers, that's the signal to escalate rather than approximate.

## **Primary Routing Table**

Find the situation that most closely matches where the team is. The next step is the action that reduces the most uncertainty from that position.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 489px;"><colgroup><col style="min-width: 25px;"><col style="width: 148px;"><col style="width: 169px;"><col style="width: 147px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="148"><p><strong>What It Signals</strong></p></td><td colspan="1" rowspan="1" colwidth="169"><p><strong>Next Step</strong></p></td><td colspan="1" rowspan="1" colwidth="147"><p><strong>Where It Goes</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience is defined, source is Helio, credibility is High, attributes cover the situation</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The audience definition is strong enough to support Collecting. The group is behaviorally defined and the situation is clear.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Complete the Audience Definition Card and hand off to Collecting with the connected UX metrics</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Collecting → choose the method that fits the audience type and attributes</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience is defined, source is CRM or survey, credibility is Medium, behavioral attributes are present but motivational or contextual attributes are assumed</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The definition is usable but incomplete. Collecting can begin but needs a validation step built in.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Proceed to Collecting with a credibility note — include at least one method that validates the assumed attributes before drawing conclusions</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Collecting → include a screener or attitudinal question to validate the assumed attributes</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience source is an advertising segment or demographic label, credibility is Low</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The current definition is not qualified to support a design decision. A behavioral audience needs to be built first.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Run a Helio screener poll to establish a behaviorally defined group before any usability or validation study begins</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Back to Audience → Helio screener, then re-evaluate credibility before Collecting</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience source is internal assumptions only, no external data exists</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The team is working from instinct. The definition is a hypothesis, not a starting point for design.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Document the assumptions as hypotheses in the Audience Definition Card, rate credibility Low, and run a Helio study to validate before any design work proceeds</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Back to Audience → Helio validation study, then return to Decisions</p></td></tr><tr><td colspan="1" rowspan="1"><p>Helio or data reveals two or more distinct groups that have been treated as one</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The audience is not uniform. Averaging the groups will produce findings that serve neither.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Complete a separate Audience Definition Card for each group, then use the comparison step from the Playbook to identify which group to prioritize for the current decision</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Back to Audience → multiple cards, then Collecting prioritizes one group per study</p></td></tr><tr><td colspan="1" rowspan="1"><p>The audience definition reveals a design situation that doesn’t match the stated user need</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The audience work has surfaced a need that wasn’t captured, or revealed that the stated need is specific to one group and not others.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Return to User Needs with the audience definition as new evidence. The attributes are the input that sharpens the need before Collecting begins.</p></td><td colspan="1" rowspan="1" colwidth="147"><p>User Needs → refine the need statement, then return to Audience and Collecting</p></td></tr><tr><td colspan="1" rowspan="1"><p>Advertising audience data and Helio audience data are pointing in different directions</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The people who see the product are not the same as the people who find it useful. This is a targeting or positioning gap, not a usability question.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Surface the divergence to stakeholders before designing. Frame it as a strategic question: who is the product actually for, and does the current targeting reflect that?</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Stakeholders → alignment on target audience before design work resumes</p></td></tr><tr><td colspan="1" rowspan="1"><p>No audience data exists and no study has been run</p></td><td colspan="1" rowspan="1" colwidth="148"><p>The team has no user signal to work from. Any design decision made now will be built on assumption.</p></td><td colspan="1" rowspan="1" colwidth="169"><p>Pause design work. Run a Helio audience poll or screener to establish the minimum viable audience definition before proceeding.</p></td><td colspan="1" rowspan="1" colwidth="147"><p>Back to Audience → Helio study, then return to Decisions</p></td></tr></tbody></table>

## **Credibility Decision Guide**

Credibility rating is the fastest shortcut to the right next step. When in doubt about which situation applies, start here.

<table xmlns="http://www.w3.org/1999/xhtml" style="width: 616px;"><colgroup><col style="width: 120px;"><col style="width: 117px;"><col style="width: 190px;"><col style="width: 189px;"></colgroup><tbody><tr><td colspan="1" rowspan="1" colwidth="120"><p><strong>Credibility Rating</strong></p></td><td colspan="1" rowspan="1" colwidth="117"><p><strong>Can Collecting Begin?</strong></p></td><td colspan="1" rowspan="1" colwidth="190"><p><strong>What Collecting Needs</strong></p></td><td colspan="1" rowspan="1" colwidth="189"><p><strong>When to Stop and Rebuild</strong></p></td></tr><tr><td colspan="1" rowspan="1" colwidth="120"><p>High</p></td><td colspan="1" rowspan="1" colwidth="117"><p>Yes — proceed with confidence</p></td><td colspan="1" rowspan="1" colwidth="190"><p>The Audience Definition Card as the brief. Collecting chooses the method that fits the audience type and attributes.</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Only if the Collecting method surfaces a group composition that doesn’t match the definition — return to Audience and re-evaluate.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="120"><p>Medium</p></td><td colspan="1" rowspan="1" colwidth="117"><p>Yes — with a validation step</p></td><td colspan="1" rowspan="1" colwidth="190"><p>A screener or qualifying question that confirms the assumed attributes before the main study runs. Do not draw conclusions from assumed attributes until they are validated.</p></td><td colspan="1" rowspan="1" colwidth="189"><p>If the validation step reveals the assumed attributes were wrong, return to Audience and rebuild the definition before continuing.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="120"><p>Low</p></td><td colspan="1" rowspan="1" colwidth="117"><p>No — establish the audience first</p></td><td colspan="1" rowspan="1" colwidth="190"><p>A Helio screener or behavioral poll to build a group that is qualified for the decision at hand. Collecting cannot produce credible findings from a Low credibility audience definition.</p></td><td colspan="1" rowspan="1" colwidth="189"><p>After the Helio study, return to Decisions and re-evaluate. If credibility reaches Medium or High, proceed to Collecting.</p></td></tr></tbody></table>

## **When the Audience Is More Than One Group**

Multiple audience groups are the most common decision challenge in Audience work. Helio frequently surfaces two or three distinct segments where the team expected one. The decision is not which group is “right” — it is which group to prioritize for the current decision.

<table xmlns="http://www.w3.org/1999/xhtml" style="width: 634px;"><colgroup><col style="width: 257px;"><col style="width: 377px;"></colgroup><tbody><tr><td colspan="1" rowspan="1" colwidth="257"><p><strong>Group Comparison Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="377"><p><strong>Decision</strong></p></td></tr><tr><td colspan="1" rowspan="1" colwidth="257"><p>One group has High credibility, the other has Medium or Low</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Prioritize the High credibility group for the current Collecting study. Plan a follow-up study to validate and strengthen the other group’s definition before designing for them.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="257"><p>Both groups have High credibility but different connected UX metrics</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Run separate Collecting studies, one per group. Do not combine them — the metrics are different because the situations are different.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="257"><p>Both groups have the same connected UX metrics but different attributes</p></td><td colspan="1" rowspan="1" colwidth="377"><p>A single Collecting study with a screener split may work. Flag the attribute differences in the study design so results can be analyzed separately.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="257"><p>One group represents the stated user need, the other represents an unexpected situation</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Complete the current work for the stated need group. Document the unexpected group as a new audience finding and return to User Needs to assess whether it represents an unaddressed need.</p></td></tr><tr><td colspan="1" rowspan="1" colwidth="257"><p>Groups are so different that no single Collecting method serves both</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Treat them as separate workstreams. Each group gets its own Audience Definition Card, its own Collecting brief, and its own path through Measure.</p></td></tr></tbody></table>

## **Cross-Block Routing**

Audience decisions sometimes point outside the Audience block entirely. These are the most common cross-block situations and where they lead.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 466px;"><colgroup><col style="min-width: 25px;"><col style="width: 140px;"><col style="width: 301px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Situation</strong></p></td><td colspan="1" rowspan="1" colwidth="140"><p><strong>Block</strong></p></td><td colspan="1" rowspan="1" colwidth="301"><p><strong>Why</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience definition reveals a user need the team hasn’t named</p></td><td colspan="1" rowspan="1" colwidth="140"><p>User Needs</p></td><td colspan="1" rowspan="1" colwidth="301"><p>The attributes have illuminated the situation well enough to identify a need. Return to User Needs with the audience definition as evidence before designing or testing.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience definition is complete and credibility is High or Medium with validation</p></td><td colspan="1" rowspan="1" colwidth="140"><p>Collecting</p></td><td colspan="1" rowspan="1" colwidth="301"><p>The definition is the brief. Collecting chooses the method — Helio study type, survey, analytics query — based on the audience type and connected UX metrics.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience definition points to a specific design situation that maps to a Measure concept</p></td><td colspan="1" rowspan="1" colwidth="140"><p>Measure → Concepts</p></td><td colspan="1" rowspan="1" colwidth="301"><p>When the situation is clear enough — onboarding flow, loyalty dashboard, mobile navigation — the relevant Measure concept tells the team which test to run and what to measure.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Advertising and Helio data diverge, suggesting a targeting gap</p></td><td colspan="1" rowspan="1" colwidth="140"><p>Stakeholders</p></td><td colspan="1" rowspan="1" colwidth="301"><p>This is a strategy question. Design cannot resolve who the product is actually for. Stakeholders need to align on the target audience before design work resumes.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience drift is detected — the current audience no longer matches the designed-for audience</p></td><td colspan="1" rowspan="1" colwidth="140"><p>User Needs and Stakeholders</p></td><td colspan="1" rowspan="1" colwidth="301"><p>Drift is both a need question (what does the new audience actually need?) and a strategy question (is this the audience the product should serve?). Both blocks need to be engaged before design continues.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience work surfaces a lifecycle stage gap — no data on a stage that matters for the product</p></td><td colspan="1" rowspan="1" colwidth="140"><p>Collecting</p></td><td colspan="1" rowspan="1" colwidth="301"><p>The gap is the brief. Collecting needs to design a study that reaches the missing lifecycle stage — often a Helio poll targeting dormant or churned users.</p></td></tr></tbody></table>

## **Signals That Audience Work Is Complete**

Audience work is complete when the definition is clear enough to hand off. These are the indicators:

• **Source is identified and credibility is rated.** The team knows where the audience data came from and what that means for how much weight it can carry.

• **At least three behavioral or motivational attributes are defined.** The group is described by what they do and why, not by a demographic label.

• **The design situation is described in one or two sentences.** The team can articulate what makes this group’s experience of the situation different from other groups.

• **Connected UX metrics are identified.** Collecting knows what to measure.

• **Multiple groups are separated into individual cards.** No groups have been averaged together that have meaningfully different attributes.

• **The audience definition matches the stated user need.** If it doesn’t, that mismatch has been returned to User Needs before Collecting begins.

Audience work does not need to be exhaustive to be complete. It needs to be precise enough that Collecting has a clear group to study and Measure has a clear situation to test against. Clarity over comprehensiveness.

#### **  
Audience Lives in Exploratory Territory**

In the Glare Assessment's Guiding Decisions dimension, Audience sits in the Exploratory quadrant — Abstract and Effectual. This means Audience work produces directional signals, not causal proof. The audience definition points toward the right group and the right situation. It does not confirm that the design will work.

This is not a limitation. It is the correct role for this stage of the work. Exploratory signals reduce uncertainty enough to make Collecting purposeful. The shift from Exploratory to Analytical happens in Collecting, where methods are chosen and data is gathered against a defined group. The shift to Evidential happens in Measure, where signals become proof.

When Audience work feels inconclusive, that is usually appropriate. The goal is not a certain answer — it is a definition clear enough to move the work into territory where certainty can be built.

## **What Decisions Doesn’t Resolve**

Decisions routes teams to the right next step. It does not resolve questions that belong to other parts of the work:

• **Which user need to prioritize** — that is a User Needs decision, not an Audience decision.

• **Which Collecting method to use** — that is Collecting’s job, informed by the Audience Definition Card.

• **Which Measure concept applies** — the design situation in the card points toward it, but Measure makes the final determination.

• **Whether the product should serve a new audience** — that is a stakeholder and strategy decision that Audience work can surface but not resolve.

• **How to reconcile competing stakeholder views of the customer** — Audience can show where signals diverge, but alignment is a leadership decision.

When Decisions surfaces one of these questions, the right response is to name it clearly, route it to the right block or the right people, and document it so it doesn’t get absorbed back into the design work as an unresolved assumption.