The following post was written by Vishnu Kumar and Rhea Manocha, who interned at Pivotal during the summer of 2018.
We’ve all been there; trying to put something together but you just can’t make heads or tails of the instructions. Maybe it was IKEA furniture, something you were super excited to buy, but a few hours later all you have is a pile of wood, nails, and frustration.
Or, maybe, it was a PCF tile.
Interning at Pivotal this summer was an amazing experience, and we wanted to share some of our learnings.
But first, some context.
Pivotal Cloud Foundry is Pivotal's cloud-native platform that enables developers to do their work more efficiently. PCF allows companies to move their application infrastructure onto or across different clouds.
Tiles are integrations with PCF that make it easy for developers to access services like app monitoring, databases, and other add-on components. Tile authors are usually third-party ISVs who build software that complements PCF’s core functions. For these ISVs, the tile creation and publishing experience is designed to mirror how smartphone developers create apps and make them easily available in app stores.
At the beginning of the summer, we found using the tile documentation to create a new tile was intimidating. The tile docs were helpful, but very technical. And they didn’t contain all the information we needed to get started developing our own tiles. Furthermore, the information was generalized for all types of users, rather than focusing on specific roles.
As the saying goes, within every challenge lies an opportunity!
So we decided our summer project should be the creation of a getting started guide for developers that want to package their custom software as a PCF tile. With the support of Pivotal PMs, engineers, and the designer on our team, we uncovered shared knowledge across the organization, which was vital to us as we attempted to become domain experts.
As a product design intern (Rhea) and product management intern (Vishnu) we came to our work with different perspectives, experiences, and values. Pairing on this project shaped the outcome to be inclusive of both the user and stakeholder.
To get started, we used a process called “discovery and framing” (D&F). During discovery, we conducted a broad range of user research. Then, we narrowed the scope of the project down to a specific problem. Framing involved generating many potential solutions to the problem. From there, we selected one and pared it down to a first, rudimentary version. Finally, we planned to iteratively improve the prototype solution based on feedback from stakeholders and users.
After going through the D&F process, we settled on creating a “Getting Started” guide for Pivotal partners interested in creating their first tile. Let's break it down into two stages; Discovery, and Framing.
Discovery (Rhea)
When we started the project, we had little context around tile development. We did a walkthrough on our own using the existing docs to try to build a tile from scratch. Vishnu’s technical expertise helped us navigate the docs. My experience with cognitive walkthroughs as a research method helped us pay attention to our internal attitudes along the way. For those unfamiliar, a cognitive walkthrough is a user research method in which the participant explains her thoughts and emotions as she executes a task. Essentially this breaks down to "thinking aloud."
After internalizing the lessons from our self-service experience, we aimed to learn from the experience of others with this process.
We conducted six user and expert interviews. The interviews with Pivotal engineers across several different teams helped us understand the journey that an external tile author goes through to get a tile up and running. Even though these stories were second-hand, it was incredibly valuable.
We expected interviews to be easy. I was accustomed to creating learning goals and protocols and Vishnu was comfortable interviewing, thanks to a user research class he took. However, we soon realized being in a technical space meant we needed to rely on our team to help us navigate the ocean of information we were drowning in at the beginning of our internship.
Research in an organization requires a balanced perspective. As a designer, I focused on understanding the specific problems users were facing. As a PM, Vishnu was thinking about how to prioritize the problems we wanted to solve.
We kept both of these perspectives as we interpreted the results. An affinity diagram helped us synthesize and identify common themes in our research. With the help of our team, we also constructed a journey map outlining the process external tile authors follow, highlighting where users experienced the most pain.
Affinity Diagram
Journey Map
Another vital tool to the project: personas. We found that internal and external developers have different goals, so we created two personas, Isaac and Terri. Isaac, our Pivotal developer persona, works on an existing tile and has easy access to experts within the company. His colleagues at Pivotal have context on how tiles work. Lucky for him, he can just pair with his fellow Pivots to learn about tile development. Terri, our partner tile developer, works on a new tile for her company that is a new Pivotal partner.
Although we wanted to solve all the problems we uncovered, we had to prioritize and focus on one persona. We discovered external tile authors face more difficulty working on tiles than internal Pivotal developers do. As a result, our problem statement focused on the partner experience and our goal was to improve it.
Terri the External Tile Author persona.
Framing (Vishnu)
In the discovery phase, Rhea and I learned more about the problem space and created personas to better understand our users. We also scoped our summer internship down to a single effort: improving the external tile author experience. This aligned with the larger business goal of expanding the PCF platform ecosystem. With a larger number of PFC-integrated partner services, the platform could solve more jobs for its users.
After discovery, we started the framing phase. Here, we started working on solutions. After brainstorming and applying some of the research insights we gathered during the discovery phase, we created an initial wireframe. We thought it would be an amazing panacea for all the pain points we believed tile developers were experiencing.
Our first attempt at our eventual solution intended to be a “one-stop-shop” for tile development. We tried to bundle a ton of functionality into one neat package:
-
Ops Manager from PCF
-
Documentation on creating UI forms for Ops Manager
-
An IDE in which you could work on the YML files that were necessary to create those UI forms
-
An environment in which you could see how edits to the YML file would actually render in the Ops Manager UI.
Rhea and I were excited about our new idea and the prospect of deftly alleviating nearly all of the tile developer pain points in one visionary product.
Unfortunately, the PMs on our team explained that our grandiose idea would be way too complex to actually implement.
First Wireframe
Though a bit discouraged at first, we quickly became motivated to come up with something better suited to our business and user needs. Rhea and I headed back to the drawing board. Knowing that we were constrained to the Pivotal docs framework, we scoped down our lofty ideas to target the specific problem we were solving. We honed in on a minimum viable product (MVP), which is essentially a version of a new product that is just valuable enough that users will adopt it. We could then iterate on the solution based on real-world usage patterns.
To come up with the MVP, Rhea and I revisited our persona, Terri the External Tile Author. We focused our thoughts on the pain points she was experiencing. We came back to the analysis of the current problems with the external tile author experience, through the lens of Pivotal documentation. We concluded that the tile development documentation was unclear, missing key information, or way too complex for beginners. There was no real guide of where to start or how to go about tile development. During our own attempt at building a tile, we found the documentation inaccessible and somewhat convoluted. There was a simple introduction page that briefly previewed the content in the rest of the documentation. Clicking on the links to any of these pages, however, brought us straight into the weeds, diving headlong into technical information without much context or explanation.
Based on our analysis, we realized that the most significant barrier for developers making new tiles is that there’s simply no good resource simply laying out how to go about doing so. Scoped down to a specific problem, Rhea and I started wireframing an MVP, a simple splash page for the tile development documentation with a getting started guide on tile development for new external tile authors. We also enlisted the expertise of Ramia, an intern on the PCF Documentation team, to make sure we got the language we used just right.
MVP.
We spent the next couple of weeks iterating on our MVP using the build-measure-learn lean framework. This involved wireframing, usability testing, and synthesizing the results to glean insights on how to improve the product, then doing it all over again for the next iteration of the product.
We collected general feedback by showing our wireframe to the partners team, platform engineers, docs team members, and designers at events like company-wide design critiques. Along the way, we gained more context and got a concrete understanding of the specific steps in the tile development journey. As our context and understanding increased, so did the content fidelity of our wireframe.
Rhea and I also tested the usability of our prototype through cognitive walkthroughs. We interviewed people that were the closest proxies to brand new external tile developers: new Pivots and interns with technical backgrounds, but without much context or experience building tiles. After each interview, we synthesized notes we took in a color-coded Excel spreadsheet. This exercise also helped us visualize where users were having issues. We documented our learnings in Trello, which helped us maintain a high-level view of the problem and not get lost in the data, and provided feedback to other stakeholders about successful aspects of text and UX.
This focused approach, coupled with scheduling interviews back-to-back and dedicating time after each interview for synthesis, was a welcome change from the comparatively disjointed way in which we did user interviews during the discovery phase. We also included text and content edits from Ramia as part of the iteration process. As a result, we could rapidly gain insights and iterate on our prototype daily.
Later wireframe.
Throughout this process, at each revision of the wireframe, Rhea and I grappled with balancing user needs and the constraints of the company, attempting to iterate in a way that added value on both sides. Our unique backgrounds proved complementary. I leaned on Rhea’s UX background for some of the usability testing protocol, and for quickly wireframing prototypes. And I was able to use my computer science background to provide Rhea with context and guidance through some of the more technical details. And my product management experience helped us focus on the high-level business needs while balancing the needs of Terri, our persona.
After the rapid prototyping phase of the framing process, it was time to write user stories. User stories are short, atomic descriptions of a feature articulated from the perspective of the user. This allows each feature’s functionality to be explicitly defined, and to be built out in exactly the way it was intended. Unfortunately, we had a false start during our prototyping phase where we jumped the gun. We wrote stories for an unfinalized wireframe, and ended up having to scrap nearly all the stories we had written. (They were no longer relevant to our updated version of the wireframe.) Once we finalized our prototype, our second time writing stories went much better. Rhea and I were a two-person story factory. We used the experience we had gained from our first failed attempt to blaze through defining stories for our entire wireframe in less than a day.
After all the stories were written, we had an iteration planning meeting in which we assessed the relative effort necessary to complete each story. Ramia, the intern on the docs team who built our splash page, worked with us on this process.
Pivotal Tracker.
Journey map.
After several iterations of this story-writing and IPM process, the page was fully built out in a staging environment and we were able to finally push our summer’s work to production which you can view the PCF Tile Developer Guide here.
Vishnu and Rhea.
Pairing cross-functionally helped us learn from each other. We learned a ton about each others’ roles. This helped us build empathy for coworkers and look at our work from a different lens.
This summer was full of continuous learning that we will take with us, no matter where our careers lead. Some of the lessons we learned were earned through trying circumstances. like when we wrote user stories too early and had to redo our work. We also learned that reusing participants in testing can create bias.
Some learnings were more concrete, technical skills like iterative wireframing, writing user stories, and synthesizing research. However, maybe most importantly, much of what we learned was about what it means to be an empathetic team player.
Both of us will never forget the experience we had at Pivotal this summer. There’s nothing we’d like more than to thank everyone we worked with this summer and those who helped us, in every and any way, throughout our intern experience.
Vishnu Kumar worked at Pivotal as a Business Operations Intern and again as Product Management Intern. He is studying Computer Science at University of California, Berkeley. In his free time, you can catch Vishnu working on a couple cool side ventures, traveling near and far, and stopping to smell the roses. You can connect with him on twitter @vishnugkmr or at vishnukumar.io.
Rhea Manocha worked at Pivotal as a Product Design Intern. She is studying for her BS in UX Design at Purdue University. Outside of doing design work, she enjoys traveling around the world, trying new foods, and taking photos of her adventures. Her personal website is rheamanocha.me.
