Observability for the engineers who keep the internet running.
Kentik’s existing Kubernetes product saw little use. I investigated why through analytics, customer interviews, and surveys. Those findings led leadership to commission a new experience, which I led through discovery and design.
Principal Product Designer
Final designs shipped across MVP and subsequent releases. Pod views were added after MVP.
Hours to minutes to locate network issues, reported by customer cloud engineers. The visual topology replaced searching through pages of tables and gave PMs and engineers shared context for taking action. Sales reported $10M+ in closed product sales following the KubeCon demos and launch. Customers embraced it because it addressed their core frustrations: navigating complex networks, locating issues, and sharing context with their teams.
I can finally see it so easily and show my team the issues at every level.
Oil & Gas product managers / lead engineers
Want to see how we got there?
Principal Product Designer
Customers use Kentik to observe their cloud networks. My role focused on network-mapping architecture, making complex networks easier for cloud network architects to understand and navigate.
These environments can span Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform, and Kubernetes.
Kentik’s existing Kubernetes product saw little use. I reviewed analytics, interviewed customers, and conducted surveys to understand why. The findings led leadership to pursue a new product experience and ask me to lead discovery and design.
I spoke directly with customer cloud network engineers and facilitated the workshops myself to understand how they investigated issues, navigated Kubernetes, and shared findings with colleagues. I used those customer insights to influence the design direction with my VP, CTO, and team, which included engineering and product management.
I worked with engineering, the PM, and design partners to turn those findings into three design priorities.
“No more tables.”
Customer feedback during collaborative sketching
I asked customers to sketch their ideal solution and explain what they meant by ‘no more tables.’ Their sketches helped the team understand the Kubernetes hierarchy and why a visual approach mattered. Engineering also identified a key constraint: rendering hundreds of nodes.
We translated the hierarchy into a visual topology, a node-based, hierarchical view of the cluster instead of a table.
I switched to wireframes to separate information architecture from visual styling. This helped stakeholders agree on the topology layout, hierarchy, and placement of detail.
Release scope: these wireframes document the agreed direction, including pod detail that was deferred from MVP and built afterward.
The agreed direction: a cluster-overview canvas that drills from clusters → namespaces → deployments, with a right-side drawer carrying performance, traffic, and pod detail at every level, and high-latency states flagged inline.
Picking your battles mattered here. I let some things go, like showing region in the breadcrumb, so we could focus on the bigger picture and ship on time. Those went to the backlog.
SHIPPED PRODUCT
The final designs shown below shipped to customers across MVP and subsequent releases. Pod views were added after MVP.
The decision: use an infinite topology canvas with a persistent detail drawer. Customers could follow relationships across clusters, namespaces, and deployments while keeping performance data in context.
Checking feasibility: engineering wanted to see whether hundreds of nodes could fit in the canvas. I made the concept concrete through the design, which engineering used to build and test a view containing hundreds of nodes. That test confirmed the approach was feasible.
I can finally see it so easily and show my team the issues at every level.
Oil & Gas product managers / lead engineers
Customer cloud engineers reported that locating network issues had taken hours of searching through table pages, sometimes across thousands of nodes. The topology view made the issue’s location visible, bringing that task down to minutes.
Customer PMs could share a screenshot or point engineers to a region on the map, giving them a common reference for investigation and action.
Sales reported completed customer purchases totaling more than $10 million following KubeCon demos and the product launch. Prospective customers saw the experience demonstrated and purchased licenses.
Sales reported five to six customer purchases per month against a forecast of one. Buyers included existing Kentik customers adding the Kubernetes product and brand-new customers.
Customer account records showed organizations adding more people, and Pendo confirmed active use by those additional users. Alongside engineers sharing the experience with colleagues, this showed adoption spreading within existing customer organizations.
Visibility across deployments helped PMs and engineering teams coordinate changes and avoid conflicts.
The topology canvas and detail-drawer pattern became a foundation for Kentik’s Azure and AWS experiences, extending the design’s impact across the cloud product portfolio.
After launch, I used Pendo analytics, surveys, and direct customer conversations to guide continued improvements to the experience.
