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 (RozieAI generated insights and AWS Connect attributes):

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.

Over a few weeks of feedback calls, I noticed teams consistently bypassed the interactive charts and went straight to conversation records. When I looked closer at what they actually wanted, it wasn't complex: for a topic like "Bookings," they just wanted to see the label and its call count, like 1,345 calls. That was the insight. They didn't need to hover across a trend line or compare it against other topics to get there.

The chart I designed assumed users wanted to explore how an issue moved over time: is this topic trending up, how does it compare to others this week. But for a lot of what teams needed first, the question wasn't "how is this trending," it was "what are the biggest issues right now, and how many calls does each represent." I'd designed for exploration when what was needed, at least as a starting point, was a direct, scannable summary.

The filter pattern we reused to hit the initial launch, built originally for a product with simpler filtering needs, started breaking down as investigations grew more complex. During the bi-weekly calls, I watched users apply several filters, then struggle to relocate a specific one they'd already set among the chips stacked across the toolbar. Each chip showed only a count ("Primary Topics: 12 selected"), so once five or six were applied, users had to open chips one by one to find the one they actually wanted to check or adjust.

The deeper issue wasn't just the pattern itself; it was what the pattern was doing to the page. Filters had grown to occupy as much visual space as the data they were meant to scope. That inverted the priority of the dashboard: filters are an affordance to control what data is visible, not the content users came to see. Once filtering started competing with the charts and table for attention, the product was asking users to work through the tool before they could get to the information.

Another gap that surfaced during feedback calls was that teams relied on operational metrics, like call volume and resolution rate, to decide whether an issue needed attention in the first place. This wasn't something I'd cut for time; it was something my discovery interviews hadn't surfaced. My original interviews focused on how teams moved through an investigation once they'd identified an issue worth digging into. What I hadn't fully asked was: how do you decide something is worth investigating at all? That earlier decision point turned out to depend heavily on these operational numbers, and it was a blind spot in my initial research scope rather than a deliberate tradeoff.

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.