Whiteboard challenge

Login Code: ending the resend loop

A waiting state for the security code step of a banking app login.

FormatWhiteboard exercise

PlatformNative mobile

DateOctober 2026

Three screens of the Cherry banking app: the log in screen, the security code screen with a countdown and a locked resend button, and the timeout screen where resend is active again

The challenge

Redesign the security code step of a banking app login. Users say they tap resend several times before a code arrives. Cherry is a made-up bank that I used for this exercise.

Diagnosis before design

The complaint is that the code does not arrive on the first try. I separated what the user sees from what he concludes. He sees that he tapped, no code came, he tapped again several times, and then a code came. He concludes that the first one was never sent. From his side of the screen he has no way to know which tap produced the code that arrived.

That left two places where the problem could be.

Between his tap and our handoff to the SMS provider. Nothing on screen tells him a request is in progress, so he taps again.
Between the handoff and his phone. The carrier is slow or drops the message. No screen change fixes that.

On a real team I would check the send logs first: one message per tap, and whether each was delivered or failed. In this exercise I had no logs, so I stated my assumption and designed for it.

My assumption: the text is delivered, but each extra tap sends a new code and cancels the previous one. His own tapping is part of the failure, and he taps because the screen gives him no feedback.

A waiting state for Cherry clients who can't log in, to end the repeated tapping caused by no feedback between the tap and the handoff.

I deliberately left the carrier delivery problem to the SMS provider team.

One user, one situation

Ali is at home at 11:50pm. He just remembered his electricity bill.
He has ten minutes before a late fee.
He is on good wifi with a full signal. I chose that on purpose: if the code still takes four taps, the cause is on the app side, which is the problem I committed to.

Pain points and priorities

Frustration	Decision	Why
No sign that his request is in progress, so he keeps tapping	Solving	It is what stops him logging in tonight, and the app team owns it.
A code is required at every login	Left out	It is a security requirement and it works as intended.
“Remember me” does not save the password	Left out	It saves the Login ID by design. It annoys him, but it does not block the login.
The text message is slow or never delivered	Left out	It belongs to the SMS provider team.

The flow

He opens the app. His Login ID is already filled in, because “Remember me” is on by default.
He enters his password and taps “Send security code.”
The waiting state starts: the screen says where the code was sent, a 30 second countdown runs, and resend is locked.
If the code arrives, the app fills it in. He is logged in and pays the bill.
If 30 seconds pass with no code, the screen says so and resend unlocks. He taps it and the waiting state starts again.
After a second timeout, the screen offers a phone call or an email, so he is never stuck.

The key screens

Log in. One primary action. The button names what happens next: “Send security code.”
Waiting. The largest element is the “Code sent” card with the live countdown, because that reassurance is what stops him tapping. The locked button shows three signals and never colour alone: a muted fill, new text (“Resend in 0:24”), and a spinner.
Timeout. The card changes to “The code didn't arrive” and the button returns to full colour with “Resend security code.” It also tells him the first code will stop working.

The three Cherry screens side by side: log in with a saved Login ID, the waiting state with a Code sent card, a 0:24 countdown and a locked Resend button, and the timeout state with an active Resend security code button

Three questions I had to answer

Why lock the button when he is in a hurry? Every extra tap may send a new code and cancel the previous one, so the tapping is part of what breaks the login. The lock protects his request, and the countdown tells him it is working.
Why 30 seconds? It is a starting assumption, because most carriers deliver a text within that window. I would set the real number from our delivery data. If 95% of codes arrive within 20 seconds, the countdown becomes 20.
Is the call or email option out of scope? Delivering the text is the carrier's job. Not leaving Ali stuck when it fails is a design job, so it stays in.

Edge cases

His phone storage is full and the text cannot arrive. After the second timeout he can get the code by phone call or email.
The text is never delivered. The same second route gets him in tonight. The delivery failure goes to the SMS provider team.
He cannot type or copy the code. The app reads the incoming text and fills the code in, and “Paste code” sits beside the field.

How I would know it works

The share of login attempts that end in a successful login within two minutes of the first code request.

What I would do differently

My first attempt opened with the solution, a disabled state for the button, before I had asked whether the code was being delivered at all. I redid the exercise starting from the cause.
My first metric was taps per login. A locked button forces that number down even if nobody logs in faster, so I replaced it with a number my own design cannot fake.
The whole design rests on one assumption. Before building it, I would confirm in the send logs that extra taps cancel earlier codes.
Next I would tune the 30 seconds against real delivery times.

The screens were drawn with Claude from my design decisions. Cherry is a made-up bank, and the Login ID and phone number are sample data.

All whiteboard challenges →