Pivotal Cloud Foundry

Product Design, Interaction


Pivotal helps companies deliver exceptional user experiences through adoption of platform, tools and methodology. In summer of 2018 I joined Pivotal Cloud Foundry, the cloud-native platform that enables Pivotal's customor companies to build stable, secure software quickly, efficiently, and at scale.

My Role

I worked on Apps Manager, the web interface product that developers and operators use to manage and monitor apps that are deployed on Cloud Foundry. My role was working directly with a product management intern to explore opportunities to improve Apps Manager through research-driven product strategy. I also completed interaction and visual design for these solutions.

The Problem

Pivotal Cloud Foundry is expanding at a rapid pace - and so are the companies who run on it. While Apps Manager features expand just in time with PCF's growth and customer needs, it's user experience wasn't ideal for companies at scale. Finding and managing apps in a foundations containing a hundred to a thousand apps became difficult for an interface that wasn't built for that much volume, so our challenge was to create a solution to help users navigate their foundation so that they can find the apps they need.

Apps Manager Information Architecture Defined

Improving the information architecture of Apps Manager meant improving the experience of app developers and app operators going through their different workflows in the hierarchy of apps, spaces and orgs. Working on the navigation consisted of designing the UI components necessary to navigate these flows. Below is the original state of Apps Manager.

Discovering User Painpoints

We started off answering these important questions to understand this problem more:

How much of a pain-point is the information architecture of AM? How does navigation help or impede user flows? How can we optimize this for current users?

After speaking with teams working on related products, user proxies (like those in Field) and product management, we found that our users were split into two groups: app developers and app operators.

In interviews and intitial tests, we found some patterns in how users responded.

Converging Pain-points into Problem Statements

We then converged on insights and painpoints that were recurring throughout our interviews through affinity mapping. By doing this we were able to generate our main problem statements.

Diving deeper into our research we found a critical pattern: developers and operators had two distinct (and almost opposing) use-cases. Developers' main domain of influence was on the apps level, while operators spent most of their time on the higher hierarchies like foundation/org levels.

Solution Ideation

We jumped straight into brainstorming possible solutions to address the four problem statements we had isolated from before. During this process the product team got together a sketched out full solutions for each problem, without considering tech-feasbility. This was important to help generate ideas and inspiration for potential features and the scope of what could be possible (or not).

A New Problem Statement: Focusing on App Access

During our brainstorming we realized that an unsaid but equally important pain-point was being left out: developers spent a lot of time getting to their apps despite that being their main area of work. This was something we realized after going through our concepts in ideation, and so we added this to our problem statements.

Converging on Solutions with Goals

After brainstorming, there was a huge pool of ideas to consider. To narrow down what we would focus on, we determined goals that we would use as metrics of effectiveness/success of a solution concept (listed from top to bottom, in order of importance).

Wireframing Concepts

After trying several combinations, I took the concepts to wireframes to scope out interactions/components in higher detail. I iterated several times in wireframes as well, and this eventually led me from a flow similar to our current I.A. with additional features to a more app-centric, functional navigation and globally accessible version of Apps Manager.

When we got to the point where we were comfortable with this wireframe, we moved on to make and test and higher fidelity prototype.

The Solution

Make Apps Manager app-centric

Developers primarily use Apps Manager at the apps level of hierarchy because many of their primary functions (like binding apps to service instances, or like trouble shooting) takes place at the app level. We optimized for these workflows through the Recent Apps and Apps Overview features.

Hierarchy navigation as a complete, separate experience

Due to the sheer size of foundations, it became apprent that we should be focusing on navigation as it's own experience instead of a add-on to the current layout. Using a side navigation flyout gives users a quick way to access a full list of spaces and orgs, along with navigation tools to help find specific ones.

Create access to a higher-level hierarchy: the foundation

App operators, who tend to take admin roles, need higher level perspectives to manage entire foundations, user permissions, storage, services and more. Creating access to a foundation level through a Foundation Page furthers this access, and is in sync with the overall product direction for Cloud Foundry.

Other Solutions

There were also smaller changes added to improve the navigation experience.

Refining Features and Components

By using user testing as a baseline, we learned that some components needed to be rethought to become more usable in our current solution. For example, the search bar which was originally only for apps now searched globally, so in the new solution it had to be optimized for different types of results.

Rethinking Apps Overview

A major feature we learned wasn't so effective during testing was Apps Overview. We did a design sprint with the whole team to re-examine it's purpose, and what information to display to make it more useful for customers.

Final Designs

After testing we refined the designs further, and combined all of the components together.

Measuring Success

We revisited our initial goals and problem statements and determined if each new feature solved them or not. While no one solution completely scored perfectly, a combination of all of them created a well-rounded solution.

Areas of Improvement

Apps Overview still has some points that could use improvement. It's up to more iteration to determine how this can feel more like an overview and less like a list of random apps.

More to Learn

More Insight on Customer Usage

We got a lot of our research from anecdotal, qualitative data from internal developers, new and existing user proxies and broad metrics on user interactions. We can validate this new implementation of the information architecture of Apps Manager even further by getting direct user input and in-depth quantitative dataon the platform to see what these findings look like at scale and to validate our research. Having more data would allows for us to have greater confidence and narrow down our solutions even further.

The Future of Apps Manager

What are the workflows we can optimize for as the functionalities continue to grow? Will A.M. continue to remain user-type ambiguous (operator + dev) product? Will those functionalities split in the future?

Will Apps Manager be Multi-foundation?

The scope of this project didn’t go into depth to include a multi-foundation app monitoring experience, though now we see that becoming a huge factor for where Apps manager goes in the future.

More Projects