Over the last week, we’ve been working to define how to make better design decisions. We’ve been using design signals for five years, and thought it needed to be better defined for Helio Glare.
Here’s my LinkedIn post:
I put together a rough slide deck that captures the main ideas. It needs refinement for sure, but it starts to pull these ideas together. A design signal is the unit of clarity in Glare.
I’d love your thoughts on the screens.
Can you elaborate on this @Bryan - Glare is the framework thats being applied here, in your example. UX Metrics are the quant piece and signals are the output?
It would seem to me that a design signal is the output that drives the process / project forward, and that would sit outside of Glare? Thanks!
I think one thing that will really help for new viewers is pulling the context out of the header bar, and into the left-hand copy for easier engagement through the deck. This is a great case-study though, and really highlights how to approach the testing with actual data!
Design signals are the outputs you create from synthesizing UX metrics. They are a core part of driving through the facets in Glare. They give you direction in your projects.
Signals cut through the Fog. The Fog makes busy look like progress.
Work continues. Meetings happen. Features launch. Yet progress slips away until nobody remembers why the idea mattered in the first place. The Fog hurts because it feels ordinary.
The Fog is not bad ideas. It is unclear decisions. And unclear decisions kill momentum.
When they’re stuck in the Fog, teams debate endlessly without evidence until hierarchy wins. They ship features no one notices or wants. They rely on late metrics that confirm the past but don’t guide the present. Or they hide behind dashboards, A/B tests, or opinions as substitutes for proof.
Signals are found through UX Metrics.
A UX metric is a simple number about user behavior, like how many people click a button, how long it takes to finish a task, or how many say the design was easy to use. On their own, these numbers are raw data.
A design signal is when those metrics are tied to a design choice, a user need, and a business goal. In that context, the metric becomes evidence that guides a decision.
When signals are combined with design intuition and business goals, they give teams clear direction. Signals are faster than waiting for long reports and stronger than relying on opinions. They keep good ideas alive and help teams move forward with confidence.
Agree with this Eric. The context in the header seems to be the biggest piece of orientation!
This is rad, thanks Bryan. “A design signal is when those metrics are tied to a design choice, a user need, and a business goal.”
Will this always be the case? Can a proper signal exist without one of these 3 things?
Ok, doing some iteration here on a design signal to help us frame the core unit in Glare.
I’ve modified the triangle (head nod to triangulation) and flipped the triangle to make it stable.
Some thoughts that come to mind to frame this moving forward:
I’ve found this illustration to be intuitive- “direction” being at the top shows how these lower items are “driving” where you’re going.
Very cool!
I agree with Ben, the direction as the result is quite intuitive and certainly represents the reality of the outcome very well. But intuition/hunch is represented as equal to the UX metric. What would happen if the metric was the thing tying the user needs, context, and goals together with the hunch? How would that look as a diagram?
I like how design intuition is on the same level as the UX metrics in this triangle framework, really drives home idea that this is a data-informed approach, not completely data-driven and dictated.
Regarding the deck on what is a signal, I can’t quite tell where the signal comes in. Feels like it moved directly from data to decisions without calling out exactly where the signals are in the middle.
