Getting the Usage Story Straight

As a design lead for Tanzu Observability, I used the End-to-end story process on a product feature called the Usage Portal to align the product team and to make sure that the entire customer experience was considered in our solution — from the initial learning about it to using it at scale.

Project Background

Tanzu Observability is a SaaS tool for monitoring the performance of IT infrastructure and applications. Customers buy a subscription which entitles them to send a certain amount of monitoring data to our platform. Observability teams in customer organizations lacked the tools to track their usage and costs. This was preventing those teams from onboarding their own customers as well. This project was an effort to help customers holistically monitor their consumption and place guardrails on consumption.

At the start of this project, the design team had three separate tickets in our backlog with different product managers associated. From the perspective of the product managers, they created tickets to address needs they were hearing from customers. From the design side, we were able to see a thread connecting the needs and pain points identified in the individual tickets.

The product managers had done some interviews with customers to understand their needs and what they wanted to be able to do. We were also able to learn about these needs from sales deals that we lost where the lack of these capabilities factored into the decision not to purchase. Additionally, I met with members of our technical pre-sales and customer success teams to understand the problem from their perspective. Some of these issues were ones that the customer success team dealt with all the time, so they were a powerful resource.

Kickoff Workshop

After digesting the work that had been done already, we decided that it would be helpful to understand how the different pieces may fit together. We ran a workshop with representatives from design, product management, engineering, and customer success to understand the ecosystem around the problem. From this workshop, we were looking to address the following: 

1. What were the pain points and desired outcomes of our hands-on users and their stakeholders?  

2. What were the outcomes we wanted for our company? 

3. What were some specific use cases that could help users’ pain points and lead to the desired outcomes? 

4. Were there technical constraints that we were working within? 

Usage portal workshop whiteboard

Through the workshop, we uncovered themes that suggested a coherent story.

Script and Storyboard

With this journey in mind, I set to work on a script to tell that story from the perspective of our customers. This script would later be brought to life in a storyboard. The goal was to create a common understanding of the customer and market problems, as well as to map out the buyer’s journey for our user: How do the learn about the new capability? How do they try it? Why do they decide to adopt it? What is it like to use it? And how will they scale up their usage?

Going through the script-writing process, I realized that we already had some of the pieces we needed in the product, but some of those pieces were incomplete, and they were not connected in a way that would be obvious to a user—they would have to go to different places to find the information they needed. For example, we had a feature called Ingestion Policies that should allow users to track usage for an application or team, but in our research we heard that they were not useful because they were too restrictive and didn’t allow customers to segment the data in ways that were meaningful to them. And we had several dashboards related to overall account-level consumption but a user might have to look at multiple dashboards to get the full picture.

Slide from the Usage Portal storyboard

I worked with my PM counterparts throughout this process to ensure that we were on the same page. Once we were aligned and felt good about what we had we presented the story to leadership to get their buy-in.

Prototype

When working on the storyboard, I had created some very low fidelity wireframes to illustrate the ideas, but for the prototype we needed to move to a higher level of fidelity. One of the challenges here was that now we needed to think about actual data. At this point we really started to lean on the customer success team. They had already been helping customers on a case-by-case basis to solve some of the challenges we were looking to solve more generally.  

We needed to propose where this functionality would live in the product, what we would call it, how users would go from one task to the other, etc. We collaborated with our information experience partners on the verbiage and copy. While we had started referring to this as the “usage portal” we ultimately decided that “Usage and Subscriptions” was more descriptive of what users would find. In the final design we brought together some of the information that had been in different dashboards and put that alongside the ingestion policies when allowed users to segment usage data.

Screen from Usage Portal prototype

Next Steps

We shared the vision we had created resonated with our customers. These customer conversations were critical in helping us validate assumptions, uncover more questions, and further improve the experience. Then there was the matter of scoping. The story we presented was deliberately forward-looking. There were things that customers wanted, that would be very technically challenging. Including these things in our prototype was important because it helped us show where we wanted to go while allowing us to define a plan to get there.

The Usage and Subscriptions capabilities are being rolled out to Tanzu Observability customers in phases with some of the first pieces already available in the product. As customers begin taking advantage of these new capabilities, we expect to learn more and to continue providing new tools to help users understand and manage their consumption. 

Learnings

• The E2E story process was helpful for this project to unify different aspects that were initially viewed separately, and to get the whole team aligned on a vision. 

• Having design, engineering, and product management all collaborate on the E2E story creates buy-in across the team.  

• This process is most useful when done early. If implementation has already started, it may be too late. 

• The process is fairly involved, so it is probably better suited for larger design efforts where there is more ambiguity.

This end-to-end process is now part of our team’s process. And since doing this end-to-end story, our team has gone on to do several more. It is a great tool for aligning the team and making sure that the customer is at the center of what we do.