Company IBM Bluemix (Now IBM Cloud)
Timeline 2017
My Role UX Designer (Project Lead)
Collaborators Christine Tsai
Background
Bluemix was IBM’s Cloud Platform for Developers before rebranding to IBM Cloud.
Similar to how grocery stores and malls sell food and products across multiple verticals, Bluemix offers developers a wide variety of Cloud Services; from databases to AI to hosting services.
At the time of this project, Bluemix offered over 130 unique services to developers, each owned by a Service Provider.
To take our analogy a step further, Service Providers on Bluemix behave a lot like stores in a mall. Similar to how the goods and interiors vary from store to store in a mall, Service Providers each have their own space within the Bluemix UI where users can engage with their services.
The problem
At the time, the Bluemix Design System did not offer Service Providers consistent guidance around how to handle navigation within their area of the Bluemix UI.
The lack of navigation pattern guidance caused Service Providers to design and implement their own “local” (secondary) navigation patterns; each slightly different from one another.
This ultimately resulted in a fractured experience for our users; leaving them confused and disoriented as they attempted to navigate between the different services they were using.
The diagram above shows how 5 separate Service Providers opted to tackle local navigation within their product area.
Service Providers were designing and implementing similar navigation patterns in different ways.
Hypothesis
Offering Service Providers a consistent local navigation pattern that works for all their needs will make navigating the platform easier for users and significantly reduce the amount of inconsistencies in our product
Project goals
- Design a consistent "local" (secondary) navigation pattern that works for service providers building their UI in Bluemix.
- Capture the local navigation pattern and usage guidelines into the Bluemix Design Guide
Working with Service Providers
Since functionality can vary drastically from service to service, I started my research by meeting with 12 different Service Providers to better understand their needs.
Here’s what I found...
Side Navigation
Many Service Providers designed a side navigation pattern to solve for the constraints of the recommended horizontal navigation pattern.
Side navigation example.
Iconography
A few Service Providers explored using iconography as a way to maximize screen real estate.
Icon usage example.
Tiered navigation
Many services required more than one tier (level) of navigation. Some services seeking to maximize screen real estate for productive use explored a navigation pattern that could expand and collapse.
Multi-tiered navigation.
Sketches and iterations
I created many iterations of a possible local navigation pattern. I worked with Service Providers to narrow down two distinct local navigation options.
The 12 teams we worked with unanimously supported Option B: Side Navigation - No Tabs (vertical side nav only).
What’s gained (Pros)
- Persistent navigation aids in orientation & context setting
- Supports greater granularity of topics compared to horizontal navigation patterns
- Content can be organized in a way that makes the most sense for a specific service
- Service providers can accommodate for a breadth of content & productive use
We moved forward testing Option B: Side Navigation - No Tabs to see how it performed with our users.
User testing
I worked with the Containers team (an internal Service Provider) to adapt their service into an Invision prototype that utilized our new navigation design (Option B). We were able to easily map the Service Provider’s content to the proposed pattern.
We identified 5 users of the Container service (engineers) to test the new navigation pattern.
Participants in the user test were asked to compare the flow of getting a Container (a service we offer) up and running using the current UI versus our proposed side navigation pattern.
Results confirmed
- Current navigation is inconsistent across the platform resulting in a quick loss in context for our users. Using the existing navigation users often jumped back and fourth between pages to remember where they were in the product.
- With our proposed design most users didn’t notice the navigation, we took this as a positive as it did not impede on their productive use.
- Local navigation acts as a point of reference and sets user context
- Users are not familiar with our iconography.
Feedback received from our user tests prompted us to continue moving forward with Option B: Side Navigation - No Tabs.
From the feedback we were able to prototype 3 refined versions of the pattern.
Refining the Pattern
A. Persistent Local Nav
Refinement A is a simple, persistent side navigation pattern where both Parent (Sub-category) & Child (Item) links are visible.
Context is most easily gained, but scrolling may be required if there is a large amount of content.
B. Expandable Local Nav
Refinement B allows the user to expand and collapse Sub-Category items. This results in less visual clutter but the user its provided with slightly less initial context.
C. Fly-out Navigation
Refinement C is invoked via a hamburger menu and slides out from the left.
This maximizes a user’s productive use space, but requires the user to click to invoke the nav.
The least amount of context is provided because Sub-Categories & Items are not immediately visible.
Finalizing the design
We reviewed the pros and cons of each of the 3 refined navigation patterns with our stakeholder Service Providers.
We opted to move forward with B. Expandable Local Nav because it provided enough context to end-users while also drastically reducing visual clutter.
Increasing visual fidelity
The final step in the design refinements was to adapt the pattern to the existing Bluemix Design Guide look and feel.
Final Expandable Local Nav pattern.
Codifying the design
After finalizing the local navigation pattern I took time to carefully author detailed usage guidelines.
Guidance captured in the Bluemix Design Guide, used by both developers and designers.
Then I collaborated with our developers to codify and incorporate the pattern into the Bluemix Design Guide.
Final outcomes
- The pattern was renamed from Expandable Local Nav to Interior Left Nav and made a requirement for all Service Providers.
- Within the first 6 months over 30 Service Providers had adopted the new navigation pattern, drastically reducing the amount of unique navigation patterns in our UI.
- Within the first 6 months ~30% decrease in negative NPS comments related to Navigating the platform.
- 4 years later the pattern has been tweaked and adopted to fit new use cases, but is 100% adopted by all Service Providers. It lives on in the IBM Cloud Carbon Design system.