Create Your First Signal

Product and design work often slows at the moment a decision needs to be made across teams.

A common situation looks like this:

You have two directions for a flow. Design prefers one. Product leans another way. Engineering is thinking about complexity. There’s some feedback and a bit of data, but nothing that clearly points to a decision.

The work has to keep moving forward, but the decision isn’t sharp and things start to Frankenstein. It gets revisited. It loses clarity as it moves across teams. Confidence drops. This is where most teams spend their time.

Glare helps bring structure to that moment. It gives the team a way to take what already exists—intuition, direction, user input—and shape it into something that can guide a decision.

That “something” is a signal.

What You’re Actually Doing

Creating a signal means taking a hunch and giving it enough structure so it can guide a real decision. A signal comes from bringing together what the team already knows:

• A UX metric (what you’re trying to understand or improve)

• Your intuition (what the team is noticing)

• The direction you’re considering

• The context the work sits in within a concept.

• The business goal you’re trying to move

• The user need you’re trying to satisfy

Most teams have all of this floating around already.  It just lives in different places…conversations, notes, feedback, and assumptions.

Creating a signal connects these pieces.

Once they are connected, the team has something concrete to work from. The conversation becomes clearer, tradeoffs are easier to see, and the decision has direction behind it.

---

Creating a Design Signal

Start with a Hunch

Every signal starts with something the team is already reacting to.

It usually doesn’t show up as a formal idea. It shows up in conversation. Someone points out that a flow feels off. Another person thinks a different direction might work better. There’s a sense that something could improve, but no one has fully defined what that means yet.

That’s the hunch.

You’ll hear it in phrases like:

• “This direction feels cleaner”

• “Users might get stuck here”

• “This could improve conversion”

At this point, everyone is reacting to the work, but not necessarily in the same way. The conversation expands, more opinions come in, and the decision stays open.

The goal here is simple: make that hunch clear enough that the team is aligned on what they are actually reacting to.

Make It Clear

Take a moment to write the hunch down. Keep it to one sentence. Focus on what you think is happening, not why it’s right.

For example:

• “Users may not understand what to do on this screen”

• “This version may make the next step clearer”

This step is small, but it changes the conversation. Instead of reacting to a general feeling, the team now has something specific to respond to. It gives the work a starting point that everyone can see. Once the hunch is clear, connect it to the parts of the work that actually matter. This is where it starts to become a signal.

Bring in two things:

1. What the user needs

2. What the business is trying to move

Use a User Needs Skill to clarify:

• What the user is trying to do

• What they expect to happen

• Where the experience might break

Use a Business Goals Skill to define:

• What outcome matters

• What success looks like

Now the work is grounded. It’s no longer just a team perspective. It’s connected to real user behavior and real outcomes.

Shape the Signal

With that context in place, the next step is to tighten the signal so it can guide a decision. Focus on one thing you want to understand. Refine the hunch into something more specific:

• “Users may not understand what action to take here”

• “This version may improve completion of the next step”

Then give it a way to be read by anchoring it to a UX metric:

• Comprehension

• Usability

• Confidence

• Desirability

This gives the team a shared lens. Now when you look at the work, you’re not just reacting. You’re looking for something specific.

Check out how to create a design signal

---

Using a Design Signal

At this point, the signal is ready to be used. This is where the work starts to shift.

Up until now, the team has been reacting. Different perspectives, different opinions, and partial data have been shaping the conversation. Now there’s something shared to work from.

Place the signal next to the directions you’re considering and look at them together. You’re no longer reviewing designs on their own. You’re looking at how each direction holds up against something specific.

Ask:

• What is the signal telling us to look for?

• How does each option respond to that?

As you do this, patterns begin to show up. Sometimes one direction is clearly stronger. Other times both options reveal gaps. In some cases, the signal itself needs to be refined. If the signal still feels thin, bring in a small amount of input.

This can be quick and lightweight:

• Show both directions to a few users

• Ask a focused question tied to the metric

• Review existing feedback or behavior

This step adds weight to what you’re seeing without slowing things down. Now the differences become visible:

• What is improving

• What is getting worse

• What still needs attention

The signal brings those tradeoffs into view so the team can move forward.

Decide What Moves Forward

With that clarity, the decision becomes easier to make. The team can move forward with a shared understanding of what they’re seeing. That might mean:

• Choosing one direction

• Refining what’s there

• Stopping something that isn’t working

The signal gives the team a shared way to decide. Instead of circling the decision, the team can commit and move.

---

Make Decisions Hold

The moment the work moves forward, the decision starts to meander. New people get involved. Details change. Constraints show up. Questions come back. What felt clear in the moment can start to shift as the work moves across teams.

The signal is what helps the decision hold.

Keep it visible as the work continues. Not as documentation, but as a shared reference for why the decision was made. When questions come up, bring it back:

• What was the team trying to understand?

• What did the signal show?

• What direction did that lead to?

This keeps the team aligned without having to rework the same decision from the beginning. As the work evolves, the signal continues to guide what happens next.

It helps you:

• Decide what to refine

• Identify where another signal is needed

• Build on what’s already been learned

This creates continuity instead of reset.

What This Looks Like Over Time

As this loop repeats, the work starts to feel different. Decisions land faster. Conversations stay focused. The team builds on what’s already been learned instead of starting over.

Over time:

• Decisions carry across teams

• Fewer conversations restart from scratch

• Signals connect across decisions

• Direction holds as the work moves forward

You don’t need to apply this everywhere at once. Start with one decision. Run the loop. Then repeat it where it matters.