Private Access for Oracle Cloud Infrastructure is a service that enables users to connect from their private network to services running on OCI. As part of future Gartner requirements and general usability, Oracle needed a user interface to allow themselves and third-party providers to display and configure private endpoint-based access to consumers, and for consumers to browse and configure those endpoints.
Goal: The proposed solution was to create a product called Private Access with services geared toward two types of users, providers and consumers. A provider must be able to offer their services as an Endpoint Service, to which a consumer can register a Private Endpoint, that is routed through a Private Access Gateway.
Challenges: The main challenges for this project included: the user interface was unable to distinguish whether a user was a provider or consumer; how to organize the navigation structure; and how to guide users through the setup of necessary peripheral resources: Private Access Gateways and Endpoint Services.
Deliverables: stakeholder interviews, user journeys, UX design, prototyping, and testing.
My role in the project begins once the data model and API plan has been decided and I have met with the team to understand the requirements. My first challenge was to find the right balance between personas - provider or consumer of private endpoints. We needed the UI to guide a user toward whichever workflow suited them without being able to tell a user apart.
Further interviews were conducted with stakeholders and in-house engineers to gather technical requirements for workflows. For instance, the API and network architecture required that a Private Access Gateway must exist first in the workflow so that a provider may then use it to route traffic when they configure an Endpoint Service. Thus the user journey should consider directing a new user to a Private Access Gateway first before an Endpoint Service -- but it should not enforce it, in case this was a returning user that was only interested in maintenance, not creation.
Competitor analysis throughout the design process helped immensely in cementing our decisions. We compared Microsoft Azure, AWS PrivateLink, and Google Cloud for their presentation of the provider vs consumer problem. Where some buried the provider/consumer distinction late in the process, the team decided our later approach was more user friendly.
With the team I explored several IA possibilities, such as offering two separate services depending on providers or consumers, or combining both into one service that de-emphasized the Provider persona due to them consisting of far fewer users overall.
After deliberation it was settled that the three services (Private Endpoints, Private Access Gateways, and Endpoint Services) would become siblings bundled as a whole under the term Private Access, but a landing page would be used to divide the service depending on persona. Messaging and emphasis would be employed to direct a user to their needs. Once this was decided, I wireframed a definitive user journey using Figma.
Once the user journey was approved, I started high fidelity mockups. These are designed in Figma using the Oracle Cloud design system. While the generic templates and components are pre-existing, each step must be designed to reflect the final product, including accurate technical content if possible. This means building the forms, writing content drafts, and revealing sub-menus, tabs, edit panels, and the like.
Defining error and friction paths was critical to the project. As detailed above, it is possible that a provider attempt to create an Endpoint Service before an Access Gateway. The creation workflow addresses this by forcing the user to select an existing or create a new one within the same panel, and the edit workflow addresses this by checking behind the scenes if any Private Access Gateways exist when a panel to create an Endpoint service is opened. Messaging would guide the user on next steps if none exist.It was extremely important to highlight error paths in the designs, as a load balancer could be set up to fail. This is allowed in order to be fully flexible; guidance via tooltips and information blocks and at times, disabled states, was necessary to explain why actions were not recommended unless intentional.
Prototypes were created in Figma's prototyping mode, and fully linked up to simulate a working service. This included fully interactive sub menus, notifications, and even provisioning downtime. Interactions are also built in, such as the intended behavior for a panel to slide in from the right. Overall, over 50 screens were designed for this project, ranging from detail templates to deletion flows.
The review and revision process happened iteratively over the course of the entire project. Once the mockups were finalized and approved by the project team, they had to be presented to the review board to pass into development. This is when the workflows and patterns are compared to the design guidelines for consistency across the console. Once the work passes into development, I offer design support where needed. To track usage over time, I created a report in Adobe Analytics that uses tracking pixels to gauge visits and hits across different buttons and pages.
The main struggles with this project were with information architecture and the persona problem. We validated our IA decision with competitor analyses and will watch usage reports to gauge our success. Thus far I am satisfied with the decision to present all services to all users equally in the hierarchy, with use of a landing page to emphasize the use case that would apply to most visitors (the consumer persona). I believe our UI successfully guided a user while staying out of their way.
