CASE STUDY · IBM MLz
COMPANY
IBM
ROLE
UX Designer
TIMEFRAME
April 2025 – September 2025
TOOLS
Figma
The Service Hosts & Services management area within Machine Learning for IBM z/OS.
Project overview
Machine Learning for IBM z/OS (MLz) needed a way for z/OS system administrators and system programmers to set up and manage the environments used to run services such as Trust AI, ONNX, and PCIe accelerator services.
These users work with technical infrastructure every day—hosts, ports, system resources, service health, and dependencies. The challenge wasn’t to hide that complexity, but to organize it into an experience that made the relationships between those pieces easier to understand and manage.
This was a new area of MLz without an established interface to build from. My challenge was turning the underlying infrastructure model into a workflow administrators could follow—from registering a Service Host, to creating and configuring a Service, to understanding what was happening after it was running.
My role
I was the primary UX designer for Service Hosts & Services, designing most of the experience from early concepts through development handoff and implementation support.
I worked with design lead Julia Bulgannawar, designers Alexis Landis and Olivia Gardella, and content designer Kelly Xiang. I also collaborated closely with developers Qin Liu, Thanmai Boddoju, and Jim Owens as we translated technical requirements and system behavior into the product experience.
Establishing the relationship between hosts and services
Before an administrator could create a Service, MLz first needed an environment where that Service could run.
That relationship became the foundation of the experience: set up a Service Host first, then create and manage Services associated with it.
I brought both into the same management area so administrators could understand and manage that relationship in one place. In the empty state, Add service host is available while Create service remains unavailable, making the required setup order visible from the beginning.
Empty state → populated state. Two product conditions within the same host-first management model.
Registering the infrastructure first
Adding a Service Host meant giving MLz the information it needed about the environment where Services would run.
Administrators needed to provide details such as the host type, IP address or hostname, SSH port, CPC name, and LPAR name. I kept that setup focused in a single form so they could register the infrastructure and move directly into Service creation.
The experience also needed to handle problems administrators could encounter along the way, including duplicate names, duplicate IP addresses, and invalid ports. Inline feedback identified the affected fields, while a broader message made it clear when multiple entries needed attention.
Service Host registration and validation keep infrastructure setup focused while identifying fields that need attention.
Turning Service creation into a guided flow
Creating a Service introduced another layer of complexity.
Administrators needed to choose what they were creating, associate it with the right infrastructure, configure the resources that Service required, and verify the setup before creation.
I organized that work into three steps:
Service details → Service resources → Summary
The goal was to give administrators a predictable path through setup without pretending every Service worked the same way. The overall structure stayed familiar while the configuration inside it could adapt to the Service being created.
Service details → Service resources → Summary.
One workflow, different technical requirements
Keeping the workflow consistent didn’t mean forcing every Service into the same configuration.
For Trust AI and ONNX, an administrator selected one Service Host. PCIe accelerator Services could be associated with multiple Service Hosts.
That difference carried into the resource step. Rather than creating separate workflows for each Service type, I kept the same three-step structure while allowing the configuration inside it to adapt to the technical requirements of the Service being created.
TRUST AI / ONNX
01 · SELECT SERVICE HOST
02 · CONFIGURE PORT
Trust AI and ONNX use a single-host path. The administrator selects one Service Host, so the resource step only needs to expose the port configuration for that selected Host.
PCIE
01 · SELECT SERVICE HOSTS
02 · CONFIGURE HOST RESOURCES
PCIe supports multiple Service Hosts. Each selected Host carries into the resource step with its own port range and PCIe-card allocation.
Accounting for real infrastructure constraints
Some of the harder UX problems appeared when the interface needed to reflect constraints coming directly from the system.
PCIe configuration was a good example. Administrators weren’t simply choosing preferences—they were allocating available hardware and ports across the Service Hosts they selected.
The interface showed the available PCIe cards for each Host and let administrators assign the required port range and card count. It also needed to explain when a configuration wasn’t possible, such as when all available PCIe cards were already in use.
These weren’t generic form errors. They represented real infrastructure conditions, so the experience needed to surface the problem where the administrator could understand it and respond.
PCIe resource allocation and a system constraint when available cards are already in use.
Making system state understandable
Setup was only part of the administrator’s job. Once a Service existed, they also needed to understand what it was doing.
A Service could be created but not yet initialized, actively loading, operating normally, paused, degraded, or in an error state. Simply showing that a Service existed wasn’t enough—the interface needed to communicate its current condition and help administrators recognize when something required attention.
This was an area where close collaboration with development and content design mattered.
Jim Owens and Thanmai helped clarify the technical behavior behind different system states. I translated that behavior into the interaction and status model, while Kelly Xiang and I worked through how those states should be communicated in the interface.
Together, we defined status indicators and contextual guidance for states including Created, Loading, Initiating, Active, Degraded, Error, and Paused.
The goal wasn’t just to change an icon or color. When something needed attention, the interface also gave administrators context about what was happening and where to go next.
Status guidance and degraded-state context help administrators understand when attention is required.
Managing a Service after setup
Administrators also needed a place to understand and operate a Service after it had been created.
I designed the Service details experience to bring together overall health, technical information, associated containers, and the actions available for those containers.
This gave administrators a way to move from the high-level health of a Service into the lower-level runtime state when something required attention.
Actions such as starting, restarting, or stopping a container also needed to reflect how the system actually behaved. Instead of implying that an operation completed immediately, the interface acknowledged when a request had been sent while the system continued processing it.
Service details and operational feedback connect health, runtime state, and container actions.
Preventing destructive mistakes
Service Hosts, Services, and Deployments weren’t isolated objects. Administrators could be working with one resource while other parts of MLz still depended on it.
That became especially important around deletion.
A Service Host couldn’t be deleted while Services were still associated with it. Likewise, a Service couldn’t be deleted while an active Deployment depended on it.
Instead of letting administrators attempt those actions without understanding why they couldn’t continue, I designed blocking states that explained what was preventing the deletion and what needed to be resolved first. When an active Deployment was the blocker, the experience could direct them to the affected area.
This made the underlying dependencies visible at the moment an administrator actually needed to understand them.
Parallel dependency safeguards: associated Services block host deletion; an active Deployment blocks Service deletion.
Working through implementation
My involvement continued after the main flows were handed to development.
As implementation progressed, I worked particularly closely with Thanmai to answer UX questions and work through scenarios that became clearer once the experience was being built.
That collaboration was an important part of the project. Development helped me understand how the system actually behaved, content design helped make that behavior understandable, and I used those inputs to shape the interaction model.
Service Hosts & Services ultimately became part of the MLz product experience.
What I took away
This project reinforced something I’ve learned from designing highly technical products at IBM: the hardest part often comes before drawing the interface.
Learning a new domain can feel like drinking from a firehose. Service Hosts & Services required me to understand unfamiliar infrastructure, dependencies, system states, and technical constraints well enough to make decisions about what administrators actually needed to know.
The goal wasn’t to remove complexity just because it was technical. It was to understand what users needed to know, when they needed to know it, and how much of the underlying system the interface needed to expose.
That became especially important as the Service types diverged. A consistent workflow gave administrators something familiar to follow, while the interface still needed enough flexibility to support the very different requirements of Trust AI, ONNX, and PCIe.
The project also reinforced how collaborative that process is. Developers helped me understand how the system behaved, content design helped turn that behavior into understandable language, and my role was to bring those pieces together into an experience administrators could actually work through.