# Playbook

### **From Audience Data to Audience Definition**

The Playbook provides the operational structure for Audience work — the inputs, workflows, prompts, and outputs that turn raw audience data into a definition clear enough to guide Collecting.

Audience work begins in one of two places: a team has a question they need to answer and needs to find the right audience to answer it, or a team has existing data — a survey, a Helio study, a CRM export, forum posts — and needs to interpret what it says about who is experiencing the situation and how. The Playbook covers both.

### **Inputs**

Audience inputs are whatever a team brings into the definition process. They vary in source, structure, and credibility. The Playbook treats all of them as raw material, not conclusions.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 493px;"><colgroup><col style="min-width: 25px;"><col style="width: 190px;"><col style="width: 278px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Input Type</strong></p></td><td colspan="1" rowspan="1" colwidth="190"><p><strong>Examples</strong></p></td><td colspan="1" rowspan="1" colwidth="278"><p><strong>What It Can Reveal</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Helio study results</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Named audience groups, poll response breakdowns, attribute distributions</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Behavioral and motivational attributes, how groups differ from each other, which needs are most active</p></td></tr><tr><td colspan="1" rowspan="1"><p>Survey data</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Customer satisfaction surveys, onboarding feedback, NPS responses</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Attitudinal attributes, lifecycle stage signals, patterns across segments</p></td></tr><tr><td colspan="1" rowspan="1"><p>CRM or analytics exports</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Lifecycle stage breakdowns, feature adoption data, churn cohorts</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Lifecycle and behavioral attributes, which customer segments to prioritize</p></td></tr><tr><td colspan="1" rowspan="1"><p>Advertising audience data</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Facebook segment definitions, Google audience lists, programmatic targeting specs</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Demographic context, reach composition — not experience quality</p></td></tr><tr><td colspan="1" rowspan="1"><p>Existing personas or segments</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Marketing personas, product personas, customer archetypes</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Starting hypotheses about attributes — must be validated before use in design decisions</p></td></tr><tr><td colspan="1" rowspan="1"><p>Forum or community posts</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Support threads, community discussions, app store reviews</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Contextual and motivational attributes, friction patterns expressed in natural language</p></td></tr><tr><td colspan="1" rowspan="1"><p>Stakeholder assumptions</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Leadership beliefs about the customer, product team mental models</p></td><td colspan="1" rowspan="1" colwidth="278"><p>Internal framing and bias — useful for surfacing what needs to be tested</p></td></tr></tbody></table>

A Skill receiving raw data — a CSV export, a forum thread, a survey summary — runs the same process: identify what source type this is, extract which attributes are present, and evaluate whether the data is strong enough to support a design decision or needs validation first.

## **Two Entry Points**

Every Audience workflow begins in one of two ways. The entry point determines how the workflow runs, but both arrive at the same output: a structured audience definition.

### **Entry Point A — Starting from a Question**

The team knows what they need to learn and needs to identify the right audience to learn it from. This is the most common starting point when beginning a new project, planning a Helio study, or deciding which customer segment to prioritize.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 590px;"><colgroup><col style="min-width: 25px;"><col style="width: 189px;"><col style="width: 376px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Step</strong></p></td><td colspan="1" rowspan="1" colwidth="189"><p><strong>Action</strong></p></td><td colspan="1" rowspan="1" colwidth="376"><p><strong>Output</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>1</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Name the learning question</p></td><td colspan="1" rowspan="1" colwidth="376"><p>A single question that specifies what the team needs to understand — comprehension, trust, task performance, or behavior</p></td></tr><tr><td colspan="1" rowspan="1"><p>2</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Identify the audience type</p></td><td colspan="1" rowspan="1" colwidth="376"><p>Which of the four types (Participants, Customers, Stakeholders, Project Team) is the right source for this question</p></td></tr><tr><td colspan="1" rowspan="1"><p>3</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Select 3–5 attributes</p></td><td colspan="1" rowspan="1" colwidth="376"><p>The behavioral, motivational, contextual, lifecycle, or demographic traits that define a testable group for this question</p></td></tr><tr><td colspan="1" rowspan="1"><p>4</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Identify the source</p></td><td colspan="1" rowspan="1" colwidth="376"><p>How this audience will be reached — Helio study, CRM pull, existing survey, stakeholder interviews</p></td></tr><tr><td colspan="1" rowspan="1"><p>5</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Map attributes to UX metrics</p></td><td colspan="1" rowspan="1" colwidth="376"><p>Which measurable outcomes each attribute connects to — completion, trust, satisfaction, error rate</p></td></tr><tr><td colspan="1" rowspan="1"><p>6</p></td><td colspan="1" rowspan="1" colwidth="189"><p>Draft the audience definition</p></td><td colspan="1" rowspan="1" colwidth="376"><p>A completed Audience Definition Card (see Output section)</p></td></tr></tbody></table>

### **Entry Point B — Starting from Existing Data**

The team has raw data in hand and needs to interpret what it says about the audience. This is the most common starting point when working with a completed Helio study, an inherited CRM segment, a survey that’s already been run, or forum and community data.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 590px;"><colgroup><col style="min-width: 25px;"><col style="width: 190px;"><col style="width: 375px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Step</strong></p></td><td colspan="1" rowspan="1" colwidth="190"><p><strong>Action</strong></p></td><td colspan="1" rowspan="1" colwidth="375"><p><strong>Output</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>1</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Identify the source type</p></td><td colspan="1" rowspan="1" colwidth="375"><p>Which of the four source types this data came from — Helio, advertising, CRM, or internal assumption — and what that means for credibility</p></td></tr><tr><td colspan="1" rowspan="1"><p>2</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Extract the attributes present</p></td><td colspan="1" rowspan="1" colwidth="375"><p>Which of the five attribute types are represented in the data, and which are missing</p></td></tr><tr><td colspan="1" rowspan="1"><p>3</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Name the audience groups</p></td><td colspan="1" rowspan="1" colwidth="375"><p>If the data contains multiple groups or segments, name each one by its defining attributes rather than its label</p></td></tr><tr><td colspan="1" rowspan="1"><p>4</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Evaluate credibility</p></td><td colspan="1" rowspan="1" colwidth="375"><p>Run the four credibility questions from Techniques to assess whether this data is strong enough for the decision at hand</p></td></tr><tr><td colspan="1" rowspan="1"><p>5</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Identify gaps</p></td><td colspan="1" rowspan="1" colwidth="375"><p>Which attribute types are missing and whether those gaps need to be filled before the audience definition is usable</p></td></tr><tr><td colspan="1" rowspan="1"><p>6</p></td><td colspan="1" rowspan="1" colwidth="190"><p>Draft the audience definition</p></td><td colspan="1" rowspan="1" colwidth="375"><p>A completed Audience Definition Card, with a credibility rating and any gaps noted</p></td></tr></tbody></table>

## **Prompts**

Prompts are the questions that surface the information needed to build or interpret an audience definition. They work in both directions: helping teams articulate what they already know, and helping Skills extract what matters from raw data.

### **Prompts for Starting from a Question**

-   What do we need to learn from this audience? Name one specific thing — not a list of goals.
    
-   Who is most likely to experience the friction or situation we’re investigating? Are they current customers, research participants, or a group we haven’t reached yet?
    
-   What do we know about how this group behaves? Frequency, task type, channel, experience level.
    
-   What drives this group? What are they trying to accomplish, and what do they value most?
    
-   Where are they in their relationship with the product? Trial, active, dormant, churned — or not yet a customer at all?
    
-   What context shapes how they interact with this design? Device, environment, time pressure, collaboration mode.
    
-   What would we measure to know if this audience found the design clear, trustworthy, and usable? Name two or three UX metrics.
    

### **Prompts for Interpreting Existing Data**

-   Where did this data come from? Helio poll, CRM export, survey, advertising platform, forum, or internal assumption?
    
-   What attributes are visible in this data? Which of the five types — behavioral, motivational, contextual, lifecycle, demographic — are represented?
    
-   What attributes are missing? Which dimensions of the situation does this data not explain?
    
-   Are the groups in this data defined by behavior or by label? If by label, what behavioral attributes would sharpen the definition?
    
-   Does this data source match the decision it’s being used to support? Is it qualified to answer the question at hand, or does it need validation first?
    
-   If there are multiple groups, how do their attributes differ? What does that difference reveal about the design situation?
    
-   What user need is most likely active for each group? What does the attribute profile suggest about what each group is trying to accomplish?
    

## **The Audience Definition Card**

The Audience Definition Card is the standard output of any Audience workflow. It is compact enough to hand directly to Collecting as a brief and structured enough for a Skill to interpret and act on.

A card is completed for each meaningful audience group. When a study or dataset contains multiple groups, each gets its own card.

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 517px;"><colgroup><col style="min-width: 25px;"><col style="width: 213px;"><col style="width: 279px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Field</strong></p></td><td colspan="1" rowspan="1" colwidth="213"><p><strong>What to Fill In</strong></p></td><td colspan="1" rowspan="1" colwidth="279"><p><strong>Example</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience Name</p></td><td colspan="1" rowspan="1" colwidth="213"><p>A short descriptive name built from the group’s defining attributes, not a marketing label</p></td><td colspan="1" rowspan="1" colwidth="279"><p>High-frequency mobile users with short session windows</p></td></tr><tr><td colspan="1" rowspan="1"><p>Audience Type</p></td><td colspan="1" rowspan="1" colwidth="213"><p>Participants, Customers, Stakeholders, or Project Team</p></td><td colspan="1" rowspan="1" colwidth="279"><p>Customers</p></td></tr><tr><td colspan="1" rowspan="1"><p>Source</p></td><td colspan="1" rowspan="1" colwidth="213"><p>Where this audience came from — Helio study, CRM segment, survey, advertising data, forum, internal assumption</p></td><td colspan="1" rowspan="1" colwidth="279"><p>Helio study — behavioral poll, April 2025</p></td></tr><tr><td colspan="1" rowspan="1"><p>Lifecycle Stage</p></td><td colspan="1" rowspan="1" colwidth="213"><p>Trial, Freemium, New Paying, Habitual, Power, Advocate, Dormant, or Churned — if applicable</p></td><td colspan="1" rowspan="1" colwidth="279"><p>Habitual</p></td></tr><tr><td colspan="1" rowspan="1"><p>Defining Attributes</p></td><td colspan="1" rowspan="1" colwidth="213"><p>3–5 attributes with their type noted. These are the traits that make this group experience the situation differently</p></td><td colspan="1" rowspan="1" colwidth="279"><p><strong>Behavioral: </strong>Daily task frequency, mobile-first</p><p><strong>Contextual: </strong>Short session windows, high time pressure</p><p><strong>Motivational: </strong>Efficiency-oriented, low tolerance for friction</p></td></tr><tr><td colspan="1" rowspan="1"><p>Design Situation</p></td><td colspan="1" rowspan="1" colwidth="213"><p>One or two sentences describing how this group’s attributes shape the design situation — what they make harder or more important</p></td><td colspan="1" rowspan="1" colwidth="279"><p>This group needs to complete core tasks in under two minutes on mobile. Any added steps or unclear navigation creates abandonment.</p></td></tr><tr><td colspan="1" rowspan="1"><p>Connected UX Metrics</p></td><td colspan="1" rowspan="1" colwidth="213"><p>2–3 UX metrics that the defining attributes connect to most directly</p></td><td colspan="1" rowspan="1" colwidth="279"><p>Time on Task, Completion Rate, Effort</p></td></tr><tr><td colspan="1" rowspan="1"><p>Credibility Rating</p></td><td colspan="1" rowspan="1" colwidth="213"><p>High, Medium, or Low — based on source type and whether the group is defined by behavior or label</p></td><td colspan="1" rowspan="1" colwidth="279"><p>High — Helio behavioral poll, attributes validated through responses</p></td></tr><tr><td colspan="1" rowspan="1"><p>Gaps</p></td><td colspan="1" rowspan="1" colwidth="213"><p>Any attribute types missing from the current definition that would sharpen the picture</p></td><td colspan="1" rowspan="1" colwidth="279"><p>No lifecycle data — unclear whether these are new or long-term users</p></td></tr></tbody></table>

### **Minimum Viable Card**

Not every situation allows for a fully populated card. The minimum a card needs to be usable for Collecting is:

-   Audience type identified
    
-   Source named and credibility rated
    
-   At least two behavioral or motivational attributes defined
    
-   One connected UX metric
    
-   The design situation described in one sentence
    

A card below this minimum is a signal that the audience isn’t defined clearly enough to move to Collecting. The next step is to identify which prompt above would surface the missing information.

**How the Card Maps to Organizing Work** The Audience Definition Card is the documentation artifact for Audience work. Its fields map directly to the four areas the Glare Assessment scores for documentation maturity.

Objectives: the learning question and audience type. These capture what the team was trying to understand and whose signals were relevant. 

Drivers: the defining attributes and design situation. These document the factors that shaped the interpretation of the audience and the conditions behind the design decision. 

Learnings: the credibility rating and gaps. These codify what the data revealed and what remains unresolved, so the next team or study starts from a documented position rather than from scratch.

Outputs: the completed card handed to Collecting, including connected UX metrics. This is the artifact that makes Audience work reusable and comparable across studies.

## **Working with Multiple Audience Groups**

Most real-world audience work involves more than one group. A Helio study surfaces several segments. A CRM export reveals multiple lifecycle stages. A product serves both habitual users and trial users whose needs look completely different.

Multiple groups are not a problem to resolve. They are information about the design situation. The Playbook handles them through repetition — one Audience Definition Card per group, then a comparison step that surfaces what the differences between groups mean.

### **Comparing Groups**

Once cards are completed for each group, run this comparison:

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 402px;"><colgroup><col style="min-width: 25px;"><col style="width: 377px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Comparison</strong></p></td><td colspan="1" rowspan="1" colwidth="377"><p><strong>What It Reveals</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p>Where do the attribute profiles diverge most?</p></td><td colspan="1" rowspan="1" colwidth="377"><p>The dimension of the situation that is creating the biggest difference in experience across groups</p></td></tr><tr><td colspan="1" rowspan="1"><p>Which group has the weakest credibility rating?</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Where validation is most needed before moving to Collecting</p></td></tr><tr><td colspan="1" rowspan="1"><p>Which group’s situation is most urgent for the current decision?</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Which group to prioritize in Collecting and which to address in a later study</p></td></tr><tr><td colspan="1" rowspan="1"><p>Do any groups share the same connected UX metrics?</p></td><td colspan="1" rowspan="1" colwidth="377"><p>Where a single Collecting method might serve multiple groups, reducing study complexity</p></td></tr></tbody></table>

The comparison step often reveals that two apparently different groups have more in common than the labels suggested — or that a group the team treated as secondary is actually the one whose situation matters most for the current decision.

## **Handoff to Collecting**

The Audience Definition Card is the handoff artifact. When Collecting receives it, the card tells the team or Skill three things it needs to choose the right collection method:

-   **Who to recruit or query.** The audience type, source, and attributes define the group precisely enough to build a study or query a dataset.
    
-   **What to measure.** The connected UX metrics define what Collecting needs to capture.
    
-   **How much to trust what comes back.** The credibility rating tells Collecting how much validation is already in place and how much new evidence is needed.
    

When the Audience Definition Card is weak or incomplete, Collecting loses focus. Studies get designed without a clear group in mind. Metrics get chosen without knowing whose experience they’re supposed to measure. The handoff is where Audience work either compounds into stronger evidence or dissolves back into assumption.

### **Handoff Back to User Needs**

Audience work sometimes surfaces a situation that wasn’t anticipated in the original user need definition. When the defining attributes of an audience group point to a need that wasn’t captured — or reveal that the stated user need is specific to one group but not others — the handoff goes back to User Needs before Collecting begins.

The signal for this handoff is: the design situation described in the card doesn’t match the user need the team is trying to address. When that happens, the audience definition is the evidence that sharpens the need, not a reason to pause the work.