Signals are most useful when they are part of the work, not something added after. Many teams wait until the end to gather feedback or review metrics. By that point, decisions have already been made, and it’s harder to change direction. Capturing signals earlier keeps the work grounded while it’s still moving.
What this does
Capturing signals gives you a simple way to turn input into direction as you go.
-
Input: ideas, hunches, designs, or flows
-
Process: shape and test the signal
-
Output: a clearer direction the team can act on
This helps the team move forward without waiting for perfect certainty.
How signals are captured
Signals don’t start as signals. They start as small moments in the work.
A question comes up in a review. A design feels unclear. Two directions are on the table and no one is sure which one will hold. The team has a sense of what might be happening, but not enough clarity to move forward with confidence.
Instead of pushing through or waiting for more data, this is where signals begin to take shape.
Capturing a signal means slowing down just enough to connect what the team is seeing to something that can be understood and acted on. It doesn’t require a full study or a long research cycle. It requires making the thinking visible, grounding it in what matters, and bringing in just enough input to reduce uncertainty.
From there, the work follows a simple flow. Each step builds on the last, turning a loose observation into a clear direction the team can move forward with.
1. Frame the Signal
Start with a hunch
Every signal begins with a moment where something doesn’t feel right.
This usually comes up in a review or while looking at the work. Someone notices friction, confusion, or an opportunity to improve. It’s not proven yet, but it’s enough to pause and ask a question.
The important part here is to pull that thought out of the conversation and make it visible.
Example:
“We think users might not understand what to do on this screen.”
At this point, you’re not solving it. You’re just capturing where to look.
👉 Go deeper: Explore Hunches
Make it clear
Hunches are often vague. If they stay that way, the conversation drifts.
This step is about tightening the thinking by asking a better question. The goal is to make it specific enough that the team can actually respond to it. You’re moving from a feeling to something you can test.
**Example:
**“Do users understand what action to take on this screen?”
Now the team is aligned on what they’re trying to learn.
👉 Go deeper: Explore Questions
2. Ground the Signal
Connect to what matters
A question on its own isn’t enough. It needs to be tied to why it matters. This is where you connect the work to:
-
What the user is trying to accomplish
-
What outcome the team is trying to move
This step grounds the signal so it’s not just about the interface, but about impact.
Example:
-
User need → “complete the next step without hesitation”
-
Business goal → “increase onboarding completion”
Now the team understands why this matters.
👉 Go deeper: User Needs
👉 Go deeper: Business Goals
3. Measure the signal
Anchor it to a metric
At this point, the team knows what they’re looking for. Now they need a way to read it. This is where you choose a metric that reflects the question. The goal isn’t to measure everything. It’s to measure the one thing that will make the answer clear.
Example:
- Comprehension → do users understand what to do
This gives the signal a way to be seen, not just discussed.
👉 Go deeper: Collecting
👉 Go deeper: UX Metrics
Put it next to the work
Signals only work when they are tied to real options.
This is where you place the signal next to the designs or directions the team is considering. Instead of reviewing work in isolation, you are now evaluating how each option holds up.
Example:
-
Version A → detailed explanation
-
Version B → simple call to action
Now the signal has something concrete to test against.
👉 Go deeper: Concepts
Bring in real input
This is where the signal starts to gain weight. You bring in just enough user input to see what’s actually happening. This can be fast and lightweight. The goal is not to run a full study, but to reduce uncertainty.
You’re looking for both:
-
metrics → what users did
-
comments → why they reacted that way
Example:
-
72% understood Version B
-
comments: “this one is easier to follow”
Now the signal reflects real behavior, not just team opinion.
👉 Go deeper: UX Metrics
4. Use the signal
Compare and read
This is where most teams fall back into opinion. Instead, you stay with the signal. You’re not just looking at numbers. You’re reading how the options differ and what that means.
You’re asking:
-
Where is one direction clearly stronger
-
Where do both struggle
-
Where do the results and comments align
**Example:
**Version B shows higher comprehension and clearer feedback.
Version A shows hesitation and confusion.
Now the tradeoff is visible. The signal is doing the work.
👉 Go deeper: Comparison
Decide what moves forward
With the signal in place, the decision becomes clearer. You’re not trying to prove something is perfect. You’re choosing the direction that holds up better.
This might mean:
-
selecting one option
-
refining the stronger one
-
combining parts
-
stopping something
**Example:
**Move forward with Version B and simplify the CTA further.
The signal doesn’t remove judgment. It gives it focus.
👉 Go deeper: Decisions
Keep the signal attached
Most decisions don’t fail in the moment. They drift later. This step keeps the signal connected to the work as it moves forward. It gives the team a shared reference point so they don’t have to restart the conversation.
**Example:
**“We chose this because users understood it faster.”
Now the decision holds across reviews, handoffs, and future changes.
👉 Go deeper: Run a Design Review
<table xmlns="http://www.w3.org/1999/xhtml" style="min-width: 50px;"><colgroup><col style="min-width: 25px;"><col style="min-width: 25px;"></colgroup><tbody><tr><td colspan="1" rowspan="1"><h3><strong>What you get from this</strong></h3><p>When signals are captured this way:</p><ul><li><p>decisions form earlier</p></li><li><p>feedback connects to something concrete</p></li><li><p>tradeoffs are easier to explain</p></li><li><p>direction carries forward with more confidence</p></li></ul><p>The team spends less time revisiting decisions and more time moving forward.</p></td><td colspan="1" rowspan="1"><h3><strong>Where it breaks</strong></h3><p>Signals lose value when:</p><ul><li><p>hunches stay vague</p></li><li><p>metrics don’t match the question</p></li><li><p>no clear direction is defined</p></li><li><p>input is gathered too late</p></li></ul><p>In these cases, signals come in after the decision instead of guiding it.</p></td></tr></tbody></table>
Quick use
To capture a signal:
-
Write the hunch
-
Connect it to a need and goal
-
Choose a metric
-
Compare directions
-
Decide what moves forward
-
Keep the signal attached
You don’t need perfect clarity. You need enough to move.
How this fits
This page shows how signals are created in the work.
-
Components show how signals are built
-
Signal Types show where they apply
-
Signal Quality shows if they can be trusted
Together, these turn signals into a practical way to guide decisions.