Skip to content
Visual IVRFlagship

Designing Visual IVR Experiences

Voice + visual UI + conversational interaction. How audio guidance and an on-screen interface combine to turn long IVR menus into fast self-service journeys.

Client

Multiple enterprise clients · Ubona Technologies

Role

UX/UI Designer — journey, conversation and screen design across client deployments at Ubona.

Platform

Mobile · Voice + Visual UI · Web

Visual IVRConversational UXMobile UXSelf-Service
OverviewContextJourneyUX DecisionsInteractionEdge CasesScreensLearnings

01Overview

Visual IVR is the flagship pattern of my work: a call plus a screen. While the audio menu speaks, the device shows the same choices visually — so users can read, tap and complete tasks instead of memorising a voice menu. It is conversational UX with a visual layer, real application logic behind it, and self-service as the goal.

02Context

Banks, insurers and financial-services companies run enormous IVR trees. Callers hate them: long audio menus, misremembered options, high effort. The business goal was call deflection and containment — letting callers complete real tasks (activate a card, renew a policy, make a payment) without an agent, while keeping a human handoff one tap away.

03User Journey

The Visual IVR interaction loop

  1. 01

    Call lands

    IVR greets the caller with a short, branded audio prompt.

  2. 02

    Visual screen delivered

    A menu or task screen arrives on the phone while the call is live.

  3. 03

    Options shown + read out

    Audio and screen present the same options in the same order.

  4. 04

    User acts

    Tap or speech maps to the same state — no duplication of logic.

  5. 05

    System validates

    Progress and validation states are visual; the audio stays brief.

  6. 06

    Done — or human handoff

    Completion is explicit; agent handoff is always available.

04UX Decisions

01Few options, one action per screen

Voice menus can carry many options; screens should not copy them. Each visual step offers at most a handful of choices and one primary action, so reading and tapping are faster than listening.

02Audio and visual must say the same thing

The prompt and the screen are generated from the same state, in the same order. If they ever diverge, the caller doubts the entire journey.

03Design the exit first

Every screen keeps a visible, persistent path to a human agent. That exit is what makes self-service feel safe, which paradoxically improves completion.

04Thumb-first mobile layout

These journeys run on real phones during real calls. Primary actions sit in the thumb zone, text is readable in one glance, and buttons meet touch-target standards.

05State machine thinking

The journey is modelled as states: validating, success, error, retry, timeout, handoff. Designing all of them before visual polish meant engineers got exact behaviour — and edge cases did not come as surprises.

05Interaction Design

States, transitions and behaviour — not just the happy path.

Loading

Lookup and validation get explicit progress states — 'Checking your policy…' — so the caller never wonders whether the system heard them.

Validation

Inputs (card number, UPI ID, OTP, PIN) validate inline where possible, with the error shown in context and a clear next action.

Error + retry

Failures explain what happened in plain language and always offer a path: retry, change input, or handoff to an agent. Retry counters prevent infinite loops.

Timeout

If the caller goes quiet, the prompt repeats and the screen highlights the current step — never silently resetting the journey.

Success

Completion is explicit: reference number, what happens next, and how to reach the follow-up. The audio confirms, the screen persists it.

Agent handoff

The handoff passes journey context, so the caller never re-explains what the system already knows.

06Edge Cases

Good UX is what happens when things go wrong. Each case: the problem, the user-facing message and the recovery action.

Session expired

Edge case

The screen session dies while the call is still live.

“Your session ended. We'll keep you on this call.”

Recovery: Resume the journey from the last confirmed step without re-entering everything.

Network drop

Edge case

The visual layer disconnects mid-task.

“We lost the visual session. You're still on the call.”

Recovery: Continue in audio or retry the visual session — state is preserved server-side.

Invalid input

Edge case

A card number or UPI ID fails validation.

“That number doesn't look right. Tap to re-enter.”

Recovery: Inline correction with keyboard focus on the invalid field.

OTP mismatch

Edge case

The entered OTP is wrong.

“That OTP didn't match. You have 2 more attempts.”

Recovery: Retry with remaining-attempt visibility; resend option; handoff after limit.

Payment timeout

Edge case

The payment provider does not respond in time.

“We didn't get a confirmation yet.”

Recovery: Never assume failure without checking status — poll, then offer retry or agent.

Agent unavailable

Edge case

Caller requests handoff during an outage.

“All agents are busy right now. Your place is saved.”

Recovery: Queue with position info or schedule a callback instead of dropping the caller.

06bMicrocopy

UX copy exploration — before / after / why. These are proposed directions, not necessarily shipped copy.

Before

The UPI ID entered does not exist or is not registered with any bank.

After

We couldn't find that UPI ID. Check it and try again.

Why: UX copy exploration. The recovery action is explicit, and the user is not blamed for a system mismatch.

Before

Connectivity problems prevent verifying the UPI ID or completing the transaction.

After

We're having connection trouble. Your payment hasn't gone through.

Why: UX copy exploration. Reassures the user about money state before asking them to do anything.

Before

An error occurred while processing your request. Please try again later.

After

Something went wrong on our side. Nothing was charged. Tap to retry.

Why: UX copy exploration. States who is at fault and what state the money is in — the two things people panic about.

07Final Experience

1Step 1
2Step 2
3Step 3
4Step 4
5Step 5

Journey — Call to completion

Journey — Call to completion

The interaction loop: audio prompt, visual screen, user action, system response, next state.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Menu screen during a live call

Menu screen during a live call

Audio and screen present the same options. Primary action in the thumb zone; agent exit always visible.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Validation state

Validation state

Explicit progress while the system checks input — the caller always knows the system heard them.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Error with recovery

Error with recovery

Plain-language failure, state of the transaction, and a clear next action.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

Primary action

Success with reference

Success with reference

Completion is explicit: reference number, what happens next, how to follow up.

Schematic placeholder — add an approved screenshot via data/case-studies.ts

08Learnings

  • Designing for voice + screen forced me to think in states, not screens — audio, visual and logic are one system.
  • The unhappy path is the product: error design and the exit-to-agent are what make self-service trustworthy.
  • Engineers could implement exactly because every journey was specified as states with defined transitions.
  • Small real-world constraints — one hand, one glance, bad network — matter more than visual polish.

Next case study

Insurance Policy Renewal

All workNext case study

← /work · case study · visual-ivr