Contexto del proyecto
Problemas de negocio
Obtener mayor cantidad de usuarios registrados y logueados activos en TN.
Obtener mayor cantidad de usuarios activos en la sección de juegos.
Problemas de usabilidad
Se observaron fricciones a la hora de concretar registros de usuarios, principalmente en el "wall" bloqueante para acceder a los juegos.
Frustaciones en el login para un inicio exitoso.
Desconocimiento sobre cuál era el último método de login utilizado.
Diseño obsoleto y con falta de accesibilidad.
El rediseño completo de este proyecto era elemental para mejorar métricas relacionadas a negocio, y por otro lado también, mejorar la usabilidad y accesibilidad para nuestros usuarios.
Research cuantitativo: Clarity
Entendimiento
El rediseño completo de este proyecto era elemental para mejorar métricas relacionadas a negocio, y por otro lado también, mejorar la usabilidad y accesibilidad para nuestros usuarios.
Análisis
Lo primero que hicimos con toda esta información fue analizar detalladamente como estaba el flujo construido, si se podía ajustar o si era necesario pensar todo desde cero.
Rediseño
Consideramos que lo mejor era rediseñar y tener la libertad para mejorar y proponer un flujo completo, mas organizado, con una mejor accesibilidad y por sobre todas las cosas, que sea sencillo para nuestros usuarios. (personas de +50 años)
Benchmark
Con toda la información obtenida en la etapa anterior, hicimos un benchmark de nuestra competencia y otro más general específicamente de la funcionalidad, para entender como resolvían este flujo, que podíamos usar, y en que nos podíamos destacar.
Detecciones destacadas
Lovable muestra un badge informando a los usuarios cuál fue su último método de inicio de sesión utilizado.
Un medio nacional utiliza un steper para informar al usuario en que paso del registro se encuentra.
Un medio internacional utiliza un input que detecta si el email tiene o no una cuenta creada y en base a eso te lleva al flujo de inicio de sesión o al de crear una cuenta.
Userflow
Teniendo en claro el problema, los objetivos, y finalizado el análisis de como se podían resolver lo que necesitábamos, procedimos a rediseñar el flujo de usuario, el cual nos permitió ver de manera clara todos los escenarios posibles que tenía el usuario.
Frontstage
Pantallas del login/registro
Pantallas de error
Pantallas de éxito
Backstage
Validar email en database
Envío de emails
Manejo de errores
Requerimientos de password
Definición visual
Con los flujos ya claros y definidos, avanzamos con el diseño visual de cada pantalla.
Estructura de flujos visuales
Iniciar sesión
Crear cuenta
Cambiar contraseña
Implementamos el badge de “último usado” para informar al usuario que método de login había usado por última vez. (Previamente se validó con desarrollo si era viable guardar en localstorage esta información)
Rediseñamos el componente de input, agregando label e iconografía informativa sobre el campo que debía completarse.
Mejoramos la funcionalidad “Mostrar contraseña” cambiando el “ojo” por el botón “Mostrar”.
Mejoramos la información de requisitos para crear contraseña, con validación en tiempo real.
Desglosamos el registro en 3 pasos y creamos el componente steper para informar el estado al usuario.
Errores y accesibilidad
Accesibilidad
El modal funciona como role="dialog" con aria-labelledby. Se inicia con foco en el primer input y mensajes marcados con aria-invalid + role="alert", además de tooltips descriptivos (por ejemplo, para los caracteres especiales).
Errores
Diseñamos los estados de error para que sean explícitos y accesibles, evitando mensajes genéricos. Cada input tiene su label asociado, iconografía y un texto que explica exactamente qué está pasando.
Prevención de errores
Sumamos la detección de mayúsculas en el momento de escribir la contraseña, esto puede o no tenerlo nativamente el dispositivo, por eso es que pensamos una solución para que aparezca siempre.
Prototipo en Figma Make
Construimos un prototipo de alta fidelidad que replica la lógica real del login/registro: validaciones de campos, requisitos de contraseña, estados de error y avance por pasos.
Esto nos permitió testear el flujo en Mobile casi como si ya estuviera desarrollado, medir tiempos de tarea y detectar fricciones reales antes de pasar a la etapa de desarrollo.
Dado que el diseño de cada pantalla fue armado con componentes reutilizables, autolayouts e instrucciones claras, el proceso de importar las vistas hizo que el resultado en Figma Make sea prácticamente igual al diseño planteado.
Captura tomada de reporte automático que generamos
con IA en base a todos los datos cargados en el Excel.
Testeos de usabilidad
Objetivo
Validar el uso del muro que exige un registro completo de los usuarios sin cuenta para poder jugar.
¿Qué medimos?
Conversión de tareas
Tiempo
Usabilidad percibida
¿Cómo lo hicimos?
Testeamos a 5 usuarios en Mobile (92% de nuestros usuarios usa Mobile)
Se les presentó un escenario ficticio, para que puedan tener un contexto en el cuál estaban haciendo la prueba. Se armó un guion con tareas para poder verificar la eficacia de la creación de cuentas. Fueron de manera presencial, grabados con audio y captura de pantalla para luego volcar los resultados en un Excel.
También se sumaron preguntas con el fin de obtener información cualitativa.
Las tareas
1. Ingresá al rompecabezas. 2. Registrate (No podés usar Google/Apple). 3. Finalizá el proceso de registro. 4. Jugá.
Testeos de usabilidad
Tarea #01
Ingresar al rompecabezas
Conversión: 100%
Tiempo promedio: 4s
Tiempo mediana: 4s
Todos los usuarios lograron identificar como avanzar en la primera tarea.
Testeos de usabilidad
Tarea #02
Registrarse
Conversión: 60%
Tiempo promedio: 63s
Tiempo mediana: 71s
4 de 5 usuarios completaron campos de login pensando que eran los de registro.
2 no pudieron avanzar sin ayuda.
Testeos de usabilidad
Tarea #03
Finalización del registro
Conversión: 100%
Tiempo promedio: 78s
Tiempo mediana: 73s
Todos los usuarios lograron identificar como avanzar en la tercer tarea.
Testeos de usabilidad
Tarea #04
Jugar
Conversión: 80%
Tiempo promedio: 6s
Tiempo mediana: 6s
Acción inesperada: Al realizar el testeo no podemos validar al 100% esta acción, dado que el envío de email no estaba desarrollado para que le llegue realmente al usuario.
1 usuario volvió a inicio esperando confirmar el email
Otros problemas detectados
No se indican cuáles son los caracteres especiales
Al momento de crear una contraseña no está especificado cuales son los símbolos permitidos que debe contener
Requisitos de contraseña tapados por teclado
En 2 de 5 usuarios se vio como en el momento de crear su contraseña, el teclado les tapaba el último requerimiento, por lo que avanzaron pensando que ya cumplían todos.
Crear contraseña
Al momento de crear una contraseña, se observo que un usuario confundió el wording de “Ingresar contraseña” pensando que no era para crear la misma. El usuario tocó el botón de “Mostrar”.
Jerarquización de problemas - [G] y [F]
El orden se establece a partir de la suma entre la Gravedad y Frecuencia.
Resumen
66,7% -
Completan campos de login pensando que eran los de registro
33,3% -
Requisitos de contraseña tapados por teclado
16,7% -
No se indican cuáles son los caracteres especiales
16,7% -
Crear contraseña wording confuso
16,7% -
Volvió a inicio esperando confirmar email
Criterios (Gravedad)
Impide la tarea
Problema menor / mejora
Iteración de flujo #01
El 67% de los usuarios completaron datos de registro en el login
Propuesta de mejora
Ajustamos la pantalla principal para que el usuario solo vea un input y tenga una única opción de ingreso de datos.
Se diseño un flujo que detecta la información de el email ingresado:
Si el usuario tiene cuenta creada se le da la bienvenida nuevamente y se le muestra el input para que ingrese su contraseña.
Si se detecta que el email ingresado no tiene una cuenta creada, se avanza a mostrar el flujo de registro.
Iteración de flujo #02
Requisitos de contraseña tapados por el teclado
Propuesta de mejora
En este caso, proponemos analizar la posibilidad de hacer que al seleccionar el input de la contraseña la aplicación te posicione la pantalla de manera que entre tanto el input como todos los requerimientos.
Iteración de flujo #03
No se indican cuáles son los caracteres especiales requeridos
Propuesta de mejora
Integramos en el diseño un icono de ayuda que al hacerle hover o tap muestre un tooltip con todos los caracteres disponibles para la creación de la contraseña.
Iteración de flujo #04
Nombre del label y placeholder para crear una contraseña
Propuesta de mejora
Mejoramos el texto tanto del label como del placeholder para que se entienda que es una creación de contraseña y no indicar una previamente existente.
Iteración de flujo #05
1 usuario regresó a inicio esperando confirmar email
Propuesta de mejora
Decidimos sacar el botón de “Ir a inicio” dado que consideramos que no generaba un beneficio concreto.
Es importante mencionar que si el usuario desea salir del registro siempre puede hacerlo desde la “x” o volver pasos atrás con el steper.
Al realizar el testeo no podemos validar al 100% esta acción, dado que el envío de email no estaba desarrollado para que le llegue realmente al usuario.
