​The context

The first access is more than a technical step: it’s the user’s very first encounter with the platform. It’s a decisive moment to build confidence and provide clarity. When this experience fails, the impact goes beyond a simple interface error — every barrier increases the chance of abandonment.

While reviewing the initial authentication flow, I identified inconsistencies that could harm the experience at this crucial stage.

The problem

The flow originally proposed by the business team seemed straightforward: request the user’s email and send a verification code. However, upon reviewing each step, I noticed issues that could easily confuse and frustrate users:

Step 1: The user enters their email and is informed that a verification code will be sent — naturally assuming it will arrive by email.

Step 2: On the following screen, the system informs that the code was sent via SMS, even though no phone number was requested.

Step 3: If the email entered is incorrect or not registered, the system provides no feedback. The user remains stuck on the same screen, unsure if the internet connection failed, if the system crashed, or if they made a mistake.

​

As Don Norman explains in The Design of Everyday Things:

​

“If I do something expecting a result and nothing happens, I am apt to interpret this lack of informative feedback as an indication that I didn’t do the action correctly... Who is at fault: me or the thing? We are apt to blame ourselves, especially if others are able to use it.”
 

For the user, the sensation is like knocking on a door and hearing no answer — total absence of feedback, confusion, and the risk of giving up.

The analysis

To structure my evaluation, I applied Nielsen’s heuristics, highlighting key conflicts:

• Visibility of system status: no feedback about errors or progress.

• Consistency and standards: promise of email delivery, but actual delivery via SMS.

• Error prevention: lack of warnings or validation before submission.

• Help users recognize and recover from errors: absence of clear and actionable messages.

• User control and freedom: no option to correct or restart the flow easily.

These weren’t minor details — they were significant barriers to the user experience.

Initial proposal

My first proposal was to align expectations with execution:

• If the channel requested is email, the code should be sent by email.

• If the code is to be sent by SMS, then the phone number should be requested instead.

• If the email entered is incorrect or not registered, the system should provide a clear error message and allow the user to correct it.

This simple reformulation required no complex technology but would restore trust, clarity, and predictability in the journey.

Technical and business limitations

When I presented the solution, the Product Manager pointed out two restrictions:

• Cybersecurity concerns: the security team feared that displaying specific error messages could help attackers discover valid email addresses.

• Dual validation: the business team wanted to validate both email and phone number at the same time, which is why the flow requested email but sent the code via SMS.

Counterproposal

Considering the restrictions, I proposed an alternative that reduced friction while still respecting security and business requirements:

• Make the communication clearer from the very first screen, explaining that the code would be sent by SMS.

• Provide upfront guidance on why the email is being requested and what the user should expect next.

Although this counterproposal didn’t completely eliminate the usability issues, it offered a minimally viable experience, reducing confusion and aligning expectations.

Expected impact

If implemented, the initial proposal could:

• Reduce user frustration.

• Lower abandonment rates.

• Increase conversion from leads to active users.

The counterproposal, while less transformative, would still improve clarity and reduce doubts within the given constraints.

The documentation of both proposals remains available for future consideration.

Confidentiality note

This case is protected by a Non-Disclosure Agreement (NDA). Therefore, visual representations and texts have been adapted to preserve proprietary information.

Conclusion

In real projects, the best user experience is not always prioritized. Technical and business constraints are part of reality, and the designer’s role is to find solutions that balance these forces. Even when the ideal solution cannot be implemented, proposing alternatives that minimize friction and maintain clarity is essential to preserving user trust.