‍

Private Paths introduce a new way for customers to connect their third party applications with secure services hosted on IBM Cloud. By iterating through designs and conducting usability research, I led this project from idea to Beta. With industry experts and customers, we seamlessly integrated this new service into the existing Virtual Private Cloud service suite. You can view the live product here.

‍

Introduction

Duration: 10 Months | Beta: 2Q24 | GA: 4Q24 | Role: Product Design Lead

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.

‍

Defining our users

With the guidance of User Experience Researcher, Arthur Hayden, we recruited two groups of users to interview and formulate a hypothesis of how this project may work. Group A, comprised of those who plan their organization’s cloud infrastructure, mainly Network Architects and Senior Cloud Engineers. They streamline the usage of cloud services so their development teams can build applications for clients. Group B, DevOps and Site Reliability Engineers, manage and develop the output of Group A. They build the applications. From interviews with both groups, we were able to hypothesize these personas within their highly regulated industries:

The Consumers - Those who request to privately connect an application. (Healthcare Company)
The Providers - Those who receive and act on connection requests to their application. (Independent Service Provider)
Both Groups A and B represent Consumers and Providers personas, though Consumers and Providers represent companies.

‍

Defining the journey

We included in house Systems Engineers in these conversations, cross referencing our findings with their proposed architecture and making edits to align with Consumer and Provider needs a long the way. The final user journey entails four steps.

Step 1: Providers log into IBM Cloud and, within their existing Virtual Private Cloud (VPC), create a new Network Load Balancer (NLB) alongside a Private Path, connecting the two. Once the Path is deployed, the Provider sends its identification number to the Consumer, the company seeking access to the application hosted on the Provider’s VPC.

Step 2: Consumer create a Virtual Private Endpoint Gateway (VPE) on their own VPC using the identification number (CRN) provided by the Provider. This process automatically links the Consumer’s VPE to the Provider’s Path, creating a path for data exchange between the isolated environments.

Step 3: Providers decide whether to grant the Consumer access to the applications hosted on their VPC. This step is crucial for maintaining the highly secure environment needed by customers of highly regulated industries. Only authorized Consumers have a chance at gaining access.

Step 4: Consumers receive a notification alerting them of the Provider’s decision, completing the journey. This results in a successful connection, enabling the Consumer to access the application.

Providers and Consumers alike can manage and monitor these connections through the Cloud console UI or Command Line Interface, using tools we designed.

‍

Reviewing competitors

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.

‍

Medium fidelity wireframes and usability testing

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.

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.

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.

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.

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

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.

‍

High fidelity prototype and usability testing

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.

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.

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.

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%.

‍

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.

‍

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