Esta web utiliza cookies para que podamos ofrecerte la mejor experiencia de usuario posible. La información de las cookies se almacena en tu navegador y realiza funciones tales como reconocerte cuando vuelves a nuestra web o ayudar a nuestro equipo a comprender qué secciones de la web encuentras más interesantes y útiles.
Una de las cosas más difíciles de hacer a la hora de diseñar una aplicación web suele ser tanto la gestión de los usuarios y sus datos como el proceso de registro y de login. Lo primero por los problemas de seguridad y jurídicos que plantea y lo segundo porque parece que nunca se acierta en cuántos datos tenemos que pedir para registrarse y cómo tiene que ser la caja de login dentro de la aplicación y cómo debe insertarse el proceso en una página por la que puedas navegar sin registrarte y no volver locos a los usuarios registrados buscando el login (cosa que suele ser un error común, por poner un ejemplo en un blog de WordPress.com si no entras en él desde la página principal).
Hoy vamos a hablar del proceso de login y más concretamente de la pantalla de login y el registro. Jeff Atwood ha escrito en su blog Coding Horror (dedicado a la programación y al factor humano, es decir usabilidad y programación) un artículo titulado The God login (El login de Dios en castellano). Al artículo le falta una explicación de lo que es el login y su historia que voy a explicar antes de comentar su artículo.
El login viene de los sistemas de tiempo compartido, más conocidos como mainframes, de la primera época de la informática. En aquellos tiempos no había ordenadores personales, sólo terminales de un ordenador más grande. Al principio eran sólo teclados que enviaban órdenes a un soporte donde se guardaban y luego el ordenador las procesaba. Posteriormente ya eran teclado y pantallas tal y como hoy conocemos a los terminales y al haber aumentado la potencia ya permitían la interactividad y el multiusuario.
Resumiendo el usuario hacía login (metía usuario y password y el mainframe los validaba con la lista que tenía), programaba las tareas o cálculos que tenía que hacer y el ordenador los ejecutaba según el tiempo que tenía el usuario disponible (de ahí el nombre de tiempo compartido) y el ordenador se los devolvía cuando los hubiera acabado.
Posteriormente cuando se creó el correo electrónico era similar. El usuario escribía los correos, hacía login en el servidor de correo, los mandaba a la cola del servidor de correo y éste los procesaba. De ahí, las direcciones de correo: usuario@servidor, donde usuario era el nombre con el que hacía login el usuario y el servidor era el servidor que recibía y enviaba sus correos, para saber a qué servidor tenía que dirigirse otro servidor de correo.
Usuario y dirección de correo están muy unidos, si conoces la historia de la informática. De hecho casi se podrían decir que son lo mismo, o que se deben de usar indistintamente que es la afirmación principal del artículo de Jeff.
Explicado esto, vamos con el resto. Jeff nos da una serie de útiles consejos a la hora de diseñar una pantalla de login:
- Permitir al usuario usar su dirección de correo para hacer login – la identidad del usuario acaba siendo el correo, así que aunque le dejemos elegir un nombre de usuario permitamos también que haga login con su dirección de correo.
- Avisar al usuario cuando el correo no existe – los usuarios pueden tener más de un correo y olvidar con cuál de ellos se registraron, así que no está de más avisarles de cuando un correo no está en nuestra base de datos.
- Permitir al usuario cambiar fácilmente entre registrarse y la pantalla de login – muchos sitios han comenzado a colocar juntos el login y el registro porque se han dado cuenta que los usuarios lo perciben como cosas similares
- Usar palabras simples/comunes – hay muchas maneras de poner las pestañas de login y registro: login, entrar, registrarse, crear usuario, etc.
- Probar que se guardan bien los datos en los gestores de contraseñas de los navegadores – Deberiamos probar que se pueden autocompletar el usuario y la contraseña con al menos los 4 navegadores más usados(IE, Firefox, Chrome y Safari) con los gestores de contraseñas integrados que llevan.
- Cuida los errores comunes de los usuarios – Debemos avisar de que el bloquear mayúsculas está encendido y de posibles errores al escribir los dominios de los servicios de correo más habituales.
- Ayuda a los usuarios a elegir contraseñas seguras – Hay muchas escuelas sobre ésto, pero Jeff recomienda contraseñas de 8 carácteres mínimo y comprobar que el password no está en la lista de los 10000 passwords más comunes.
- No te olvides del teclado – Verifica que funciona la secuencia: usuario/correo, tabulador, contraseña, intro.
- Limita el número de veces que el usuario puede hacer login – Normalmente 3 veces suele ser un número bueno de veces que cómo máximo alguien puede intentar acceder legítimamente a un sitio web. Más veces casi siempre será alguien intentando robar una contraseña.
En Torresburriel Estudio apoyamos el rediseño de tu producto digital, con un proyecto de acompañamiento donde aplicamos metodologías de diseño centrado en el usuario. Contacta con nosotros, y cuéntanos tu proyecto. Te enviaremos una propuesta adaptada a tus necesidades y presupuesto.
Hola, Samuel. Antes de nada quería felicitarte por tu artículo, claro, fácil de leer y muy bien estructurado.
Quería comentarte dos puntos que has tratado en el post, y que no comparto completamente:
En primer lugar, hablas de «avisar al usuario cuando el correo no existe»: a mi entender, este punto no debería ser así, por varios motivos: estás dando pistas a tu posible competencia de clientes / usuarios que están registrados en tu web; y además posiblemente estés comprometiendo al usuario, ya que puede que otra persona este comprobando si ese usuario está registrado en esa web por algún motivo y quizás a tu usuario no le interese dejar pistas de que es usuario registrado de tu servicio. Creo que la opción más válida es indicar que «el nombre de usuario o la contraseña no es correcta» (te invito a poner mails de tus amigos o familiares en webs como badoo, meetic, loovo, etc. y verás que sorpresa 😛 )
Y por último, indicar que utilizar una misma página para mostrar 2 formularios (uno de login y uno de registro), puede ser perjudicial y fácilmente confundible para el usuario: cuando me encuentro con páginas así me obligan a perder unos segundos en ojear y pensar cual de los formularios debo cumplimentar… creo que la opción más indicada sería mostrar el login y una acción de registro destacada y visible dentro de esa misma página (pero no abierta).
Hola David S.
Gracias por tu comentario lo primero. Lo que tu comentas es muy interesante, ya que esto son consejos universales o una guía de buenas prácticas como lo prefieras denominar. Luego estos consejos hay que ponerlos en práctica en un contexto de una web o una aplicación y no es lo mismo una web de contactos o de amistad, que una aplicación para una intranet empresarial o una web cualquiera.
En el caso que tú comentas(webs de contactos o de amistad) si que es conveniente que el mensaje sea más ambiguo para preservar la privacidad del usuario, pero siempre sin descuidar que los mensajes tienen que ayudar al usuario a usar nuestra página y que tenga una buena experiencia de usuario.
A lo que Jeff Atwood se refiere cuando dice que tiene que haber dos formularios(uno de registro y otro de login) es que tienen que estar con pestañas. Él pone el ejemplo de The Verge (http://www.theverge.com/login). Si te fijas puedes cambiar de uno a otro como si fueran pestañas en el navegador, lo cual es un tipo de navegación «usual» para un usuario normal de la web actual. Es decir, no se ven los dos a la vez, sino uno cada vez. Si que es verdad que para usuarios inexpertos o que no se den cuenta del mecanismo de navegación les cueste pensar unos segundos hasta darse cuenta de esto.
Espero haber resuelto tus dudas
Otra posibilidad podría ser unificar el login y el registro de la siguiente manera:
Al hacer click en la pestaña nos muestra solo dos campos para login/registrarse
-Usuario / Correo electrónico
-Password
En el caso de que este registrado nos loguea sin más.
En el caso de que no esté registrado nos lleva a la siguiente pág donde se nos pide por favor completar los datos que faltan para registrarnos, donde el nombre de usuario y el password aparecen completados ya que lo hicimos en el paso anterior.
Saludos!
Hola Alex:
Muchas gracias por comentar.
Lo que dices no es mala idea, el problema es que al hacer interfaces de usuario hay una cosa que es preferible no hacer y es romperle los esquemas al usuario. La idea de que el registro y el login son procesos diferentes la tienen los usuarios tan interiorizada que sería como intentar poner los enlaces de color verde y querer que el usuario no se confunda. Yo personalmente no conozco ningún ejemplo de una implementación de lo que dices.
Si la implementas en algún sitio web, házmelo saber y qué tal te ha funcionado, en el caso de que no esté registrado deberías poner la confirmación de contraseña y comprobarla por si el usuario comete algún fallo la primera vez, le salte un aviso.
[…] El login perfecto […]
[…] 12. El login perfecto – Torresburriel Estudio […]