ENTERPRISE CLOUD · IBM
IBM Private Path Services
Designing secure, scalable private cloud connectivity, while cutting task completion time in half.
ROLE
Design Lead
TOOLS
Figma, Adobe Illustrator
DURATION
10 months
PLATFORM
IBM Cloud Console
OVERVIEW
The problem worth solving
"Many companies are blocked from onboarding new customers because the security specifications that these big, prospective partners require present high barriers to entry. Using a cloud provider to facilitate private connectivity is a much more scalable solution and opens a lot of doors for customers."
Enterprise security is one of the most significant barriers to new customer acquisition in cloud services. Large enterprise partners often require strict private connectivity standards, standards that many businesses struggle to meet on their own, leaving them locked out of valuable partnerships and stalling growth.
IBM Private Path Services was built to solve this. The product provides a secure, cloud-native connectivity layer that allows applications to communicate privately, completely bypassing the public internet, using IBM Cloud's Network Load Balancer and Virtual Private Endpoint Gateways. In doing so, it removes the barriers that were preventing IBM's customers from onboarding high-value enterprise clients.
MY ROLE
How I entered the project
I joined this project as Design Lead at the mid-to-high fidelity stage, with a clear mandate: get the beta out the door. But rather than simply executing on what existed, I used that entry point strategically.
My first move was to run a thorough audit of the experience as it stood; stress-testing assumptions, reviewing flows through fresh eyes, and running early user sessions to validate what was working and what wasn't. That audit surfaced critical gaps and unaddressed user needs that had not been on the roadmap. Advocating for those additions, and getting alignment across product, engineering, and content design, became a defining part of my contribution.
USERS
Two users, one shared flow
Private Path operates on a provider/consumer model; two user types with distinct goals, interacting with the same underlying system from opposite ends.
Provider
Sets up and manages the private service. Configures the load balancer, publishes the service, and controls which consumer accounts get access. Primary concern: control, security, and operational efficiency.
Primary concern: control, security, and operational efficiency.
[ User diagram ]
Provider and consumer personas with their primary goals and pain points
Consumer
Requests access to the provider's service via their Cloud Resource Name. Needs visibility into request status to confidently move forward. Primary concern: clarity, trust, and confirmation that things worked.
Primary concern: clarity, trust, and confirmation that things worked.
RESEARCH
Where competitors were failing
A competitive analysis of AWS PrivateLink and Azure Private Link revealed two consistent pain points that became direct design targets.
Workflow fragmentation
Configuring a load balancer required navigating across multiple tabs, breaking user flow mid-task and forcing users to repeatedly re-orient themselves.
Manual approval at scale
Providers had to manually approve each connection request one by one. For enterprises managing dozens of partner connections, this was unsustainable.
DESIGN OPPORTUNITY
Both gaps pointed to the same principle: reduce cognitive load for technical users managing complex configurations — not by dumbing things down, but by making defaults smarter and automation more powerful.
[ Competitive audit ]
DESIGN DECISIONS
Automation policies
I proposed and designed a net-new feature: automation policies that let providers define rules to auto-approve or deny connection requests from specific account IDs, eliminating repetitive manual review at enterprise scale. Iterated through three rounds of testing:
61
Initial confidence score /100
70
After first iteration
82
After final iteration
Mid-fidelity design & usability testing
Provider setup flow
Providers begin by configuring and purchasing their Private Path service, then managing all active Paths within their VPC. The goal was to make this feel like a guided, progressive process, not an enterprise configuration nightmare.
100%
Of usability test participants found this task straightforward on the first attempt
[ Competitive audit ]
CRN verification & consumer connection
Once a Provider sets up their service, they share a Cloud Resource Name (CRN) with the Consumer to initiate the connection. This step had to feel trustworthy, as a wrong entry breaks the connection silently. I designed a real-time CRN preview component that gives consumers immediate confirmation of what their CRN resolves to, before committing.
90%
Found the CRN preview helpful
87%
Confident their CRN was verified correctly
[ Competitive audit ]
Connection request management
The Provider-side request management interface needed to handle a key edge case: what happens when a single enterprise client sends dozens of connection requests? The mid-fidelity design introduced a clear pending requests view with inline notifications, laying the groundwork for the automation policies feature built out at high fidelity.
100%
Found it easy to review and act on connection requests
100%
Successfully located and interpreted their request status
20+ steps → 4
Setting up a Network Load Balancer normally requires over 20 steps. By pre-populating fields with Private Path-appropriate defaults and eliminating tab switching, I compressed the setup to 4 essential inputs all within the same context. Every usability test participant completed it without error.
[ Competitive audit ]
Consumer Status Visibility
Once a Consumer submits a connection request, they need to know what's happening. Ambiguity here erodes trust in the product. I focused this part of the design on making connection progress unambiguous; clear state labels, status indicators, and contextual messaging at each stage.
100%
Successfully located and accurately interpreted their connection request status
High-fidelity design & key iterations
Moving into high fidelity, I focused on three areas: refining the automation capability, introducing a publish/unpublish model, and tightening the request management experience based on testing data.
Approve / deny — final request management
The final high-fidelity treatment of the approve/deny flow was the most refined part of the experience. The action was designed to be immediate, reversible, and completely unambiguous, both in terms of visual hierarchy and the language used.
Publish / unpublish model
I introduced a draft state for Private Path services, keeping them unpublished by default so providers could configure and test before enabling consumer access. Testing showed the feature initially decreased ease-of-use scores (76 → 60), a signal that the mental model was unfamiliar not that the concept was wrong. The right response was better onboarding, not removing the feature.
OUTCOMES
Results at beta launch
60%
Reduction in task completion time (8:52 → 3:30)
4.1/5
Overall experience rating at beta launch
82/100
Automation policy confidence score
100
Ease-of-use score for approve/deny action
The 60% reduction in task completion time was the cumulative effect of every friction point removed across the provider workflow, not a single design win. The overall rating of 4.1/5 reflects a product that shipped in a genuinely usable state, not one that just cleared an internal bar.
POST-LAUNCH
What comes next
After launch I ran feedback sessions with network engineers and architects. Three themes emerged consistently:
Publishing automation — Users wanted the publishing workflow to include automated validation of access rights — reducing the risk of misconfigured permissions before going live.
Load balancer setup — Despite the improvements made, the Load Balancer setup remained a point of friction for some users. Further streamlining and contextual help are on the roadmap.
ID validator — An ID validator feature was consistently requested; a mechanism to verify that only authorized accounts can gain access, providing an additional security assurance layer.
REFLECTIONS
What I'd take forward
Entering a project mid-stream is not an excuse for passive execution. The audit I ran in my first weeks directly shaped the product's most distinctive features; automation policies and the publish/unpublish model both emerged from that process, not the original roadmap.
Working alongside network engineers to translate highly technical infrastructure concepts into intuitive UI also deepened my appreciation for the role of language and progressive disclosure in enterprise products. Getting the terminology right, and deciding what to surface vs. abstract, often mattered as much as the visual design.