Global navigation

Rogers Communications Inc.

OVERVIEW

Users: Rogers support team and Retail agents

Scope: Navigation across Serve Flows, Residential and Wireless

Timeline: 2 years, phased releases

Impact: 10% call time reduction + improved retail engagement

The company and the problem

Rogers serves 20M+ customers across wireless, internet, TV, and streaming. OneView is a mission-critical internal platform used by Care and Retail agents
to manage subscriptions, billing, promotions, and package changes, often while
a customer is on the line or in-store.

OneView was created to replace a fragmented ecosystem of ~15 internal tools, supporting high-frequency workflows where speed and consistency directly impact handling time and service quality. Over time, as multiple teams shipped independently, navigation and interaction patterns became fragmented and complex to maintain. Agents struggled to find key customer information and frequently had to switch tools to complete simple tasks.

Adoption issues made this even harder: reliability gaps and missing functionality led many agents to default to Maestro, a legacy tool that was planned for deprecation. This project focused on reducing fragmentation and friction so OneView could become the dependable, end-to-end experience agents needed.

My role

I led this initiative in collaboration with two designers, partnering closely with the Product Manager and cross-functional teams across Product, Engineering, Content, Research, and Design Systems. I drove alignment and decision-making across lines of business, translating competing requirements into a cohesive navigation strategy and practical guardrails that teams could apply during delivery.

In addition to leadership and coordination, I owned key parts of the design work end-to-end: discovery planning, information architecture, interaction patterns, documentation, and implementation support through development and iteration.

Scope and constraints

Multi-team, multi-LOB environment: navigation decisions affected several product areas and roadmaps.
Operational impact: agents depended on speed and predictability during live customer interactions.
Sustainability: the business needed a scalable way to keep navigation updated without heavy development effort.
Platform transition: one of the legacy tools was planned for deprecation within ~two years, requiring migration of essential functionality into OneView.
Permissions complexity: different roles needed different access, and critical information was inconsistently available across permission levels.

Approach

To build shared understanding and avoid “local optimizations,”

I created two cross-functional workstreams:

DESIGN WORKGROUP

Designers from each team collaborated to map flows, patterns, and gaps, creating a shared foundation for information architecture decisions.

STAKEHOLDERS WORKGROUP

POs from each line of business aligned on priorities, constraints, and ownership, ensuring decisions could scale across teams and remain implementable.

This structure helped us move from opinion-based debate to evidence-based decisions, reduce rework, and keep stakeholders aligned throughout

a long-running initiative.

Discovery and insights

Flow mapping & system diagnosis

We mapped existing agent journeys and documented where navigation patterns diverged, where users lost context, and where tasks required unnecessary page switching. This revealed repeatable friction points that were systemic, not isolated to one feature area.

Data analysis

Partnering with the data team, we analyzed frequency of use by navigation item and identified high-traffic actions that were not represented in the current nav. This informed an MVP roadmap grounded in real behavior, not assumptions.

Permissions and visibility

Permissions were a critical constraint. Different views were required by role, and important information was either hidden from the wrong users or exposed at the wrong level. One example: order and sales visibility impacted agents who were commission-based—managers could see performance, while agents lacked access to track progress against daily or monthly goals. Addressing this required navigation and information architecture decisions that respected security while improving usability.

Decisions and trade-offs

A major trade-off was execution model: there wasn’t a dedicated cross-org team assigned to deliver the navigation change. While my team could focus on this initiative, other teams had tight roadmaps and limited capacity, and their dependencies directly impacted the navigation outcomes.

To make progress, we treated each release as both a product improvement and an alignment opportunity. As new work shipped, we pushed to address related backlog items in parallel, especially those that would otherwise break or weaken the new navigation model. This approach helped reduce fragmentation over time, but it also introduced constraints on pacing and sequencing, since delivery depended on multiple teams working together.

Roadmap and MVP strategy

We created an MVP roadmap that mapped:

Current and upcoming requirements
Agent flows that existed (and those that were missing)
Dependencies and ownership across teams

This roadmap acted as a decision tool to prioritize what mattered most to agent efficiency and to keep future additions consistent with the navigation model.

Solution

The project took approximately two years to reach a soft release. In the first year, the initial design was approved; subsequent requirements introduced new constraints that required optimization and a second redesign.

We delivered a standardized global navigation system across Serve Flows, Residential, and Wireless by:

Establishing a shared information architecture and labelling strategy
Standardizing interaction patterns and navigation behaviours to reduce cognitive load
Defining a scalable structure that supported current needs and future additions
Streamlining key pathways to the most common customer information, reducing unnecessary page switching

Equally important, we aligned teams around a unified direction through collaborative design interventions and practical guardrails that made the system maintainable over time.

Technical constraints and implementation realities

This project faced recurring technical interference. The underlying platform had limitations and ongoing stability work, and some parts of the experience required technical changes outside of design’s direct control. That meant we needed to design with constraints, identify critical dependencies early, and adjust sequencing to match what was feasible to implement without compromising agent workflows.

Delivery model

This was a multi-year effort that progressed through phased releases rather than a single “big bang” launch. In year one, the initial design direction was approved. As requirements evolved and technical constraints surfaced, we iterated, optimized, and ultimately delivered a second redesign that better reflected implementation realities and cross-team dependencies.

Phase 1

1/3

Phase 2

1/2

1/4

Outcomes and impact

Early soft-launch results revealed a 10% reduction in call time, with agents expressing high satisfaction with the new design. Feedback on the Global Navigation was initially mixed; some agents found it user-friendly, while others felt it required too many clicks. Despite early preferences, data showed significant performance improvements. Partner retail stores also experienced increased engagement, with teams favouring Rogers products over competitors due to ease of use and quicker onboarding for new employees.

Early soft-launch results showed a 10% reduction in call time and high satisfaction among interviewed agents. Feedback on Global Navigation was initially mixed—some agents found it required too many clicks—but performance data confirmed meaningful improvements. Partner retail stores also reported higher engagement and preferred Rogers over competitors due to ease of use and faster onboarding.

What I learned from it

This project reinforced that standardization is as much an organizational challenge as a design problem. The biggest leverage didn’t come from perfect screens; it came from creating shared language, decision-making, and repeatable guardrails across teams.

Because a formal governance model wasn’t finalized within my time on the project, I learned how far you can get by putting practical structure in place early: standardized labels, documented IA decisions, shared patterns, and regular cross-team reviews. These lightweight guardrails reduced rework, maintained consistent implementation as new work shipped, and laid the foundation for long-term governance once the final phase is complete.