I turned a request for a unified hub into an evidence-backed platform strategy.

The project arrived as a UI question.

An engineering team asked me to look at UI for a proposed unified hub across the platform’s collection of tools. The request already contained a solution, but the underlying user problem had not been clearly defined.

Rather than begin with screens, I treated the “single pane of glass” as a hypothesis. Was fragmentation actually the most important customer problem? Which experiences should become consistent? Would combining tools solve the pain—or simply put disconnected experiences behind one navigation bar?

The first design decision was to pause the interface work long enough to understand what “unified” needed to accomplish.

I built an evidence base from behavior and conversation.

Without deep UX research practices in the organization, the design team often found creative ways to gather context. I used two complementary methods: live interviews and quantitative analysis of Slack support requests.

Interviews revealed motivations and journeys. A mining script and internally hosted LLM clustered three months of support data, showing which problems surfaced most often at scale.

Because the product did not yet have a persona model, I created a lightweight framework to decide whom to interview and to understand which kinds of users were asking which kinds of support questions in Slack.

• Data analyst / engineerEngineers who build and maintain data pipelines and semantic layers
• Data explorerAnalysts, PMs, and business users who mainly explore and consume data
• ML practitionerPeople hands-on with model development and experiments
• Team lead / technical ownerTech leads, staff engineers, or managers responsible for outcomes across data and ML work
• Platform / MLOps / observability engineerEngineers who provide and operate the platform across compute, telemetry, and security
• Data steward / governance officerPeople accountable for data quality, definitions, and compliance

I validated the clustering before scaling it.

I first grouped interview pain points manually, using affinity mapping to turn individual observations into a ranked theme taxonomy. I then ran the transcripts through the clustering agent and compared its output with my manual synthesis.

Once the two approaches converged on a stable set of themes, I applied the assisted method to the larger support dataset and reviewed the results again. The model helped me work at scale; it did not replace synthesis or judgment.

Two methods, one problem space

Comparing both sources produced six shared themes. I ranked them by frequency, using prevalence as a prioritization signal rather than as a standalone measure of severity.

Users weren’t failing to use the tools—they were building shadow systems around them.

Every pain point had a hack: Slack threads replaced search, spreadsheets replaced collections, HTML exports replaced sharing, and email chains replaced access requests.

The research validated the hub—and defined its limits.

Discoverability and cross-tool context switching were repeated, high-impact pain points. That evidence supported the original direction. It also prevented the team from treating a unified interface as a universal answer to platform problems.

An incremental path

Capabilities over tools.

The original engineering proposal was a navigation bar linking isolated applications. That would reproduce the same fragmentation inside a new container, so I proposed an information architecture organized around what the platform enables—not a list of internal tool names.

The same platform needed to orient people with very different intentions while preserving direct paths for experienced users.

From strategy to production code.

I presented the research and recommendation to engineering managers across the platform product. The work aligned the team around a problem definition and clarified where unification could create value through discoverability, shared context, and more coherent entry points. It also distinguished those opportunities from problems unification could not solve, including platform stability, reliability, and infrastructure-level performance.

With no dedicated frontend engineer on the team, I paired with the lead backend engineer and submitted a series of merge requests to bootstrap and refine the application shell in one week. Working directly in code was considerably faster than translating the thinking into Figma mockups and then moving through a separate interpretation and implementation cycle with a frontend engineer.