The tool watched a company's servers and reported what needed fixing, 30 to 50 findings per machine. For an admin managing hundreds of machines, every morning began with triage paralysis. Many of the findings were obviously related, but the screen insisted on treating them as fifty separate problems.
Change the unit of work. Pathways group related findings into one actionable plan, so instead of "30 problems on this machine," the admin sees "5 plans that, applied, fix 22 of the 30."
Research and discovery
The users are the people who keep a company's servers healthy, measured on how many machines stay safe and up to date, not on how much reading they get through in a week.
Early concepts tried to rank or filter the recommendations more intelligently, higher severity first, more impactful first. The real breakthrough came when we realised the problem wasn't the ranking at all. It was the unit.
A pathway isn't a better-sorted recommendation. It's a different kind of object entirely, one organized around the action, not the analysis.
One running example carried the whole design: a case where the tool reported several findings that were all symptoms of the same underlying setting. Each finding was individually correct; together they were overwhelming, and one plan fixed all of them. Walking that example through with engineers and product managers made the value of grouping concrete in a way no diagram ever quite had.
Key UX moves
1The aggregation model: theme and shared remediation
A pathway groups recommendations by common theme and by the steps you'd take to fix them. Not just "related issues", issues that genuinely share the action to resolve them. That distinction is what makes the unit of work executable instead of merely analytic. You can act on a pathway. You can't really act on "a group of related things."
2The four-fact pathway card
Every pathway surfaces four facts, in this order: what to do, whether machines will need restarting, how many machines benefit, and which findings it covers. That's what an admin actually needs to decide whether to act, no more, no less. Anything extra would have quietly buried the action.
3The restart warning up front
"Requires a restart" is one of the heaviest pieces of information in this work, restarting a company server means picking a time, warning people, planning a window. Fixing something without a restart is a Tuesday-afternoon decision; fixing something with one is a scheduled event. So the restart flag went on the card itself, not three clicks deep.
4Borrowing trust instead of rebuilding it
Pathways use the same detection engine as the original tool, not a different signal, just a different organisation of it. Admins didn't have to re-decide whether to trust the findings; the plans inherited the credibility the tool had already earned.
Challenges
1From "smart sorting" to "a different unit of work"
We spent weeks exploring ways to rank or filter the recommendations better. The reframe, that the problem wasn't the ranking, it was the unit, collapsed a stack of dead-end concepts into a clear direction. Naming the conceptual shift out loud with engineering and PMs let everyone redirect their efforts together.
High fidelity walkthrough
Pathways shipped to production and has stayed there ever since, now as part of Red Hat Lightspeed. The feature is live in Red Hat's customer console, and Red Hat published the announcement, the documentation and a customer-portal explainer.
Final takeaways
- The smallest UX move can quietly be the most powerful one: change the unit of work. Aggregation as a design move.
- For an action-oriented user, the call to action and the operational constraint, reboot? maintenance window?, belong on the very first surface they see, not three clicks in.
- Don't try to be smarter than the underlying analysis. Pathways inherit Advisor's credibility precisely because they reuse the same detection rather than competing with it.
- What I'd push harder for next time: three sibling tools had the same overload problem, long lists of small findings. Designing the grouping pattern once, together, would have shipped faster than each tool discovering it on its own.
How this connects to Remediation
Pathways and Remediation are really two halves of the same workflow. Pathways handle the aggregation, Remediation handles the execution. The Red Hat blog puts it neatly: "Pathways naturally support the common remediation process within Insights, so you're always just a click away from a healthier data center."
Public proof and customer evidence
Live in production. Customer Portal explainer → · Pathways documentation →
From PeerSpot reviews of Red Hat Lightspeed (formerly Insights, which Pathways organizes):
"I've used Red Hat Insights primarily for its proactive issue detection, which helps maintain stability."
Enterprise System Architect · 4.5/5 on PeerSpot
One critical review captures the exact gap Pathways was designed to close: "If you come from an enterprise, you cannot just remediate, you need to have a change and everything in place." The combination of Pathways (aggregation) and Remediation (plans, scheduling, change control) is meant to meet that need head-on. (Source)