Rebuilding Segment Journeys from the ground up
Segment Journeys is a visual workflow builder that technical marketers and data teams use to reach their customers at the right moment, whether that's a nudge back to an abandoned cart or a reminder about tomorrow's appointment.
I led design for its rebuild from early vision work to GA, collaborating with three PMs, two engineering teams, and a researcher. This project was a lesson in cutting scope to deliver value quickly and learning when to push back on those cuts in order to preserve the experience.
The details couldn't make it through
Imagine a marketer wants to send a message to someone who added items to a cart but never checked out. They'd also like to reference the specific item in the cart to make the nudge feel personal. In the original Journeys, you could know when someone abandoned their cart, but there was no way to know what was in it.
That gap came from how the Journeys architecture worked under the hood. Every step in a journey was defined by an audience, a computed group of users who matched specific conditions. Because of this, the only information a step could pass forward was whether you were a member of that audience or not.
Customers worked around it by adding cascading layers of steps just to approximate information the system should already have. Extra steps meant higher cost and more logic to maintain. Some customers duplicated the same journey over and over, changing only the conditions.
A classic Journey, stitched together with extra steps to approximate personalization.
A new system that carries context forward
Journeys v2 is built around a new drag-and-drop canvas backed by an event-driven system. A journey can trigger off a specific customer's action, and every step carries that event's data forward.
Now an abandoned cart journey triggers the moment someone updates their cart, holds them there while they keep updating it, and only moves them forward once they've stopped for a set window. The follow-up message goes out with the latest cart data, not just the fact that they never checked out.
Because a journey carries context forward on its own, the same campaigns take a fraction of the steps. One customer condensed twelve journeys into one.
An abandoned cart flow in v2, where the message includes the actual cart contents.
Getting to Journeys v2
The rebuild took two years of incremental shipping. It started with vision work to align the team, then moved through three phases: event-triggered payloads, event-triggered Journeys for abandoned intent, and Journeys v2 itself.
The three phases
Event-triggered payloads
Event-triggered abandonment journeys
Journeys v2
Building belief in the vision
I started by sketching what the new Journeys could look like, working with two other designers so the functionality would scale to other products. We looked at how other tools handled similar problems, then came up with step types and settings of our own. We continuously stress-tested our ideas against use cases, putting ourselves in our customers' shoes and asking, "what's the best way to solve this with the steps and settings we're imagining?" Core pieces of the final product, like the ability to split on event properties, came directly out of those exercises.
When we started sharing the vision internally, people were stuck on how classic Journeys worked, so the new model didn't immediately click. We put together decks explaining what the new event-driven architecture was and why the features customers kept asking for weren't possible without it. Once the event trigger concept landed, the excitement was obvious, and we knew we were on the right track.
Two designers on the team working through an early concept.
Phase 1: Event-triggered payloads
The new architecture and visual canvas ended up being a much bigger lift than we'd planned for. To keep momentum, we stripped down the first release to a simple form: define an event trigger and send its data to a destination. This covered simple cases like confirmation messages.
Even though the first version of event-triggered journeys didn't have a visual canvas, I placed the entry point where customers would eventually create the full experience so the design could scale to what came next.
Customers were excited to get event data downstream, but confirmation messages weren't the problem they most needed solved. Most were trying to build abandoned intent flows, which are journeys that nudge someone back after they drop off mid-action.
Phase 2: Event-triggered Journeys for abandoned intent
We scoped abandonment logic next.
Advocating for the canvas
As the team scoped this phase, they debated whether to keep holding off on the visual canvas and fold the new logic into the single-page form instead. I knew the form wasn't the right choice. Our users already have mental models for how journey builders look and work, and the canvas is a key part of that. This logic would span multiple steps, including a branching step, and stretching it into form fields would have fought what people expected. Choosing the form would also conflict with the long-term vision, meaning we'd have to backtrack and rework the UI later once the canvas was built.
I designed three options to make the tradeoff concrete:
- A single page form with abandonment settings added in (the original proposal)
- A rigid canvas where steps could only go in fixed positions, from a limited set of step types
- A freeform, drag-and-drop canvas where steps could go anywhere, still from a limited set of step types
I led a discussion with the team to walk through the options. The rigid canvas turned out to be barely more work than stretching the form further, so we scoped it in.
An overview of the three design options I presented to the team.
Making the case for a complete experience
Once we'd built the rigid canvas and its step types, the team was ready to release event-triggered Journeys to public beta. I had a hunch the scope wouldn't hold up for most real-world cases, and was worried that shipping it as-is could break customer trust if it didn't meet their expectations.
I partnered with my research teammate to design the study, and we ran eight concept-testing sessions together. She shared my concern about the canvas scoping going in, and the findings confirmed it. We'd built basic abandonment logic, and the broader abandoned intent problem needed more granular filtering and cascading splits than the rigid canvas could support. Users were also hesitant to move to the new experience at all, since it had limited functionality compared to classic Journeys.
We brought the findings to leadership with two recommendations: expand the canvas to be fully flexible, and hold event-triggered Journeys in private beta until we were closer to parity with the classic experience. There was real internal debate about timing, but the research gave the team enough evidence to align on delaying the public beta and expanding scope.
The limited abandoned intent canvas. The add button only appears in specific spots, and only certain steps are enabled.
Phase 3: Journeys v2
With the canvas expanded and the beta extended, we kept building toward GA.
Matching the design to users' mental models
One of the new step types, still called "Wait for event" at the time, had never existed in classic Journeys. Its most complex mechanic was loopback, a PM's idea that let a customer cycle back through the step every time the qualifying event fired again, like a shopper who keeps updating their cart. To find out whether users could follow how it worked, I built prototypes and ran sessions with my research partner.
Users generally understood the loopback, but were getting tripped up by everything around it. People were still applying the classic Journeys mental model to the new system, expecting to wait passively until the evaluation window closed and then find out what happened. In reality, each branch got assessed the moment its event fired. The design wasn't making that clear.
Two pieces of the UI were contributing to the confusion:
- The step's name: "Wait for event" made it seem like you'd pick one event and then wait for it to be evaluated. One participant, unprompted, said, "To me, [the step] is essentially like a hold." That's where the new name, "Hold until," came from. In addition to changing the name, I rewrote the step's description to make its purpose clear.
- Where the hold duration lived: I'd put it in the parent node, since to me you sit there holding until an event pulls you out. Users expected it to be another branch alongside the events: do A, do B, or hit the duration and take the "everyone else" branch. I combined the configuration with the "everyone else" branch to match how they were already thinking about it.
Before: Wait for event step
After: Hold until step
Scaling steadily to GA and beyond
From there, we shipped steadily toward parity with classic Journeys. We added more step types, like a delay step and randomized split, tools for seeing exactly where a given profile stood in a journey, and quality-of-life features like versioning and editing.
I had created a design language early on, covering everything from what a node looks like to how branching steps get configured. By the end I could move fast on new features without rehashing the fundamentals every time.
A journey with a function step and a randomized split step.
Funnel metrics showing how profiles moved through a journey.
A profile activity log for tracing exactly what happened to an individual customer.
A clear shift to v2
Journeys v2 is now how most customers build on the platform. One stood up a v2 journey in a single day, delivering contextual alerts that weren't possible on the legacy system.
As of Q2 2026:
Learning when to move fast and when to slow down
This was the biggest, longest project I've worked on. Throughout it I learned when the quick version is good enough, and when it isn't.
Cutting scope got features into customers' hands quickly instead of waiting years for one big release. Most of the time that was the right call, but if a cut meant jeopardizing customer trust or shipping something confusing, it wasn't worth it. Deciding to hold event-triggered Journeys in beta was one of those moments.
On the flip side, I've become much faster at gathering evidence. At the start of this project I would have taken extra time to validate every feature, but by the end I was comfortable getting signal on concepts in days instead of weeks.