INTRODUCTION
Una demostración de inicio de sesión suele terminar en el momento agradable: el dispositivo reconoce a su dueño, la cuenta se abre y nadie escribe una contraseña. La demostración más reveladora empieza al día siguiente, con un teléfono perdido y una persona que necesita entrar con urgencia. ¿Qué le permite hacer el producto?
Las passkeys pueden facilitar la entrada. El diseño también debe resolver el regreso. Para un equipo de producto, la recuperación necesita decisiones, explicaciones y un final definido. Un pequeño enlace que diga «Probar otra opción» no puede sostener una política que todavía no existe.
Distinguir el dispositivo perdido de la cuenta inaccesible
El documento de FIDO Alliance de enero de 2024 explica que las passkeys sincronizadas pueden seguir disponibles en dispositivos compatibles. Perder el acceso al proveedor puede exigir otra vía. Las vinculadas a un dispositivo tienen otras necesidades de respaldo. La pregunta práctica es qué acceso conserva la persona.
Esa distinción debe orientar el primer paso. Alguien que aún tiene un método operativo necesita volver con rapidez. Quien no conserva ninguno necesita otro proceso. Someter a ambos a la misma lista de preguntas desperdicia el tiempo del primero y crea expectativas falsas para el segundo.
Definir la política antes de pulir la pantalla
Imaginemos un portal de clientes que contiene archivos de proyectos. Un cliente cambia un teléfono averiado y ya no puede entrar. El equipo ha diseñado una pantalla atractiva, pero nadie ha decidido si soporte puede restablecer el acceso, qué pruebas acepta o quién resuelve un caso dudoso.
La interfaz ha llegado al límite de una decisión organizativa. Añadir un mensaje tranquilizador no la completa. Escriban quién se responsabiliza del caso, qué puede esperar el cliente y cómo se comunicará una demora. Seguridad debe determinar las reglas de verificación; producto debe hacerlas comprensibles.
Pongan la política a prueba con una situación incómoda. ¿Qué ocurre si el cliente escribe desde una dirección nueva? ¿Y fuera del horario de soporte? Una revisión útil sigue el caso hasta el regreso seguro o hasta una explicación clara de por qué no puede continuar. Terminar en «Solicitud recibida» deja invisible el trabajo difícil.
Hacer que las alternativas se entiendan
Una página de recuperación debería permitir elegir una acción adecuada sin conocer la arquitectura de autenticación. Describan para qué situación sirve cada opción. Eviten una fila de botones igualmente destacados cuyos nombres solo entienda el equipo técnico.
Mantengan el vocabulario entre inicio de sesión, ajustes y soporte. Si los ajustes hablan de passkey, cambiar de pronto a «credencial de seguridad» añade otro acertijo. Expliquen también cuándo una acción abre un servicio diferente o requiere tener otro dispositivo cerca.
Hay una tensión real: mostrar todas las opciones puede abrumar a una persona preocupada; ocultarlas tras un enlace vago puede dejarla bloqueada. Empiecen por la situación más probable y hagan localizables las demás vías. Prueben la elección con alguien que no haya visto la demostración exitosa.
Tratar la recuperación como un límite de seguridad
Las recomendaciones de FIDO publicadas el 6 de febrero de 2019 sitúan la recuperación dentro del diseño de autenticación. Una alternativa cómoda puede debilitar la garantía del método principal. La elección de pruebas necesita una política deliberada.
Para la interfaz, la consecuencia es concreta: no prometan restauración inmediata cuando podría haber una revisión. Muestren el siguiente paso y el canal de comunicación previsto. Expliquen las restricciones de forma útil. Quien comprende lo que sucede tiene menos motivos para repetir solicitudes o improvisar por canales de soporte ajenos al proceso.
Probar el regreso y lo que sucede después
Organicen una simulación con diseño, soporte y seguridad. Utilicen tres casos ficticios: otro dispositivo todavía funciona; ningún método funciona; la persona duda de qué cuenta utilizaba. Pidan a cada participante que identifique la siguiente acción usando solamente la pantalla y la política establecida.
Continúen después de recuperar el acceso. ¿Puede el cliente revisar cómo inicia sesión? ¿Entiende qué acceso anterior requiere atención? ¿La confirmación distingue una recuperación completada de una solicitud en estudio? Son criterios de aceptación del producto, no detalles ornamentales.
Antes del lanzamiento, asignen a alguien la responsabilidad de recorrer el caso completo. Registren las decisiones que faltan y resuélvanlas junto con el camino habitual. El diario de Blanche ofrece más análisis sobre la relación entre las decisiones de interfaz y la entrega del producto.
Fuentes consultadas el 9 de noviembre de 2026. Este es un análisis permanente de diseño de producto; las recomendaciones citadas no se presentan como un lanzamiento nuevo.