The remote and the keyboard were both working against people.

Grounded in evaluation, not assumption.

Before proposing solutions, I conducted a heuristic evaluation of the CANAL+ leanback experience, reviewing the existing interface against established usability principles. The evaluation surfaced issues across six areas:

Looking at how others were solving the same problem.

Alongside the heuristic evaluation, I researched current UX and UI trends relevant to leanback and connected-device experiences:

What users told us directly, and what they told the world.

A discovery study and a review of public app store feedback gave two complementary views of the same underlying experience, one from guided conversations, one from unprompted public complaints.

Two concepts, evaluated against the same criteria.

With the research pointing at two distinct friction points, search input and remote control, the process branched into two parallel concepts rather than forcing a single solution to cover both. Each concept was evaluated against the same two questions: does this meaningfully reduce friction for everyone, and does it specifically help people excluded by the current remote-first design?

From research findings to early structure.

With the friction points and direction confirmed, wireframes for both Mobile Companion and Hand Gestures mapped out the core flows at a low level of fidelity, the notification handoff, the search input screen, and the gesture recognition states, before any visual design work began.

Nobody wants to type a show title with a remote.

Typing long search queries using a directional remote and an on-screen keyboard is slow and frustrating, every letter is a deliberate, multi-click action. Mobile Companion solves this by moving the typing (or speaking) off the TV entirely.

When a user selects the search bar on the TV, their phone receives a notification letting them know they can now search from their phone instead, using either text or voice input. The TV remains the display surface, but the phone becomes the input surface, replacing slow remote-and-keyboard typing with the kind of fast, familiar typing or speech people already use every day.

Notification triggered on selection

Tapping the TV search bar sends an instant phone notification, so the handoff to mobile input feels like a natural next step, not a separate setup process.

Text or voice, user's choice

Once on the phone, users can type using a full keyboard or speak their search, both far faster than remote-based input.

An accessibility win, not just a convenience one

For users with limited dexterity or difficulty with small on-screen keyboards, moving input to a familiar phone keyboard or voice removes a major barrier to finding content.

Some actions don't need a remote at all.

Hand Gestures lets users perform the most common remote actions using hand movements alone, no device in hand required. The gesture set was kept deliberately small, covering only the actions people reach for most during everyday viewing:

Volume: increase & decrease

A directional gesture adjusts volume up or down without touching a remote.

Playback: pause & play

A single clear gesture toggles playback, covering the most frequent in-session action.

Navigation: rewind & fast-forward

Directional gestures let users skip back or ahead, mirroring the most-used remote buttons.

Keeping the gesture vocabulary limited to these six actions meant the system stayed easy to learn and remember and like Mobile Companion, it doubles as an accessibility feature, giving users who struggle to hold or operate a small remote a viable alternative way to control their viewing.

Why not just redesign the remote itself?

An earlier direction explored simplifying the physical remote — fewer buttons, better grouping, clearer iconography. It was a reasonable fix, but it was still a fix to the same object causing the frustration in the first place. It also did nothing for the typing problem, which was the more acute pain point in the research.

We moved away from this in favour of Mobile Companion and Hand Gestures because both removed the remote from the equation entirely for their respective tasks, rather than making a flawed input device marginally less flawed.

Two concepts, one shared win.

Both concepts addressed the brief from a different angle — one rethinking input for search, the other rethinking control for playback, but landed on the same underlying outcome: reducing dependency on the traditional remote made the experience better for everyone, and substantially more usable for people the existing remote-first design excluded. As a concept-stage initiative, the win here was strategic clarity rather than measured impact giving the business two distinct, accessibility-forward directions worth prototyping further.

A platform migration is invisible to the business, until adoption stalls.

Defining what value actually looked like, for the customer and the business.

Before designing anything, the team mapped out what a smooth migration was actually worth on both sides. For customers, ease of transition meant less frustration and a faster learning curve; confidence and control meant fewer errors and a sense of mastery over the new platform; convenience meant finding features quickly instead of searching or calling in.

For the business, the same migration carried clear commercial weight: higher feature engagement, fewer customers leaving, fewer support calls, and stronger revenue through better-used paid services like loans and credit, all riding on whether customers actually discovered what OB4B offered them.

Designing for discovery, not just documentation.

The brief wasn't to explain everything that had changed it was to make discovery itself feel effortless. That meant driving awareness (making features visible and easy to find), encouraging exploration (a welcoming experience that motivates users to look around rather than stick to the one flow they already know), and building retention through growing confidence in the platform's value.

We landed on coachmarks lightweight, contextual overlays that point directly at features in the moment a customer might look for them, rather than front-loading everything into a tutorial nobody reads. This followed established guidance on instructional overlays: present one hint at a time, at the moment it's relevant. Cognitive load research suggests people can hold roughly three to four new pieces of information at a time, so hints were paced deliberately rather than dumped on customers all at once. Coachmarks were also built with flexibility in mind customers could skip or revisit them, keeping control in their hands rather than forcing a fixed walkthrough on everyone.

Contextual guidance, placed at the point of discovery.

Surfaced where customers would naturally look

Coachmarks appear at the point a customer would plausibly explore a feature, rather than as an upfront tutorial standing between them and their task.

One hint at a time, with the choice to skip

Each coachmark addresses a single feature, respecting short-term memory limits and customers can dismiss or revisit it, keeping the experience in their control rather than a forced walkthrough.

Visually distinct from the underlying UI

Coachmarks use a clearly different visual treatment from the platform itself, so customers immediately recognise them as guidance rather than mistaking them for new interactive elements.

Why not just send a "what's new" email instead?

An early option was a static migration guide or email summarising OB4B's new features, sent out once when a batch of customers moved over. It would have been far cheaper to build. But it asked customers to read and remember a list of features before they ever needed them — exactly the wrong moment to teach something. By the time a customer actually went looking for a specific capability, that email would already be forgotten or unread.

We moved away from this in favour of in-context coachmarks because discovery needed to happen at the point of intent, not before it.

A migration that customers could feel confident navigating.

Coachmarks gave migrated customers a low-friction way to discover OB4B's capabilities without needing a support call or a forgotten onboarding email. The approach was designed to drive the three outcomes the brief called for: more visible features driving awareness, a more welcoming experience encouraging exploration, and growing platform confidence supporting retention directly reducing the risk of customers drifting toward competitor banks during the migration window.

Every switch began with a wait.

Mapping the journey from both sides of the call.

Working alongside a Solutions Specialist gave the project a view into both ends of the existing process, the customer experience of waiting on a call-back, and the operational reality of what staff were handling on the other end. That dual view shaped the brief: this wasn't only a customer experience problem, it was a workload distribution problem too.

Mapping the existing call-based journey end to end surfaced exactly where the friction sat not in any single step, but in the complete absence of a path that didn't require a live conversation.

Designing for two very different starting points.

The flow had to work for two distinct situations — a brand new customer switching their primary banking relationship to FNB, and an existing customer moving a single product, like a loan, across from another bank. Rather than building two separate flows, the process focused on identifying the shared backbone both situations needed: initiation, document handling, and status visibility then branching only where the underlying banking process genuinely differed.

A self-serve flow that puts timing in the customer's hands.

Customers can now switch a service or product to FNB directly from their mobile device — whether they're new to the bank or an existing customer moving something like a home loan or vehicle finance across. The flow was designed to be quick, guided, and transparent from request to resolution.

A visible status tracker replaced the old black box. Instead of wondering whether anything was happening behind the scenes, customers could see exactly where their switch stood at any moment — removing the need to call in just to ask "what's happening with my application."

Switch initiation, on demand

Customers start the switch whenever suits them no need to wait for a call-back window or banker availability.

Built for both new and existing customers

The same flow supports switching an entire banking relationship or moving a single product like a loan from another bank to FNB.

Status tracking, end to end

A visible progress tracker shows where the application stands at every stage, replacing the anxiety of silence with clarity.

Why not just speed up the call centre process instead?

An early option on the table was to streamline the existing call flow — shorter call scripts, fewer transfers, faster call-backs. It would have eased pressure on staff without touching the app at all. But it still required the customer to be available at the same time as a banker, and it did nothing for the anxiety of not knowing where an application stood in between calls.

We moved away from this in favour of a self-serve flow because the core problem wasn't call efficiency, it was that customers had no control over timing or visibility at all.

A win for customers and the business.

By shifting control to the customer, the feature let people initiate and track a switch any time, without waiting on staff availability and freed up call centre staff to focus on conversations that needed a real person, supporting their KPIs in the process.