Insights Advisor was surfacing 30 to 50 distinct recommendations per system. For a sysadmin managing hundreds of systems at once, that turned every morning into triage paralysis. Many of those recommendations were obviously related, but the UI insisted on treating them as N separate problems.
Change the unit of work. Pathways group related recommendations into a single actionable plan, so instead of "30 recommendations on this system," the user sees "5 pathways that, applied, resolve 22 of those 30."
Research and discovery
The users here are sysadmins running RHEL fleets at scale — people who are measured on how many systems they keep compliant and patched, not on how many recommendations they read 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.
The running example throughout the design work was kernel boot options — a case where Advisor often surfaces several related recommendations that are individually correct but overwhelming when you see them all at once. Walking through it with engineering and PMs made the value of aggregation 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: the call to action, whether a reboot is required, how many systems will benefit and which individual recommendations it covers. That's what a sysadmin actually needs to decide whether to act — no more, no less. Anything extra would have quietly buried the action.
3The reboot signal up front
"Requires a reboot" is one of the highest-impact pieces of information in sysadmin work. It changes when remediation runs, who has to be told and how the maintenance window gets scheduled. Putting it on the pathway card was a deliberate move — applying without a reboot is a fundamentally different operational decision than applying with one.
4Preserving Advisor's analytic accuracy
Pathways use the same detection technology as Advisor itself. They're not a different signal, just a different organisation of the same one. Sysadmins didn't have to re-evaluate whether to trust the underlying recommendations — pathways simply inherited Advisor's existing credibility.
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 inside Insights Advisor and have stayed there ever since, now as part of Red Hat Lightspeed. The feature is live in the Hybrid Cloud 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: a cross-capability model from the start. Vulnerability, Patch and Compliance each had similar atomic-item-overload problems. Doing Pathways for Advisor first and then deriving a unified pattern across Insights would have shipped earlier as one design system, rather than emerging case by case.
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)