Making hierarchy visible in a live enterprise platform

Act-On is a marketing automation platform used by marketing teams in the US to run campaigns, manage contact lists, and segment audiences. After a decade in market, the interface had accumulated a lot of history, and the company began a full product redesign.

I joined that effort through Fifth LLC, working directly with Act-On’s product and design team in Portland. My workstream was the part of the product where users navigate hierarchical data: lists, segments, and the subsegments nested inside them.

This was one of my first major pieces of work after being promoted to Senior Product Designer.

The existing list view made structure something you had to read rather than see.

Folders and lists carried identical visual weight, so nothing distinguished a container from its contents at a glance. The expand controls were small and low-contrast, which made the hierarchy hard to even locate. Every row ran double-height to accommodate a timestamp line, so the view was low-density and flat at the same time, a poor trade in both directions. And once a branch was open, nothing marked depth. Three levels in, users had lost their position.

The practical consequence: finding a subsegment belonging to a particular segment meant hunting through the list rather than scanning it.

Three things shaped every decision:

I wanted to see how comparable platforms solved this. I couldn’t. Competitors’ products sit behind customer logins, so direct comparison wasn’t available.

Rather than stop there, I went looking for the same problem shape somewhere I could actually study it: any product where users navigate deep, arbitrary-depth hierarchy without losing track of what belongs to what.

I found it in Reddit comment threads. Threads run to significant depth, and readers stay oriented through three devices working together. Indentation, a subtle background shift by level, and lines connecting a reply to its parent. Different domain, same problem, solved well and at scale.

That became the basis for the direction I wanted to test.

Version A adapted the threaded model. It used nested hierarchy with depth expressed through background shift, and hover lines connecting a child row to its parent, rebuilt to fit Act-On’s design system and the workflows around it.

Version B took the conventional enterprise approach. A standard expandable tree table with dedicated expand and collapse controls, revealing subsegments inside a structured block on open. More explicit, more predictable, more familiar to anyone who has used enterprise software.

I had a preference. I didn’t have certainty. When I said as much in review, Act-On’s Head of Design was direct. If you’re not sure which one works for our users, go and find out.

The product was already live, so there was an active user base to draw on. Act-On recruited five existing customers who used the platform daily in their own work.

I ran moderated sessions with a single task. Find the subsegment that belongs to a given segment. I watched the route each person took, where they hesitated, and where they went wrong. Alongside that, I ran 5-second tests to check what people understood about the structure on first sight.

Version A won. It was the direction I’d expected to win, and the sessions showed why. The connecting lines and depth shading answered “what does this belong to?” without the user having to work it out.

Nothing surprising surfaced. Both versions were usable. The difference was how quickly people got oriented, which was the whole point of the exercise.

Version A shipped and is live to Act-On’s customers. The platform sits behind a login, so the screens here are from the design files rather than production.

Alongside the table, I built two foundations that went product-wide.

The most valuable thing I took from this project was learning how to redesign a live product without disrupting the people using it. Rather than replacing everything at once, we introduced change incrementally so the platform stayed operational throughout.

It also taught me how much of design work is engineering collaboration. I worked alongside the developers through implementation. I explained the reasoning behind decisions, adapted where technical constraints required it, and checked that what shipped matched what was intended.

What I’d do differently: bring engineering in earlier. Several design decisions could have been feasibility-checked sooner, which would have saved implementation rounds later.