Tanzu Data Services

Designing Tanzu Data Services Experience

When I joined Tanzu, developers were duct-taping together CLI commands across three separate tools just to spin up a database. I led a team of three designers to build the platform's first GUI-based data services experience from scratch — a marketplace, service management, and topology visualization that shipped to production and became the foundation for all future Tanzu capabilities.

MY ROLE

Lead Designer - Strategy, direction & execution

TEAM

Design, Product, Engineering, Tech Sales

PLATFORM

Tanzu – A cloud-native application platform

USERS

Technical – Developers, Platform Eng

+10%

Platform Adoption

IMPACT

-22%

Support Calls

Customer Satisfaction

THE PLATFORM HAD A HIDDEN PROBLEM

Tanzu is a cloud-based application platform that enables organizations to build, deploy and manage applications alongside critical data services. Tanzu's value proposition was simple: give developers everything they need to build and run cloud-native apps in one place. Platform value comes from easily facilitating the exchange between Service Providers and Service Consumers. But data services — databases, caches, message queues — were a glaring exception. There was no GUI. No list of services available. No way to see what was running or what it was costing.

On paper, leadership saw this as a feature gap. A quick UI to replace CLI. My job, early on, was to convince them it was something much bigger.

CONTEXT

BUSINESS GOALS

Collaborated with PM to define business goals

  • Increase adoption of Tanzu platform among developer community by providing data services

  • Reduce support calls by helping developers self-serve to identify services and attach to applications

  • Improve trust and satisfaction among users

KPIs

THE CLI WORKAROUNDS CHANGED EVERYTHING

I led foundational research across developer and platform engineering teams — interviews, workflow shadowing and analysis of support ticket patterns. We expected to hear frustration about missing features. What we actually found reframed the entire problem.

Developers had built elaborate CLI scripts and internal wikis just to perform basic tasks the platform should have handled natively. They weren't waiting for a better UI — they'd already assumed one would never exist.

Synthesis from 12 developer interviews

These workarounds were a signal: the unmet need wasn't a CLI replacement — it was a missing mental model. Developers didn't know what services were available, what they cost or how to manage them once running. Admins didn't know who was using what or whether the platform was delivering value at all.

The research gave us a clear frame: this wasn't a UI problem, it was a discoverability and trust problem. Fixing it required a coherent end-to-end experience, not a settings page bolt-on.

RESEARCH

KEY RESEARCH FINDINGS

  • Developers averaged 4+ tool switches to complete a single service provisioning task

  • No shared vocabulary between what admins called services and what developers searched for

  • Support tickets spiked at two moments: finding the right service, and troubleshooting after attachment

  • CLI workarounds existed in 8 of 12 teams interviewed — homegrown scripts filling platform gaps

DESIGN PROCESS

FROM BLANK SLATE TO SHARED VISION

As a newly formed team building from the ground up, I had to influence cross-functional stakeholders, define product direction with no precedents, and evangelize a user-centered design process from day one.

I used various phases of design methodology to evangelize user centered process. This helped the team to understand we are solving right problem and considering all possible solutions.

STRATEGIC DECISION

PUSHING BACK ON THE QUICK FIX

When I brought the research back to leadership, the initial response was to scope it down: add a service list to an existing page, ship in six weeks, move on. I pushed back — not with opinion, but with the data we'd gathered.

PIVOT: What leadership wanted vs. what I proposed

Leadership's ask: A service list embedded in an existing screen. Fast, low-risk, shippable in weeks.

My case: A bolt-on list wouldn't solve discoverability — developers still wouldn't know what was available or how to use it. It wouldn't help admins publish or manage. And it would create another fragmented surface we'd have to undo later.

The outcome: I presented a side-by-side: the short-term patch vs. an investment in a proper marketplace and management layer — with projected support ticket reduction and adoption lift. Leadership approved the full scope. We had one quarter to ship something production-ready.

Winning that conversation meant co-owning the outcome. I partnered with the PM to define success metrics upfront, set MVP scope, and create a shared north star that kept engineering, marketing, and tech sales aligned throughout.

DESIGN BRAINSTORM

BRINGING TEAM TOGETHER WITH EMPATHY

I I ran a series of structured workshops — producers and consumers in separate sessions first, then together — using storyboards to make abstract workflows tangible. Storyboards were deliberate: they let engineering challenge feasibility early and let business stakeholders see user impact without needing to read a spec.

Participants

  • Design

  • Product

  • Engineering

  • Business/Marketing

  • Tech. Sales

STORYBOARDS

FINAL DESIGNS

THE DECISIONS THAT SHAPED THE DESIGN

DECISION: Marketplace as the entry point, not a settings page

Research showed developers didn't know what was available. We built a marketplace with visual hierarchy that surfaced Tanzu-supported services prominently. This shifted the mental model from "finding a setting" to "choosing a tool" — a distinction that drove significantly higher engagement in usability testing.

The final experience addressed both personas across four interconnected surfaces. Here are the decisions behind the most important ones.

Tanzu Dashboard :

Developer focused dashboard with insights about key areas

Create Service Instance : Guided step-by-step process to create local version of selected service with plenty of help

Marketplace :

Easy to find required resources with visually highlighting on Tanzu supported resources

Service Details :

Service details with metadata, attached apps and visualizations of resource utilization & topology

Topology :

Visualization of services & other reouces are connected on the platform

DECISION: Step-by-step provisioning over a single form

Service instantiation involved several technical parameters. A single form would've been faster to build — but testing showed developers abandoned it when they hit unfamiliar fields. A guided step-by-step flow with inline help text reduced drop-off and removed the need for CLI fallback on the most common path.

DECISION: Topology visualization for admins

Admins' core anxiety was "I don't know what's connected to what." Rather than another data table, I designed a topology graph showing live relationships between services, applications, and resources. This was the riskiest surface to build — and the one that resonated most strongly with the admin persona in testing.

ALIGNMENT

GETTING BUY-IN FROM STAKEHOLDERS

I and PM pitched the project with business & user benefits to get buy in leadership

OUTCOME

WHAT SHIPPED AND WHAT CHANGED

We shipped to production users within three months and monitored for three months — the platform's first ever GUI-based data services experience. The service patterns we established became the foundation that subsequent Tanzu teams built on.

Beyond the numbers: the project established design's seat at the product strategy table on Tanzu. The research-led pushback on scope — and the delivery that followed — created a new model for how design and product collaborated on the platform going forward.