DE-IDENTIFIED CASE
WHAT I CHANGED
The name and logo, now an invented brand
Typography
The color palette
Illustrations and images
Names, IDs and every piece of data
Internal terms in the copy
WHAT I KEPT
The structure and layout of every screen
The flows, step by step
Interactions and states
The research, the decisions and the reasoning
The results, with client figures as proportions
Role
Senior Product Designer, Field research, Usability testing, UX/UI, both sides of the flow
Team
Product Owner (client side), engineering, stakeholders, sole designer
When
Jun–Jul 2026
Status
Approved by engineering and stakeholders.
The problem
A regulated financial service needed to confirm the client's address, without sending anyone to their home. The mechanism was a video call with an advisor, (using a proprietary video-calling tool, but it lacked proper architecture and usability, and failed to inspire confidence). To share the advisor's screen and allow the client to confirm their location on a map, ensuring the correct address and completing the credit process.
The failure was expensive in both directions. Every call that fell apart meant dispatching a person physically, and every customer who dropped out was a process that stalled.
What nobody could say was why. The assumption in the room was connectivity: bad signal, cheap phones, noisy homes. That assumption is what sent me to the field instead of to Figma.
1 in 10
eligible customers completed the verification call
Baseline before the redesign
What I found
I observed three advisors through live sessions with real customers, interviewed them afterwards, and audited the product end to end while it was running.
The first undocumented failure was a blank screen: under a specific condition the call would open to nothing, and neither side could recover. Advisors had built a workaround so routine they no longer reported it, they had stopped seeing it as a failure and started seeing it as a step.
The second was an audio echo everyone had filed as a technical defect. It wasn’t. The verification happens while the customer is already on a phone call, and opening the video room put a second audio on top of it. No audio fix could have removed the echo, because the audio wasn’t broken.
It was a flow-architecture problem wearing a bug’s clothes.
The connectivity theory turned out to explain almost none of it.
KNOWN
The service had been live for months.
Fewer than one in ten calls completed.
When a call did complete, the work got done faster.
The interface had flaws, but nobody knew where.
ASSUMED
The cause was connectivity: weak signal, cheap phones, no Wi-Fi.
Real, but it explained almost none of what happened once a customer said yes.
Field research
THEME 1
Suspected, never pinned down
01
The link opens to a blank screen
Undocumented
02
The way into the call is buried in a menu
03
No on-screen guidance: the advisor talks every customer through it
04
Nothing signals the link comes from the institution
05
Sharing controls invite exposing the wrong window
THEME 2
Not on anyone’s radar
06
Echo: two audio channels run in parallel by design
Undocumented
07
Advisors compensate with workarounds the system depends on
08
The tool sits beside four to six others, integrated with none
09
The suggested script appears after the advisor has already spoken
10
The documented flow differed from what was live
Three decisions
01
Decided: rebuild the welcome screen around the institution’s identity and illustrated faces of people. On the customer’s phone, that meant keeping the institution’s own logo above the app’s name.
Why: the original welcome was a login with a very long number. It looked mechanical and strange, almost like a fake app, and it came on behalf of an institution handling the customer’s money. The app also looked different from the institution’s other apps, even after the redesign, so the logo had to say it was theirs. The blocker was never comprehension, it was trust. In an A/B test, 91% preferred the new screen, and not one of them explained the preference in terms of clarity. Even as illustrations, the faces made it feel like a person on the other side.
On the camera: the call never asked the customer to show anything. The advisor shared a map and the customer only had to confirm, out loud, that it was their address. A video call suggests turning the camera on, so the waiting room says they don’t have to, and the camera starts off.
Discarded
Keeping the existing welcome and fixing only the entry point.
02
Decided: treat the echo as a flow problem and change the sequence that produced it.
Why: the verification happens while the customer is already on a phone call with the advisor. Opening the video room added a second audio channel: if the customer turned on its microphone, the two audios crossed and echoed. It looked like an audio defect, but nothing in the audio was broken. The flow put two audio channels on top of each other and nobody had noticed, so an audio fix would have burned a sprint proving nothing was wrong. Naming it correctly is what made it cheap to fix.
Discarded
Filing it to engineering as an audio defect, which is what it had been called for months.
BEFORE
Two audio channels on every session
1 · LINK SENT
2 · ENTERING THE ROOM
3 · IN THE ROOM
4 · CLOSING
PHONE CALL
Voice call, audio channel 1: open for the whole session
ADVISOR
Offers the call and sends the link
Grants camera, microphone and location. Mutes by hand to stop the echo
Shares the screen from the AV
Closes the tab
CUSTOMER
Receives the link
Enters the room and turns on the microphone
Watches the shared screen
Confirms and leaves
ROOM MIC
Audio channel 2: a second microphone opens on top of the call, and the echo starts
AFTER
One channel: the sequence changed, not the audio
1 · LINK SENT
2 · ENTERING THE ROOM
3 · IN THE ROOM
4 · CLOSING
PHONE CALL
Voice call, audio channel 1: the only audio in the session
ADVISOR
Offers the call and sends the link
Enters a room that opens with audio off. No microphone to manage
Shares the screen from the AV
Ends the session
CUSTOMER
Receives the link
Enters the room with the camera off, and is told they don’t have to turn it on. The microphone is never requested
Watches the shared screen
Confirms and leaves
ROOM MIC
Never opened
03
Decided: add a configuration matrix so the same verification flow could serve other areas of the institution, with different rules per use case.
Why: the underlying mechanism confirm something visually, remotely, with a human on the line wasn’t specific to one process. Scoping it narrowly would have guaranteed a second, nearly identical build within a year.
Discarded
Shipping it scoped to the team that commissioned it.
THE SHARED CORE
As I mapped it
THIS USE CASE
Designed
NEXT USE CASE
Same core, its own rules
Customer microphone
Requested together with the camera
Hidden
Never requested. Audio already runs on the phone call; a second channel is what caused the echo.
Customer camera
Video, switchable
Adapted
Off by default. The waiting room says the customer doesn’t have to turn it on.
Customer screen share
Share my screen, under More options
Hidden
The advisor shares; the customer watches.
Recording
Start and stop recording
Hidden
Off in this configuration.
Report a problem
Under More options
Removed
The phone call already carries it. It reopens if a use case has no parallel call.
Entry screen
Profile and settings come first
Adapted
The customer goes straight to the room, with the institution’s identity. The advisor’s login becomes a welcome.
Advisor controls
Device settings and in-room chat
Adapted
Share, camera, resend link, end. No microphone, no chat.
The result
1 · Welcome
2 · Waiting room
3 · In the call
4 · Done
The customer’s side, on their phone
1 · Welcome
2 · Waiting room
3 · In the call, sharing the screen
4 · Session closed
The advisor’s side, at their desk
rated the redesigned process “very clear”
Usability test, 11 participants
rated it difficult or neutral
Same test
preferred the new welcome screen
A/B test with the same 11 participants
Participant, usability test
What I learned
The signals that moved preference weren’t layout or copy: they were the ones that told the customer who was on the other side. And the most expensive failure in the flow had been invisible for months, because the people living with it had stopped calling it a failure.