# Techniques ### **Attributes Before Answers** Techniques cover the thinking behind Audience work — how to read the groups Helio surfaces, how to use attributes to clarify the situation, and how to recognize when the user signals you have are strong enough to act on. Where the Playbook covers execution, Techniques covers interpretation. The goal is not to collect more data. It is to understand what the data you already have is actually telling you about who experiences this situation differently and why. ## **Reading Helio Audience Groups** When Helio runs a poll, it assigns participants to named groups based on their responses. Those group names are the starting point, not the conclusion. The real interpretive work is understanding what the attributes behind each group reveal about the design situation. A group called “High-frequency mobile users” tells you something about behavior. But the attributes that built that group — daily task frequency, mobile-first context, short session length — tell you what the situation actually looks like for those people and where friction is most likely to appear. ### **Three Questions for Every Helio Group** When a Helio audience group surfaces, work through these questions before drawing conclusions:

Question	What It Surfaces
What attributes define this group?	The behavioral, motivational, or contextual traits that distinguish this group from others — not just their label
How does this group’s situation differ from the others?	The specific conditions — workflow, environment, experience level — that make this group experience the design differently
What user need is most likely active for this group?	The connection between the group’s attributes and the underlying need they’re trying to meet — which feeds directly into User Needs

If you cannot answer all three, the audience group is not yet legible enough to carry into a design decision. That’s a signal to go deeper into the attributes before moving to Collecting. ### **When Groups Surprise You** Sometimes Helio surfaces a group you didn’t expect — a segment that behaves differently from your assumptions, or a split that reveals the audience is less uniform than the team believed. These surprises are high-value. They usually mean one of three things: the team’s internal assumptions were wrong, the product is attracting an adjacent audience it wasn’t designed for, or the design situation is more complex than the problem statement captured. In all three cases, the right response is to examine the attributes of the unexpected group before deciding how to respond. Don’t collapse the surprise back into your existing framing. Let it sharpen the situation first. ## **Attributes as Situation Clarifiers** Attributes are the mechanism that turns an audience group into a legible design situation. They describe the real conditions — what people do, what drives them, where they work, where they are in their relationship with the product — that shape how a design is experienced. Glare uses five canonical attribute types. Each one reveals a different dimension of the situation. Used together, they give teams a sharper picture of who experiences a situation differently and what that difference means for the design.

Attribute Type	What It Reveals About the Situation	When It Matters Most
Behavioral	What people actually do — frequency, task patterns, feature adoption, interaction habits	When you need to understand usage patterns or identify where behavior diverges across groups
Motivational	Why people engage — their goals, values, risk tolerance, and confidence level	When similar behaviors produce very different experiences, or when trust and satisfaction signals conflict
Contextual	Where and how people interact — device, environment, connectivity, time pressure, collaboration mode	When environmental conditions are shaping usability or comprehension in ways that aren’t obvious from task data alone
Lifecycle	Where people are in their relationship with the product — trial, active, habitual, dormant, churned	When the same friction means different things at different stages, or when retention and activation signals diverge
Demographic	Background context that affects comprehension or accessibility — role, region, language, experience level	When clarity or accessibility breaks down across specific groups, or when localization affects interpretation

### **Choosing the Right Attributes** Three to five attributes is the working range. Fewer than three leaves too much of the situation unexplained. More than five creates over-segmentation — groups that are too narrow to produce meaningful patterns. The right attributes are the ones that explain why different people experience the same situation differently. Start with behavioral attributes because they are the most observable and directly tied to design decisions. Add motivational or contextual attributes when behavior alone doesn’t explain the gap. Demographic attributes support the others — they add useful context but rarely explain a design situation on their own. Use them when role, language, or accessibility needs are genuinely shaping how people interpret or interact with the design. ### **Attributes Connect Audience to User Needs** The strongest use of attributes is the connection they create between an audience group and a user need. When you know that a group’s defining attributes are high time pressure, mobile context, and low prior familiarity, you can see directly which user needs are most likely active — speed, clarity, and low effort to get started. This connection is what makes Audience useful upstream of User Needs. The attributes don’t just describe the group. They illuminate the situation well enough that the right user need becomes visible without starting from scratch. ## **Evaluating User Signal Credibility** Not all user signals are equally qualified to support a design decision. The source of a signal determines how much weight it can carry — and how it should be used. Credibility evaluation is not about dismissing data. It is about matching the signal to the decision it is being asked to support. A Facebook segment is credible evidence of reach. It is not credible evidence of how a design performs in use. Treating it as both creates decisions built on the wrong foundation. ### **Four Credibility Questions** Run these questions against any user signal before using it to support a design decision:

Question	What a Weak Signal Looks Like	What a Strong Signal Looks Like
Was this built from behavior or assumption?	Based on demographic data, team instinct, or stakeholder belief	Based on observed behavior, poll responses, or measured interaction
Does the source match the decision?	Using a targeting segment to validate a usability hypothesis	Using a Helio participant group to predict how users will experience a flow
Is the group defined by attributes or labels?	“Women 25–34 in urban markets” — a label without behavioral grounding	“Users who complete onboarding in under five minutes and return within 48 hours” — behaviorally defined
Has this signal been validated by a closer source?	CRM segment used as a proxy for participant behavior without any testing	CRM segment used to frame a Helio study that then validates the behavior

### **Credibility Is Relative to the Decision** A user signal doesn’t have a fixed credibility level. Its credibility depends on what you’re using it for. Internal assumptions are low credibility for a launch decision but perfectly appropriate for framing an early hypothesis. CRM lifecycle data is medium credibility for understanding experience quality but high credibility for identifying which customer stage to prioritize. The question is always: is this signal qualified to support the specific decision we’re trying to make right now? ## **Recognizing Audience Gaps** Audience gaps appear when the signals a team is working with don’t cover the full situation — when the audience is too narrow, too homogeneous, or built from a source that doesn’t reflect real use. Gaps are often invisible because teams don’t know what they’re missing. These are the most reliable indicators: • **All signals come from one source type.** Every piece of data is from advertising, or from internal assumptions, or from a single Helio study. No cross-source comparison has happened. • **The audience is defined by demographics, not behavior.** The team knows who their users are in marketing terms but not what those users actually do or need. • **Lifecycle stages are missing.** The team has data on active users but nothing on trial users, dormant users, or churned users — which means friction at the edges of the lifecycle is invisible. • **Conflicting signals are being averaged.** Different audience groups are producing different results, but the team is combining them into a single finding rather than treating the difference as information. • **The audience hasn’t been tested recently.** The participant groups or customer segments being used were defined months or years ago and may no longer reflect who is actually using the product. When any of these appear, the right response is not to gather more data from the same source. It is to identify which attribute type is missing and find a Collecting method that can fill it. ## **Comparing Signals Across Sources** Most teams have audience data from more than one source — Helio groups, CRM segments, advertising data, and internal assumptions often exist simultaneously. The challenge is knowing how to use them together without letting weaker sources contaminate stronger ones. ### **The Alignment Check** When user signals from different sources point in the same direction, credibility increases. When they diverge, the divergence is worth investigating before drawing conclusions.

Situation	What It Means	What to Do
Helio group and CRM segment align	Behavioral validation is consistent with lifecycle data — high confidence the signal is real	Carry into Collecting with confidence; the audience is well-defined
Helio group and advertising segment diverge	The people who see the product are not the same as the people who find it useful — a targeting or positioning gap	Surface this to stakeholders before designing; it’s a strategy question, not a usability question
Internal assumptions and Helio groups conflict	The team’s mental model of the user is wrong in at least one dimension	Treat the Helio data as ground truth; use the assumption as a hypothesis to test rather than a fact to design around
Multiple Helio groups produce different results	The audience is not uniform — different segments have genuinely different needs	Do not average the results; treat each group as a separate design situation and identify which needs priority

## **Spotting Audience Drift** Audience drift happens when the people a team is designing for quietly shift away from the audience the product was originally built for. It is one of the most common and least-noticed problems in product design. Drift usually appears gradually — a new customer segment starts growing, a power user cohort develops expectations the original audience never had, or an adjacent use case becomes more common than the primary one. By the time it’s visible in the metrics, the team has already been designing for the wrong audience for months. ### **Early Indicators of Drift** • **Satisfaction scores are flat but churn is rising.** Users say the product is fine but they’re leaving — which usually means the product is still serving the original audience but not the audience that’s actually growing. • **Feature requests are coming from an unexpected segment.** The requests don’t fit the original use case, which means a different audience has become a significant share of the user base. • **Helio group compositions have changed across studies.** The attributes that define the largest group in recent studies look different from the attributes that defined them a year ago. • **Internal assumptions are more than six months old.** The team is still designing for a mental model of the user that predates recent growth or product changes. Audience drift is not always a problem. Sometimes the new audience represents a better opportunity than the original one. But it is always a decision — and teams can only make that decision consciously if they can see the drift happening. ## **Connecting Techniques to the Playbook** Techniques produces the interpretive clarity that the Playbook turns into structured outputs. Once a team has read their Helio groups, evaluated attribute coverage, assessed user signal credibility, and identified any gaps or drift, the Playbook provides the workflows and prompts for organizing that understanding into a usable audience definition. If the user signals are still too thin or conflicting after applying these techniques, the next step is Collecting — gathering stronger evidence from a more appropriate source before moving forward. The goal of Techniques is not a perfect audience definition. It is enough clarity about who experiences this situation differently — and why — that the rest of the work can proceed with confidence.