App Platform

End to End Story

01.

James is working on a mobile app

02.

James works on his code and containerizes the app

03.

James also needs an environment to run his application

04.

James needs to troubleshoot

05.

There is a steep learning curve for James

Understanding Our Personas

Our Goal

How might we..
simplify the experience for application Developers on Kubernetes, so that they can build and deploy their applications faster?

How

Establish a home base for Developers to work with their apps using Backstage as our base platform

Backstage is an open source framework for building developer portals, created by Spotify.

The Vision

James gets invited to the platform

James gets an email inviting him to the platform with a link to login.

James logs in

James logs in to the platform using Single Sign On and all permissions and access to the right tools have already been set up for him by the Platform Operator.

James sees all his applications

James is lands at a central place where he can see all of his applications and spot anything that needs attention right away.

James can troubleshoot in one place

James can see all relevant details of his application and troubleshoot all in one place.

James can create applications

James can use templates with guardrails to quickly start creating applications using his favorite tools that have already been vetted.

Research

Leveraged Existing Research

And created journey map with user pain points, questions and assumptions. Validated this journey with members of different teams that had done previous research.

Led Internal Workshops

Such as working with contributing teams to align on journey map, tech, business and customer goals. Also identified the work that needed to be done in order to achieve our goals.

Conducted User Research

Conducted multiple rounds of research starting with discovery research to validate our initial assumptions and more focused research. e.g dashboard needs, logs and app creation.

Conducted Competitive Research

For general features offered in products that provided Kubernetes dashboards or app creation products that aimed to make the path to production easier for developers.

Learnings

Object Model

Overall, developers were able to understand the app topology and taxonomy we were proposing.

Troubleshooting

The most helpful information that users need in order to know their app's health and identify any potential issues is the pod logs and resource usage.

Helpful Frameworks

It will be useful to developers to have a standard framework to start working on their apps.

Kubernetes User Segmentation

Most users have basic to no experience with Kubernetes, but they were moving towards learning, so we should target user who:

Has done some Kubernetes training
Expects going into the CLI for more advanced troubleshooting, but likes to be able to do everything from the GUI.
Hands off deployment to production.

“As-is journey map" helped the team empathize, visualize and understand the App Developer’s journey through the creation of an app.

Crafted “How Might We” statements to ideate solutions with cross-functional teams

Socialized ideas through high-level flows with stakeholders

Validated internally though Subject Matter Expert Feedback and engineering reviews

Conducted usability testing studies of our prototypes with customers and recruited application developers

Design

Validation Learnings

As a Developer

I want to know other more useful information about my app before crossing the line to the Kubernetes resources.

I prefer not having to edit the .YAML file, but if it is necessary, I need a way to validate it.

Status Conditions are helpful, but I don’t understand what they mean.

How might we...

...provide the most useful app information up front before the developer has to cross the line to the Kubernetes resources.

...provide a simple process for developers to be able to see their workloads on the platform, so that the errors that can happen when editing the .YAML file are minimized?

...help users understand the meaning of the status and status conditions, so that they can identify quicker what went wrong with their running workload?

Delivery

The first release did not resemble the approved designs because of technical constraints, so we did rigid prioritization around technical feasibility. For the following releases, we had a design debt epic, and the engineers continued to address discrepancies as well as developing new features and changes based on our roadmap and user feedback.

Demo of the Tanzu Application Platform GUI. Although I worked on the strategy and research for other parts, I was the sole designer for the Runtime Resources view, starting at 12:45.
Disclaimer: The released product still has a lot of design debt that the team has to work through.

Success Metrics

Number of workloads in production increased more than 300% in 3 quarters.

Closed deals continue to rise exponentially

Clients engaged in our design partnership program. This is a collection of early users who can provide feedback during demo, design and early releases of components and features

Catherine McGarvey
VP Engineering
 

“Customers overall seem to really resonate with a lot of the principles /concepts/ technologies/ outcomes that TAP delivers.
We initially put a lot of emphasis on the ‘developer experience’ and we seem to have really nailed it.
Feedback is strong. Value of TAP for developer users seems to clearly be there.”