Path to Native: bringing voice into Zendesk

Context

Zendesk is a category-defining customer service platform, but its voice offering was limited. The Local Measure acquisition allowed Zendesk to bolster its voice offering, becoming fully integrated into the Zendesk product suite for enterprise customers.

Voice initially shipped inside Zendesk as an iframe — the Local Measure UI running inside a window bolted into the Zendesk shell. It was functional, and it got the product in customers' hands, but it wasn't a Zendesk experience. The look and feel was different. The user experience was bad. The interaction patterns were different. Agents switched between two mental models to do their jobs.

The Path to Native initiative aims to fix these problems. The experience had to feel like a native Zendesk experience.

The design challenge

Two audiences, each with different needs.

Admins had to set up and configure voice as part of the broader Zendesk instance — phone numbers, IVR flows, routing rules, business hours, integrations. Configuration-heavy work that needed to live inside Zendesk's existing admin IA without feeling tacked on.

Agents used voice alongside every other Zendesk channel. For them, the integration problem was the hardest — voice is real-time, high-stakes, and unforgiving. A dropped call or a confused transfer has immediate customer consequences. The agent experience had to feel continuous with the rest of their Zendesk workspace, not a separate tool they switched into.

Across both, the design challenge was the same in shape: take an existing, working product and redesign it as though it had always been part of Zendesk. No iframe. No seams. Native conventions, native components, native language.

How I led the work

I joined as the Voice SME. Local Measure's voice product had years of depth Zendesk didn't have in-house, and my job was to bring that domain knowledge into the integration while learning Zendesk's own design language fast enough to lead.

On the design team, I worked with four to five other designers on sub-areas, and partnered closely with the principal designer on the contact centre team. I reported to the design director for contact centre, with significant autonomy over project direction. For screens, flows, patterns, and the broader systems work — from concept through to engineering handover with specs — I was the DRI.

Beyond the craft, I ran the operating rhythm: weekly team meetings, design crits, showcases, Figma file structures set up for multi-designer collaboration. I worked with PMs to set the vision, shape decision-making, and push back on hard timelines where the trade-offs weren't right. I presented progress and direction to non-design executives, translating design work into business terms they could act on.

Where the work landed

The native integration is still in development, with first release planned for Q3 2026. Path to Native is a multi-phase program — the first release establishes the foundation, and subsequent phases will extend it based on customer feedback, usability testing, and ongoing research. What ships in Q3 sets the design language, patterns, and IA that the rest of the program will build on.

What I've taken from the work

Post-acquisition integration is a specific kind of design problem. The challenge isn't usually "how do we design the best version of this" — it's "how do we honour two products' existing conventions without compromising either." Most of the craft is in the judgement calls: when to defer to the acquiring product's patterns, when to push back because the acquired product's approach is genuinely better, when to invent something new because neither side had solved it yet.