team
PM, 5 Devs
Platform
Enterprise B2B
TL;DR
Making complex configuration behaviour understandable by surfacing distribution activity, profile relationships, and precedence rules directly within the workflow.
Background
Message Queue configurations controlled how messages were distributed and managed across environments.
Problem
The system knew how configurations would behave, but users often couldn't easily understand those outcomes.
Aprroach
Conducted domain discovery with architects and engineers , mapped decision paths, reviewed workflows, and introduced visibility into distribution activity and precedence behaviour.
outcome
Reduced reliance on tribal knowledge and made configuration outcomes easier to understand.
Impact
BEFORE: Configuration behaviour was hidden behind system logic and difficult to understand.
AFTER: Configuration behaviour became visible directly within the workflow.
01 CONTEXT
Understanding Ironstream
Ironstream helps organizations collect and route operational data from IBM i environments using a set of configurable profiles.
These profiles determine what data gets collected, how it is processed, and where it is ultimately distributed.
Where Message Queues Fit
Message Queue is one of several configuration profiles within Ironstream, alongside Message Queue Filters, QHST Filters, Job Log Forwarding, and Journal Monitoring.
It allows administrators to define how message-based events should be collected and distributed across the platform.
As the platform evolved, administrators began managing configurations across both individual Sources and Source Groups. This made configuration management increasingly interconnected and reinforced the need to understand how different parts of the system worked together.
02 PROBLEM
Understanding outcomes wasn't always straightforward
The Message Queue workflow was designed at a time when administrators primarily managed configurations at the Source level.
As Source Groups were introduced, administrators gained more flexibility in how configurations could be organized and distributed. In turn, configuration relationships became more interconnected and increasingly important to understand.
A single source could belong to multiple source groups, while multiple configurations could target overlapping sets of sources. Although the system handled these scenarios correctly, understanding the outcome of those relationships was not always straightforward.
message queue a
source group X
source 1
source 2
message queue B
source group Y
source 2
source 3
Which configuration takes effect?
As administrators worked through the workflow, they often needed answers to questions such as:
• Which configuration currently applies to a source?
• Which distribution ran most recently?
• What happens when configurations overlap?
• Which configuration takes precedence?
The information existed within the system, but it was spread across different areas of the product and disconnected from the moments when decisions were being made.
As a result, understanding configuration outcomes often depended on prior experience, documentation, or support from subject matter experts.
The challenge wasn't to change how the system worked. It was to make the reasoning behind its behavior easier to understand.
03 DISCOVERY
The Questions That Led the Discovery
Before exploring solutions, I needed to understand how Message Queues fit within the broader configuration ecosystem.
To do that, I worked closely with architects and engineers to unpack how configurations moved through the system. As I mapped the workflow, a series of questions began to emerge.
How do source groups affect profiles?
What happens when configurations overlap?
Which configuration takes precedence?
How can users verify the final outcome?
As I dug deeper, I realized the challenge wasn't creating configurations—it was understanding their outcomes. The answers often depended on relationships and rules that weren't immediately visible.
Key Insights
Defining the Opportunity
The opportunity wasn't to add new functionality. It was to make existing relationships, decisions, and outcomes easier to understand.
These insights became the foundation for the design strategy.
04 STRATEGY
Designing for Clarity
Discovery revealed that users weren't struggling to create configurations—they were struggling to understand their impact.
Because this work was part of a broader migration effort, the underlying business logic and distribution behavior needed to remain unchanged. Rather than redesigning how the system worked, the focus shifted to making it easier to understand.
These insights shaped three design principles.
CONNECT THE DOTS
Help users understand how configurations work together.
REDUCE GUESSWORK
Surface the context needed to make informed decisions.
SHOW WHAT HAPPENS NEXT
Make distribution outcomes easier to understand.
BUILD FOR WHAT'S NEXT
Create patterns that scale across future migrations.
05 SOLUTION
Turning Complexity Into Clarity
The strategy focused on making relationships, decisions, and outcomes easier to understand without changing the underlying system behavior.
Connect the Dots
One of the biggest challenges was understanding how overlapping configurations affected the final outcome. While the system correctly resolved conflicts, the reasoning behind those decisions wasn't always visible.
To address this, I introduced a Distribution Precedence Table that clearly explains how the system evaluates overlapping configurations and determines which one takes effect.
By making precedence rules visible, administrators could better understand how configurations interacted and predict outcomes with greater confidence.
Reduce Guesswork
Understanding precedence was only part of the challenge. Users also needed visibility into potential conflicts before distributing changes.
To support this, I introduced guidance for overlapping sources and source groups directly within the workflow, helping users identify conflicts earlier and understand their impact before taking action.
This shifted conflict resolution from a reactive process to a proactive one.
Show What Happens Next
Distribution was a critical workflow, yet visibility into distribution activity was limited.
To provide a clearer view of system activity, I designed a centralized Distribution Table that surfaces what was distributed, when it was distributed, and its current status.
This transformed distribution tracking from a fragmented process into a single, centralized experience.
Build for What's Next
As part of the migration effort, the Message Queue experience was redesigned using the platform's design system and reusable interaction patterns.
Before
After
These patterns improved consistency across the product while establishing a foundation for future profile migrations.
06 OUTCOME
BETTER VISIBILITY, BETTER DECISIONS
The project focused on a simple challenge:
helping administrators better understand how configuration decisions affect outcomes.
Rather than introducing new functionality, the redesign surfaced critical context, improved visibility into distribution activity, and made system behavior easier to understand.
PRODUCT IMPACT
Greater visibility into configuration outcomes
Clearer understanding of precedence and overlap scenarios
Reduced reliance on institutional knowledge
More transparent distribution workflows
platform IMPACT
Established reusable patterns for future profile migrations
Created a consistent foundation for future modernization efforts
Aligned Message Queue with the new design system
Provided a scalable approach for managing complex configurations
The redesign wasn't about changing how configurations worked. It was about making the relationships, decisions, and outcomes behind them easier to understand.
07 REFLECTION
The biggest lesson from this project was that visibility can be just as important as functionality.
UNDERSTANDING THE SYSTEM COMES FIRST
Before exploring solutions, I had to understand how the system made decisions.
Mapping relationships, dependencies, and precedence rules revealed that the challenge wasn't missing functionality—it was helping users understand behavior that already existed.
COMPLEXITY ISN'T ALWAYS THE PROBLEM
Enterprise systems often need to support complex business rules. The challenge is making that complexity understandable without requiring users to become experts.
This project showed how surfacing relationships, decisions, and outcomes can improve confidence without changing the underlying system.
