Core Platform
Making an invisible data routing layer legible
Problem
Segment was the bridge between surfaces where customer data originated and the tools that consumed it. It acted as a routing layer, moving data across a sprawling ecosystem of tools, but the mechanism itself was hard to see or reason about. The opacity was the result of two problems: First, the product terminology was anchored in Segment’s own engineering view, the connectors it had built, so customers had to translate their own setup onto an unfamiliar framework. Second, the middle of the system was a black box. Customers could see the endpoints— which sources were emitting events and which tools were consuming them, but not how data moved between them. They had no holistic view of the system, and no way to trace which sources were feeding a given destination. For a system built to make data usable, the underlying logic was more obscured than it needed to be.
Role & scope
I was the sole designer on two initiatives: first, to address customer confusion around the integration language, I conducted UX research and recommended a clearer vocabulary. Later, on a small team with the founder and the Head of Product Marketing, I designed the visualization that became the platform’s core view.
Approach
Resolving the language
Through customer research, I surfaced a problem that the existing vocabulary was quietly creating. People thought of Segment itself as an integration, so when we labeled endpoints connecting downstream third-party services "integrations," the term collided with what customers already believed Segment was. This diagnosis led me to recommend a customer-centric vocabulary. Data comes from sources (first-party data from customer-owned surfaces) and flows through Segment to destinations (inclusive of both third-party applications and data warehouses). This reframing shifted the product nomenclature to align with how customers actually reasoned about their data.
Making the flow visible
The new product naming resolved the ambiguity around "integrations" but not how sources and destinations actually connected. Customers still had no easy way to see how their data moved, either across the system as a whole or along any single route. I joined a small team with the founder and the Head of Product Marketing to solve this problem in the web app. The founder proposed restructuring the entire web app into three horizontally scrolling pages. I appreciated the boldness of this vision but was concerned about building the product around such a non-standard interaction pattern. Inspired by Sankey diagrams, I proposed a more bounded visualization for the Overview: a view of connections between sources and destinations so the state of the system was visible at a glance.
Shipping and refining
We shipped an MVP in about a week and refined it as real usage insights came in, tightening the visualization and building it into the Overview, the workspace homepage. The structure people saw every time they opened the product had become the central view.
Outcome
The work propagated outward in stages. The sources-and-destinations terminology first became the backbone of how the product itself was organized and understood. This new terminology, in turn, shaped the Overview, the workspace homepage, where the directional flow of data between sources and destinations became the central visualization. The updated product experience was well received by customers, and the founders were pleased with the visualization as a succinct way to represent the core of the product.
The brand team then built on the same motif, and it came to anchor the marketing site and external collateral. Years later, through Segment’s acquisition by Twilio, the same language and motif still front the product and the brand, evidence that the model was durable enough to outlast reorganizations and a change in ownership. Both the vocabulary and the flow motif are common across universal API platforms today, though we landed on them generatively, without an obvious precedent at the time.
