Product Design Lead | 14 Months | 2023 | Live Product
Establishing secure cloud connections shouldn’t feel like navigating a maze. I led the design of Private Paths, redefining how customers connect external applications to secure services on IBM Cloud. Through iterative design, usability research, and deep collaboration with industry experts, I transformed a complex networking process into an integrated experience within IBM’s Virtual Private Cloud suite. From concept to launch, my work focused on removing friction, high security, and ensuring an intuitive solution that simplifies private connectivity for users in regulated industries.
The Right Path: Why External App Connections Needed a Fix
A healthcare company needs to use an independent service provider (ISP) to analyze and store their patient’s medical records. Typically, this is done over the public internet utilizing a virtual private network (VPN). However, exposing personal identifiers to the public internet introduces many issues for both the service consumer (healthcare company) and service provider (ISP).
If the data contained in patient’s medical records were leaked while traveling between the healthcare company and the ISP, both companies would risk their reputation, compromise patient confidentiality, and incur financial penalties as outlined in HIPAA regulations.

Like a doctor personally handing a patient’s sealed medical records directly to a specialist, IBM Cloud Private Path services offers a secure and private channel for third party applications to connect through IBM’s regulated services, eliminating any risk of unauthorized access or data breaches, and maintaining full compliance with HIPAA regulations.
Understanding our User's Handoff System
To better understand user needs and define a clear hypothesis, we recruited two groups for interviews. Group A, consisting of Network Architects and Senior Cloud Engineers, is responsible for designing and managing their organization’s cloud infrastructure. Their focus is on optimizing network security, compliance, and performance to enable seamless application development for internal teams. Group B, made up of DevOps and Site Reliability Engineers (SREs), builds and maintains these applications, ensuring they operate efficiently within cloud environments.

Through interviews with both groups, we identified two core personas within highly regulated industries that rely on secure private networking: The Consumers – Those who request private connections for their applications (a healthcare company securely connecting to a third-party provider). The Providers – Those who receive and manage these connection requests (an independent service provider offering cloud-based healthcare solutions). Both Consumers and Providers exist within Groups A and B, but at an organizational level, they represent distinct entities managing private cloud connectivity to ensure low latency, security, and compliance—the key value propositions of IBM Cloud Private Path.
Co-Creating Four Steps
To ensure our solution aligned with real world use cases, we worked closely with in-house Systems Engineers, refining our approach based on their expertise while continuously validating against Consumer and Provider handoff systems. Through this collaboration, we defined a clear, four-step user journey that ensures secure, controlled, and efficient external application connectivity within IBM Cloud.

Step 1 - Establishing the Private Path: Providers log into IBM Cloud and, within their existing Virtual Private Cloud (VPC), create a Network Load Balancer (NLB) alongside a Private Path, linking the two. Once deployed, the Provider shares its identification number (CRN) with the Consumer—the organization requesting access to their application. Step 2 - Creating a Secure Gateway: The Consumer, operating within their own VPC, uses the CRN to create a Virtual Private Endpoint Gateway (VPE). This action automatically establishes a secure, private link between the two isolated environments, enabling controlled data exchange far away from the public internet. Step 3 - Access Control & Authorization: At this stage, the Provider evaluates and approves or denies the Consumer’s request to access applications within their VPC. Step 4 - Secure Connection & Monitoring: Once the Provider makes a decision, the Consumer receives a notification confirming the status of their request. A successful authorization results in a fully operational, private connection, allowing the Consumer to finally interact with the Provider’s cloud-hosted application.
.png)
The Multi-Tab Maze of AWS and Azure
Our competitive analysis revealed that achieving this level of private connectivity on Amazon Web Services (AWS) and Microsoft Azure requires a more intricate setup than anticipated. Establishing a connection between services often requires users to navigate away from their initial configuration (mainly when creating a Load Balancer). This disjointed process forces users to cross-reference information between tabs or windows, complicating what is already a complicated experience.

In this, we saw an opportunity to design a process where users can create all necessary resources (Load Balancer with Private Path) without leaving their in progress configuration. This integration may prevent users from abandoning their setups, leading to one less purchase.
AWS and Azure also mandate a manual process for accepting or rejecting each connection request, which can be time-consuming when handling multiple requests from the same Consumer company. To address this, we introduced automation via automatic acceptance of rejection of recognized account IDs.
Drafting the Foundation: Mid-Fidelity
With a clear understanding of the problem and the target audience, we moved forward with prototyping. Collaborating closely with fellow designer Michelle Yang, we developed several prototypes at medium fidelity. These prototypes were reviewed by our engineering teams, then tested by 10 external users via UserZoom (mainly Network Administrators, IT Managers, and DevOps Engineers) split between Provider and Consumer personas.
.png)
In the first phase, we designed a page for Providers to set up and purchase their Private Path. Once purchased, Providers could view all Paths within their VPC. This task was found easy to navigate and complete by 100% of participants.
.png)
Creating a Network Load Balancer specific to Private Paths typically requires over 20 individual steps. To simplify this, we pre-filled as much account and VPC information as possible, reducing the process to four main sections, followed by a final review page. This streamlined approach enabled all participants to successfully provision a Private Path Network Load Balancer alongside their Private Path Service.
.png)
Once the Private Paths and Load Balancers are created, the Provider sends the CRN, to the Consumer offline. On the Virtual Private Endpoint gateway creation page, the Consumer enters this CRN to initiate the connection. 90% of participants found the preview component effective in explaining the connection request process, and 87% percent were confident that their CRN was successfully verified.
.png)
Finally, the Provider can log into their Private Path and accept or reject the Consumer's connection request. The interface made it easy to view pending connection requests and act on them through notifications, with 100% of participants finding this task straightforward and easy to complete. “All of the information I expected was included” — Provider 3
.png)
Now that the connection has been initiated, the Consumer can now securely interface with the Provider’s application. We designed this to make insights into the connection progress as visible as possible. 100% of participants were able to successfully view and confidently understand their connection request status.
Building the Path: High-Fidelity
Building on the feedback from our initial usability tests, we conducted a workshop with over 20 design and product management participants to introduce new features. Using IBM’s Carbon Design System, we developed a high-fidelity prototype that addressed previous usability issues.

We received and acted on a lot of visual design feedback and explored possible integrations with services we hadn’t initially considered, such as Direct Link and Access Management. These services have been used as private connectivity workarounds by many of our customers. After completing the prototype, we shared it with seven private connectivity subject matter experts at IBM’s 2022 TechXChange Conference in Las Vegas. Here, we introduced our concepts, recruited beta testers, and conducted moderated usability testing sessions on the spot.
.png)
As a result of our design and product management workshops, we introduced the concept of publishing a Private Path, with services created by default remaining in an unpublished state. This allows providers to fine-tune the settings of their Path and Load Balancer, test them out, and verify their success with applications before allowing external Consumers to connect to their Path. Think of it like a draft Path before it’s published and available for the public.
This feature earned a usability of 76/100 when participants were asked to rate how difficult they expected this task to be. However, after completing the task the score reduced to 64/100, meaning this was more difficult than participants had expected. This is supported by the Beta feedback noted below. This new feature was also rated as a 60/100 task completion confidence score, lower than we had anticipated.
.png)
Another feature introduced was automating connections, inspired by a design opportunity from our competitive analysis. This feature automates connection requests from specific accounts or repeat account connections. While Providers are creating their Private Path, they have the option to add an automation policy that will automatically accept or deny connections for specific accounts. Participants anticipated this task to be slightly difficult, giving it a 61/100 confidence rating. After completing the task, their rating increased to 73/100, indicating it was easier than expected with room for improvement. We were pleased to see a task completion confidence rating of 82/100.
.png)
In the final step, following the Consumer’s connection request to this Private Path, Providers are able to accept or deny the connection request. This task is straightforward, and users consistently rated it with a perfect ease of use score of 100/100. Our final task completion rate improved from an average of 7 minutes and 52 seconds to an average of 3 minutes and 37 seconds, an improvement of 54.02%.
Walking the Path: Beta Feedback
Post-release, we gathered feedback from select Network Engineers and Architects. They noted difficulties in creating a Private Path specific Load Balancer from the dedicated Load Balancer configuration pages, as the only way to create a functioning Private Path specific Load Balancer was from the Private Path configuration pages. Users also expressed uncertainty about the publishing mechanism, suggesting the need for a more intuitive process. They also recommended the introduction of an account ID validator to provide sufficient information for Providers to determine whether a Consumer should be granted access. These insights are crucial for refining the experience and enhancing its security.
Paving the Way: Reflections
This project changed hands quite frequently. There were numerous occasions where I found myself onboarding new Product Managers and Content Designers. Detailed documentation of the service functions, design progress, and user feedback was crucial to their, and the projects success. Without this documentation, we would have faced the risk of starting over from scratch with the introduction of new priorities. Documenting every step ensured continuity and clarity, allowing me to help a new team member to get up to speed quickly and keep the project moving forward.
Throughout the project’s extensive journey, we were able to present it to over 50 users and more than 50 internal engineers, designers, and executives before its public release. Each presentation provided valuable opportunities for feedback, allowing us to refine and improve the service. With every iteration, Private Path services became more robust and streamlined. I’m quite proud of this work, and will continue to iterate as it becomes available for all customers this fall.
Team Feedback
“It has been a pleasure working with Eli over the last few years. His contributions to the products have made the usability and experience for them tremendously better.
Two characteristics I would like to highlight are Eli’s knowledge of the product and the end-user consuming the product. It is always apparent in the designs Eli works on or the design sessions we have, that he fundamentally understands the purpose of the Networking products in the greater context of IBM Cloud. He understands why it is needed, why one service would be used over another, and the various deployment scenarios customers would choose.
Second, Eli has demonstrated a clear and comprehensive understanding of our target end-users and incorporated that knowledge into his designs. We spent several weeks on the Private Paths design, which is fundamentally different from the typical Networking user…focusing on ISVs publishing a service on IBM Cloud. His fundamental understanding of the ISV user helped developed an intuitive design that should be submitted to design competitions.
Overall Eli is a true asset to the design team and his contributions make IBM Cloud better.”
Ahmed Osman — Global Product Manager, IBM Cloud Network Services