Apps Manager: Designing Pivotal Cloud Foundry's (PCF) UI experience
Apps Manager (AM) is Pivotal Cloud Foundry's UI for enterprise app developers. Its vision: Make it easy and simple for app developers to deploy, manage, and monitor their apps in PCF.
For the 60+ customers using the UI today, Apps Manager was likely the first encounter their app developers had with PCF, and continues to be one of the main developer tools (other than the cf CLI) for monitoring and managing their apps.
What I Did
conducted 2 discovery research initiatives at customer sites
completed 11 UX research initiatives
designed 30+ shipped UI features
interviewed ~40 Apps Manager users
onboarded and paired with a college design intern
Case Study - Designing a polyhierarchal Apps Manager
Apps Manager was developed with one major assumption: a user only has apps in one foundation, because customers only need one foundation each.
Fast forward a handful of years, and Pivotal found out customers are regularly using multiple foundations (for security, locality, stability).
🗂️🗂️🗂️ It’s like if you had several Google Drives. To view or update a specific file that’s saved in multiple Drives, you’d have to log into each Google account to access the file in that Drive. 🗂️🗂️🗂️
For users who had apps in multiple (2-70) foundations, they'd have to log in and log back out of Apps Manager... Per. Foundation. 😱 And/or open up separate tab instances to see everything at once.
How might we…. give app developer and system administrators access to their apps across all the foundations they have access to?
Over the course of eight weeks, we designed a solution that:
introduced a new level of hierarchy (foundations) to Apps Manager
vastly improved the power and accuracy of search
has a new home experience
enables app developers to navigate quickly to their desired app, service, space, or org regardless of which foundation the object lives in
. . .
I paired with my team’s PM to compile various customer and stakeholder inputs into a Feature Narrative outlining the scope, purpose, and problem this feature will solve.
We identified the two personas that our solution would serve.
After we identified our personas, we spent time exploring their workflows and goals and drafted Concept Scenarios + Workflows to further define feature scope.
We also leveraged our App Developer Journey Map to align around user needs
We began whiteboarding early design concepts…
…and digitized promising designs into wireframes for more design exploration and iteration. Once we converged on the designs we wanted to test, I created higher-fidelity mock-ups for prototype testing.
Concurrent with prototype preparation, I wrote a Usability Testing plan that includes Design Goals, Prototype Goals, etc.
Number of tests: 3
Total number of Participants: 4-5 per test
Effort: 4-6 weeks of recruitment, prototype iteration, testing, synthesis, decision-making
Video call, so user can share her/his screen during the prototype portion
One participant, one interviewer, one note taker per session (sometimes w/1 passive viewer)
30 min per test: includes a short briefing, interview questions, prototype test, and closing questions.
Type of participant: Pivots who use Apps Manager (e.g. PEZ, IAD, Marketing, etc.)
. . .
Prototype 1: Multi-Foundation Search
Description: Test the UX of an Apps Manager search that can access multiple foundations.
- The search grid was easily understood and scanned.
- However, only one tester went straight to search, the other 4 (+ two Apps Manager developers) opted for clicking to find the app
. . .
Prototype 2: New Homepage
Description: Co-create the ideal homepage with the user - understanding reasoning and workflows that prompt their decisions
- 4/5 users had trouble differentiating between being on an org page or space page. Strong signal that the two pages are easily confused.
- 2/5 users said an event stream would be the first thing they look for.
. . .
Prototype 3: Multi-Foundation Search + New Homepage
Description: Give the tester a clickable prototype with a new homepage + search, combined.
- This design gives users easy access to apps, regardless of location, and information about those apps?
- Users easily notice and quickly want to leverage “recent apps” s/he has access to
After several rounds of testing, note-taking, and synthesis, we converged on the designs that fit the desired feature scope and successfully fulfilled the user scenarios.
I refined the winning designs into smaller design bits for engineering to work on and deliver:
a. Homepage for single foundation (new)
b. Homepage for multiple foundations (new)
c. Multi-object Search, across Foundations (new)
e. Breadcrumbs, including the Foundation level (new)
. . .
🎉 Apps Manager has a polyhierarchical IA that enables app developers to navigate quickly to their desired app, service, space, or org regardless of which foundation the object lives in!
Moving a UI experience from awareness of (1 * x objects) to (n * x objects) is not an easy design problem to solve, when x = 1 - 10,000 and n = 1 - 100. IA decisions that assumed finite x of objects could live in a tree IA structure and be searched, indexed, filtered, and displayed quickly become outdated when that xis exponentially increased. During this project, I depended a lot on typical Navigation: You-Are-Here markers such as:
abbreviated search results
object-specific large search
several levels of headings
simplification of global navigation so that each item became more visually prominent when selected