Validating a unified access flow before development through usability testing.
ClientMovistar
Year2022
ScopeUsability testing / Prototyping
Context
Movistar aimed to create a unified access experience across multiple user types, products and services.
The challenge was to validate an architecture capable of integrating different types of accounts, products, and authentication methods within the same flow and reducing friction before implementation.
I conducted remote user testing to validate a proposed flow from Movistar's UX team.
The problem
The complexity of the project was not only in the screens, but in how users could understand the system logic and the relationships between accounts, lines, products, and authentication methods.
The flow had to account for:
Individual and corporate users.
mobile lines and home products (WiFi, TV).
own and third-party products.
SMS authentication, username and password.
multiple identity verification methods (KYC).
accounts associated with DNI (Individuals) and CUIT (Companies).
The main challenge was to validate whether users understood:
How to access their services.
What they could manage within the same session.
How the associations between accounts, lines, and products worked.
Methodology
18 moderated remote sessions with individual and corporate users to validate the proposal received from Movistar.
I participated in moderating the sessions and analyzing findings to identify pain points, validate flows, and uncover improvement opportunities.
Functional prototype (HTML, PHP, JS)
For this project, I developed a high-fidelity functional prototype based on the Movistar team's designs. Due to the complexity of the flows and the limitations of traditional prototypes, I built it in HTML, PHP, and JavaScript, capable of replicating production-like conditions.
The prototype-building process itself also helped detect inconsistencies and opportunities to improve the flow documentation, significantly increasing the quality of the insights obtained during the tests.
Unlike a traditional prototype, this environment made it possible to:
Real interactions to be simulated: interaction with form fields, states, validations, and errors.
Real SMS to be integrated: users received codes on their own devices.
A more realistic performance to be evaluated: load and response times similar to production.
Key findings
Many of the issues detected were not related to visual UI but to mismatches between users' mental models and the system logic.
Users did not always understand when they should log in with their own data and when with the service holder's data.
Users interpreted labels very literally. “Add more lines” was understood only as adding mobile lines.
The majority accessed via SMS and avoided the traditional login with username and password.
Users often assumed something had gone wrong when the flow behaved differently than expected.
The concept “DNI, CUIT or both” proved ambiguous within users' mental models.
Results
The validation process made it possible to:
Detect conceptual friction before development.
Redefine labels and the logic for grouping services.
Confirmed SMS as the primary authentication method.
Identify specific limitations in corporate flows.
Improve feedback and operational clarity in critical scenarios.
Conclusions
Early validation made it possible to detect structural friction before implementation and make product decisions backed by real user behavior.
The use of a functional prototype was decisive: by replicating conditions close to production, users interacted with the system genuinely and the quality of the findings obtained increased significantly.
The study confirmed that the overall architecture was solid and did not require structural redesign. The main improvements should focus on communication, feedback, and the visual clarity of the flows.