The Tanzu Developer Tools shown in the 3 supported coding environments
My Role: Lead Product Designer for Tanzu Developer Tools.
Technologies Used: Figma, Dovetail, Miro, UserZoom, VS Code, IntelliJ, Visual Studio, K9s, Tanzu CLI, kubectl, GCP, Azure.
Methodologies: Usability studies, research synthesis, ideal experience exercise, rapid prototyping, iterative design, and a lot of collaboration with cross-functional partners (PM, Eng, Tech leads).
Joining the Team
When I joined VMware I started working on a product called Tanzu Application Platform, also known as TAP. TAP is a set of tools that enable faster, more secure application delivery using any Kubernetes provider. I joined before TAP had released to the public, and as an organization we were still working on very early pre-alpha proof of concept pieces of the overall platform.
I joined the team working on Developer Tools. Our goal was to create something an application developer could use directly within their coding software to manage their application running on TAP. We called this the Tanzu Developer Tools.
I became the lead designer of the Tanzu Developer Tools portion of the overall TAP project with that as my goal: how might we enable application developers to interact with and understand their applications on TAP from directly within their coding software? Initially I was tasked with answering this question for 2 different pieces of coding software, and then later upon the release of TAP I was responsible for the design direction of the Tanzu Developer Tools in a third piece of coding software.
I joined the team after they had completed a Proof of Concept and had just finished testing it with 5 users.
My Impact
I identified 5 key user needs from the research, and from conducting competitive analysis, then worked to get those flows added for our MVP roadmap.
- Create application on cluster
- Delete application from cluster
- See all applications on the cluster and their status
- See applications in multiple different namespaces
- See in-depth error and log details for applications and kubernetes components
I worked with my team to synthesize the research, and conducted a competitive analysis of other Kubernetes development software extensions. I noticed a lot of overlap between capabilities our research participants asked about that our proof of concept did not support, and capabilities those other extensions offered.
When the TAP project started, the ideal experience described to the teams working on the TAP components was that developers would use the CLI to interact with their cluster.
Here’s how I led the team through research synthesis and task prioritization.
Synthesizing Research
The Tanzu Developer Tools Proof of Concept
When the team’s Proof of Concept was released this was the only functionality it had. It could Live Update, meaning update code changes to your running application without necessitating a full rebuild and redeploy. This Live Update feature was only accessible via the Command Prompt.
Though the team had completed testing, they hadn’t synthesized any of their notes or recordings yet. The first thing I did was work with the Product Manager to divide up the study recordings between us, and create stickies from the research. This involved watching the recordings of the research while reviewing any notes that were taken during the conversation, and simultaneously reviewing research plan to understand the scenarios tested, then creating stickies for follow-up questions, comments, or interesting things noted.
I then worked with the team, so the Product Manager, Tech Lead, Engineering manager, and engineers, to synthesize the research findings into insights in a meeting. The insights from the research started out as a bunch of stickies from the individual recordings, and ended up in the groupings you see below.
Research Insights Grouped, Follow-up Tasks Categorized
We also took this time to call out and celebrated the specific insights that showed parts of the proof of concept were working well.
POC Wins
Next I plotted those insights into themes, and proposed follow-up tasks. I did this work on my own, then brought the team back into the loop to review my themes and proposals for accuracy and comments.
I proposed two categories: Immediate Action, the things we should work on in Alpha and Beta releases, and Future Action, things we should work on for the MVP GA release or beyond.
This is where I noticed that some of the themes and actions emerging from the research, and agreed upon by the team, weren’t present in our overall roadmap.
Separate but in parallel to thet research synthesis, I worked with my team’s PM to review this, and some of the other artifacts we’re discussing, with the PM and Designer who oversaw our program within the overall platform. Our exlpanation of the insights we gained from the research resulted in expanding the target user flows our developer tools extension supports.
Follow-up Action Planning
Aligning on Alpha
Following our task review I scheduled a few additional team exercises to ensure we were properly aligned on our release plans.
First I brought the team together to map our ideal experience. We reviewed what the team’s initial goal was pre-proof of concept, and what priorities had shifted in our broader program in the interim. Then we collaboratively mapped out the ideal experience we wanted to work toward in our MVP at GA.
Mapping the Ideal Experience
Next I led us in using our list of follow-up tasks from the research and our mapped ideal experience to populate three categories, Product Goals, Business Goals, and Team Goals. I wanted to ensure that the tasks we were creating for ourselves mapped to specific goals that all of our team members understood, felt were valid, and we could rally behind and become excited about.
Understanding Goals
Finally, I led us in an exercise to identify which team group, design, engineering, or product management, had outstanding work for each of our new tasks.
Determining Outstanding Work
Designing and Iterating
Text-only Exploration, Text & Graphic Exploration
One of the primary requests we heard in the research feedback was developers wanted a way to understand which application, or which application components in the case of a microservice, were currently on the developer’s target cluster. Additionally, developers needed a way to understand essential status and configuration information about those applications.
As I brainstormed solutions to this need I investigated many methods of conveying the necessary information, from an information dense command line interface to an information-lite singular status icon, landing somewhere in the middle with a new panel designed to sit alongside the developer’s code window.
When I settled on exploring the concept of this new panel I began to imagine ways I might show the developer their application information, including using only text, using text accompanied by graphics, and others.
Clarity Design System Icons, Tanzu Mission Control Icons, Generic Shape Icons
I felt pairing graphics with text struck a useful balance between the at-a-glance comprehension of an icon, with the description of text. I worked with the central VMware design organization Clarity, with designers from other products in my design group, with the individual IDE design style guides, and used my own creativity to mock up a multitude of different icon and text combinations. These are just some of the icon and text combinations I explored and solicited feedback and input from my team and my design group on.
MVP and Beyond
The Tanzu Workload Panel in 3 Separate Code Editors
As I mentioned before, I designed, iterated, tested, and supported through implementation these experiences in three separate Integrated Development Environments (IDEs): VS Code, IntelliJ, and Visual Studio Code. Each IDE had its own conventions and interaction style that I needed to research, understand, and reconcile with our VMware Clarity Design System. I then needed to draft a design, solicit feedback from my team and iterate, and test with application developers to ensure my flow felt natural in that specific IDE.
A graphical representation of the design work I completed tied to our entire platform’s target journey map.
The workload panel was just one of the major flows that I worked with my team to design, iterate, test, and release into our Developer Tools extension. Over the course of around a year and a half we took the developer tools experience from nothing to a full extension that developers can and do use to interact with their TAP installations, enabling them to understand and manage their applications. To date we’ve had about 1,000 downloads of our extension and have received very positive feedback. I’ve personally interviewed over 20 application developers, conducted over 25 research sessions, tested over 100 jira tickets related to coding and functionality, and filed 14 bugs that I found through testing.
