Conversation Insights

Users are Air Canada's contact centre managers who used insights to identify emerging customer issues, then traced those issues to specific calls and operational patterns to understand where they were occurring.

By surfacing with data scientists, I found that teams combined two complementary types of data:

In order to understand how users approached analyzing customer issues, I conducted 6 interviews with team members. I found that insights were rarely consumed in isolation. Instead, they served as starting points for a broader analysis into their operational metadata.

The teams consistently followed this investigation workflow:

I anchored the experience around charts because teams needed to spot patterns before deciding what to investigate. I prioritized the metrics stakeholders already used to identify issues, such as changes in topic frequency and sentiment.

I placed operational data below the insights so teams could move from identifying an issue to tracing it back to specific queues, routing profiles, and agents. This created a direct path from insight to investigation.

I made date and column filters shared across the charts and table because scoping was the first step in every investigation. This let teams establish their context once and carry it across both information layers.

I designed Overview as the starting point for investigation. It surfaces operational metrics and scannable insight cards so teams can quickly identify where attention is needed before digging deeper.

I replaced the trend-line chart with insight cards because teams wanted to know which issues mattered right now, not just how they changed over time. Instead of forcing every issue into one template, I designed each card around the question it needed to answer.

I designed Table View for the deeper investigation. It connects insights to individual calls and exposes the operational attributes teams needed to trace issues across queues, routing paths, and agents.

With 60+ attributes, a fixed table made users scroll through information they didn't need. I introduced Manage Columns so each team could bring the attributes relevant to its investigation into view.

I replaced the reused chip pattern with a query-based filter because investigations rarely relied on a single condition. The new pattern let teams layer conditions across customer and operational data while keeping filters shared between Overview and Table View.

Sustained internal use and external interest supported a renewed client contract and generated new feature requests (under NDA), reinforcing the platform's long-term value beyond the initial engagement.

Designing for power users changed how I think about “better” design. Conversation Insights served only 20–25 users, but they were power users who cared less about delight and more about having the right information and affordances to do their jobs. Throughout the project, I often saw opportunities to make the interface dramatically more polished, but I learned that improving the interface isn't automatically improving the product. In this context, the best design was often the one that gave users exactly what they needed, without adding anything they didn't.

I learned to design with business momentum, not against it. Conversation Insights had to move quickly, and development had already started before I could fully shape the experience. That was uncomfortable at first, but I learned that a rigid design process isn't always the right response to a fast-moving business. My role was to keep the product moving while creating enough space to observe, reason, and improve the experience as we went. Speed didn't mean abandoning design; it meant being more deliberate about where design effort mattered most.

I learned to bring engineering into the design loop early. The insight cards were a custom interaction, and I knew they would require engineering work beyond the existing component system. By keeping engineering involved early and sharing the direction before the design was finalized, I could surface technical constraints sooner and give the team time to plan for what needed to be built. The result was less handoff and more shared ownership of the experience.