# Components

How a signal is built and strengthened. Signals only work when the pieces come together.

Many teams already have input. They see behavior, review metrics, and talk through what feels off. But those pieces don’t always connect. The result is more discussion, not more clarity. This section shows how to bring that input together so it can guide a decision.

### **What goes into a signal**

Every signal starts with a mix of input:

-   What users did or said
    
-   How the experience performed
    
-   What the team notices or questions
    

On their own, these don’t move the work forward. They need structure.

* * *

## **Structure of a Signal**

A complete signal connects six parts:

-   **Design intuition** → what the team thinks might be happening
    
-   [**UX metric**](https://glare.helio.app/document-overview/decision-map/define/ux-metrics) → what users actually did or reported
    
-   [**User need**](https://glare.helio.app/document-overview/decision-map/define/user-needs) → what the user is trying to accomplish
    
-   **Context** → where the interaction happens
    
-   [**Business goal**](https://glare.helio.app/document-overview/decision-map/lead/business-goals) → what outcome matters
    
-   **Direction** → what the team should do next
    

When these line up, the signal becomes usable. The team can see what is happening, why it matters, and what to do next.

### **Signal Structure**

<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 555px;"><colgroup><col style="min-width: 25px;"><col style="width: 129px;"><col style="width: 120px;"><col style="width: 142px;"><col style="width: 139px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><p><strong>Component</strong></p></td><td colspan="1" rowspan="1" colwidth="129"><p><strong>What it is</strong></p></td><td colspan="1" rowspan="1" colwidth="120"><p><strong>What it adds</strong></p></td><td colspan="1" rowspan="1" colwidth="142"><p><strong>What to look for</strong></p></td><td colspan="1" rowspan="1" colwidth="139"><p><strong>What breaks if it’s weak</strong></p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Design intuition</strong></p></td><td colspan="1" rowspan="1" colwidth="129"><p>The starting point. What the team thinks might be happening.</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Focus. It points to where to look.</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A clear hunch written in simple terms</p></td><td colspan="1" rowspan="1" colwidth="139"><p>The work drifts or stays too broad</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.helio.app/document-overview/decision-map/define/ux-metrics"><strong>UX metric</strong></a></p></td><td colspan="1" rowspan="1" colwidth="129"><p>The measurement of user reaction</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Evidence. It shows what actually happened</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A metric that matches the question (comprehension, usability, etc.)</p></td><td colspan="1" rowspan="1" colwidth="139"><p>The signal can’t be read or compared</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.helio.app/document-overview/decision-map/define/user-needs"><strong>User need</strong></a></p></td><td colspan="1" rowspan="1" colwidth="129"><p>What the user is trying to accomplish</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Meaning. It explains why behavior matters</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A clear outcome the user is trying to reach</p></td><td colspan="1" rowspan="1" colwidth="139"><p>Behavior gets misinterpreted</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Context</strong></p></td><td colspan="1" rowspan="1" colwidth="129"><p>Where and how the interaction happens</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Specificity. It anchors the signal to a moment</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A defined screen, step, or flow</p></td><td colspan="1" rowspan="1" colwidth="139"><p>The signal feels too general</p></td></tr><tr><td colspan="1" rowspan="1"><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://glare.helio.app/document-overview/decision-map/lead/business-goals"><strong>Business goal</strong></a></p></td><td colspan="1" rowspan="1" colwidth="129"><p>The outcome the work is meant to influence</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Relevance. It connects to impact</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A clear goal the team is trying to move</p></td><td colspan="1" rowspan="1" colwidth="139"><p>The signal doesn’t affect decisions</p></td></tr><tr><td colspan="1" rowspan="1"><p><strong>Direction</strong></p></td><td colspan="1" rowspan="1" colwidth="129"><p>What the team should do next</p></td><td colspan="1" rowspan="1" colwidth="120"><p>Action. It turns insight into movement</p></td><td colspan="1" rowspan="1" colwidth="142"><p>A visible choice or next step</p></td><td colspan="1" rowspan="1" colwidth="139"><p>The signal stays informational</p></td></tr></tbody></table>

### **How a signal takes shape**

A signal is ready when:

-   The behavior is clear
    
-   The need explains why it matters
    
-   The context is specific
    
-   The metric matches the question
    
-   The direction is visible
    

If any of these are missing, the signal needs more work.

Signals don’t show up fully formed. They get shaped over time. It usually starts with a hunch. Something feels off or could be better. That gets written down and made more specific.

From there, the team connects it to what matters:

-   What the user is trying to do
    
-   What outcome needs to move
    

Then it gets anchored to a metric so it can be read and compared. At that point, the signal is clear enough to use. The team can put it next to different directions and see what holds up.

* * *

## **How signals are strengthened**

Even a clear signal can be improved. These techniques help tighten it:

-   **Clarify the need** → focus on what the user is trying to do
    
-   **Isolate the context** → keep it tied to a specific moment
    
-   **Choose the right metric** → match the measure to the question
    
-   **Connect to a decision** → make the options visible
    
-   **Compare directions** → look at differences side by side
    
-   **Define the next step** → make it clear what moves forward
    

As these get stronger, the signal becomes easier to read and easier to act on. When signals are built this way:

-   A clear read on what is happening
    
-   A shared view across the team
    
-   Visible tradeoffs between directions
    
-   A decision the team can move forward with
    

The work moves with more clarity and less back-and-forth. When the pieces don’t come together:

-   Signals feel incomplete
    
-   Feedback doesn’t connect to decisions
    
-   Teams fall back on opinion
    
-   Direction keeps shifting
    

The work keeps moving, but it’s harder to know if it’s moving in the right direction.

* * *

## **Quick use**

To build a signal:

-   Write the hunch in simple terms
    
-   Connect it to a user need and business goal
    
-   Choose a metric that matches the question
    
-   Compare real directions
    
-   Decide what moves forward
    

You don’t need perfect clarity. You need enough structure to move.

### **How this fits**

This page focuses on how signals are built.

-   [**Signal Types**](https://glare.helio.app/document-overview/design-signal/signal-quality) show where they apply
    
-   [**Signal Quality**](https://glare.helio.app/document-overview/design-signal/signal-quality) shows if they can be trusted
    
-   [**Capturing Signals**](https://glare.helio.app/document-overview/design-signal/capturing-signals) shows how to create them in the work
    

Together, these make signals something the team can rely on, not just discuss.