Where I designed 2FA
I have designed two factor authentication in two families of financial products: login and sensitive operations in a reseller back office system, and registration, card activation and strong authentication in a credit card issuer's app. Some of this is unreleased and confidential, so this article ships without screenshots for now, recording the design tradeoffs in text; images can follow later. The 2FA mix spans email OTP, SMS OTP, authenticators and device binding, and the issuer scenario stacks KYC on top: identity documents, proof of address such as utility bills, and liveness detection.
The waiting problem
The biggest UX risk in verification is not a mistyped code, it is waiting. An OTP waits on email delivery, liveness waits on an algorithm, document review waits one to seven days. Three completely different time scales, too often rendered as the same spinner. My approach gives each wait its own shape: second scale waits get a progress animation with explicit verifying copy; minute scale waits get a countdown and a resend button with its cooldown stated; day scale waits get a status page with the expected range, current progress and what happens after approval.
Working principles for verification UX
A few principles I have verified repeatedly. First, honest errors: say how many attempts remain and when a retry unlocks, because guessing games only manufacture support tickets. Second, fallbacks must exist: a failed scan falls back to typing, an undelivered SMS falls back to email, and a dead verification component must never mean a dead flow. Third, reassurance is designed: explain why you need sensitive data and how it is protected before asking, or people will not hand their ID to a camera. Fourth, 2FA is cross functional design: every step must answer compliance asking is this allowed, engineering asking can this be built, and the user asking do I understand this, all at once.