At the beginning of 2026, FloatMe was dealing with a growing problem around account verification.

What started as a security initiative quickly became a customer experience problem as well. Users were getting locked out of their accounts, support was handling thousands of related tickets every month, and a bot attack during the 2025 holiday season exposed weaknesses in the existing implementation that could no longer be ignored.

I led the redesign of FloatMe’s verification experience, working closely with Product and Engineering to improve security, reduce support volume, and make account recovery significantly easier for users.

The Problem

On paper, the existing verification flow was simple. A user logged in, received a code via SMS, entered it, and gained access to their account.

The problem was everything that happened when that process failed.

Over time, we learned that a surprising number of users no longer had access to the phone number associated with their account. Some had changed numbers, others couldn’t receive SMS messages, and some existed in account states that made recovery difficult or impossible without support intervention.

If a user lost access to their phone number, the only path forward was contacting support.

That process required identity verification, manual review, and account updates before the user could regain access. Support teams had created processes around it, but the volume had become difficult to manage.

By early 2026, support was handling roughly 5,000 verification-related tickets every month.

Looking Beyond The Symptom

At first, it would have been easy to frame the problem as:

Users aren’t receiving their codes.

The reality was more complicated. The verification system had evolved over time and was heavily dependent on SMS as the primary verification method. Once we started mapping the experience, we discovered multiple user states that could create problems depending on how an account had been configured.

• Some users had verified phone numbers but no verified email.
• Some had verified email addresses but incomplete phone information.
• Others were affected by specific Auth0 limitations that prevented them from moving between verification methods under certain conditions.

The issue wasn’t simply code delivery. The issue was recoverability.

Mapping these states became one of the most important parts of the project because it allowed the team to understand where users were getting stuck and which scenarios required additional support.

Working Within Constraints

FloatMe uses Auth0 for identity verification and authentication. While Auth0 handled the underlying verification technology, we owned the user experience built around it.

The challenge was that the existing implementation relied on Auth0’s legacy verification system, which introduced several limitations. We explored different approaches, including more modern verification methods, but moving to an entirely new implementation would have significantly increased the project’s scope and timeline.

Instead, we focused on solving the problem within the constraints of the system we already had.

This meant understanding exactly how Auth0 handled different account states, where users became blocked, and how we could create recovery paths without introducing unnecessary complexity.

There were several moments during the project where the obvious solution would have been easier if we controlled the entire backend ourselves. Since we didn’t, the work became less about designing new screens and more about understanding system behavior and adapting the experience around it.

Redesigning the experience

The biggest change we introduced was giving users more than one way to verify their identity. Previously, verification depended almost entirely on SMS. After the redesign, users could verify using either SMS or email and switch between methods when needed.

This sounds like a small change, but it solved a large percentage of the issues that support teams were dealing with.

• If a user no longer had access to their phone number, email could become the recovery path.
• If email wasn’t available, SMS could continue to be used.

Instead of forcing users into a support workflow, the product itself provided a way forward.

We also redesigned the code entry experience, improved method switching, refined error handling, and accounted for the different account states we had identified during discovery.

One of the more complex scenarios involved users whose account status prevented them from enabling email verification under certain conditions. Solving those cases required close collaboration with Engineering to ensure the UX matched the technical reality of the platform.

Simplifying Recovery

The most important UX decision in the project wasn’t visual.

It was reducing the number of situations where a user became completely blocked.

Before the redesign, a failed verification attempt often led directly to support.

After the redesign, users had a second verification method available and could recover access on their own.

The result was a much more forgiving system.

Instead of designing for the ideal path, we designed for the moment when things went wrong.

This became one of the most valuable improvements in the entire project because it addressed the root cause of many support requests rather than just treating the symptoms.

Launch & Results

The team launched the updated verification experience shortly after work resumed in January 2026.

We monitored the release closely, tested heavily internally, and made a handful of small refinements after launch. The overall solution remained largely unchanged because internal testing had already validated the approach.

The impact was visible almost immediately.

Verification-related support volume dropped significantly during the first month and continued trending downward afterward.

Before the redesign:

• ~5,000 verification-related tickets per month

After the redesign:

• ~300 verification-related tickets per month

Beyond the support reduction, the project also strengthened FloatMe’s security posture and created a more flexible foundation for future verification methods.

The team left the project with a stronger implementation, fewer support issues, and a clearer path toward future improvements such as passkeys and additional verification options.

What I Learned

This project reinforced something I’ve learned repeatedly throughout my career:

Understanding the problem is usually harder than designing the solution.

The UI work itself wasn’t particularly complicated. The difficult part was understanding the different user states, technical constraints, and recovery scenarios that existed behind the scenes.

Once the team understood those pieces, the path forward became much clearer.

I’m especially proud of how quickly the team was able to identify the root causes, align on a solution, and improve multiple parts of the experience without allowing the project to grow beyond its intended scope.

If I were revisiting the project today, I’d continue expanding the available verification methods and explore newer approaches like passkeys. The foundation is now in place to support that evolution much more easily than before.

At its core, this project wasn’t about MFA.

It was about helping users regain access to their accounts when things went wrong, while reducing the burden on the teams supporting them.

---