Cuando un usuario llega a una página web puede tener múltiples objetivos, entre ellos desde querer simplemente consultar información hasta tener un objetivo claro de comprar un producto, por ejemplo en un e-commerce.
Enfocándonos en este último aspecto, el de adquirir un artículo, el objetivo del usuario no es rellenar un formulario web.
Repito. “El objetivo del usuario no es rellenar un formulario web”.
Éste lo que desea es comprar un producto o un servicio, ni más, ni menos, y cuanto más fácil sea para él hacerlo mejor experiencia se llevará, lo que comúnmente llamamos experiencia de usuario. Su objetivo es ese, y el hecho de que exista un formulario web de por medio es debido a una necesidad interna de la empresa que debe recoger determinada información para hacerlo. ¿Que cumpla su objetivo el usuario es malo para la empresa? no, ¿verdad?, más bien al contrario.
Esto, que parece obvio, no lo es tanto cuando navegamos por Internet. En multitud de ocasiones nos encontramos formularios web en los que parece que su existencia es un fin en si mismo, y cuantos más datos se recopilen del usuario mejor, o bien sucede que el “diseño” del formulario se ha realizado para su propio lucimiento. Sucede también en ocasiones que se indica a los equipos de desarrollo la necesidad de incluir campos a rellenar en el formulario web comentando que son por un “por si acaso” o “los necesitaremos dentro de 6 meses para…” o “cuanto más sepamos del usuario mejor”.
Y sinceramente, si esa empresa es la única en el mundo que provee un servicio único en el mundo, que nadie más ofrece…bueno, quizás pueda hacer lo que le venga en gana (poco recomendable). Pero, si es una empresa que está compitiendo en la jungla de las ventas online, como el 99,99% del resto de los e-commerce del mundo, entonces mejor olvidarse de estas prácticas jurásicas.
Los usuarios cada vez tienen menos paciencia, y lo que era válido hace años en este caso lo sigue siendo ahora, el usuario lo que quiere es comprar, no darnos el gusto de rellenar datos para que determinados departamentos sean felices. Porque el objetivo de la empresa es hacer que el formulario de la web esté lo más optimizado posible para cumplir, ya no el objetivo del usuario, sino el suyo propio, y ese objetivo no es otro que la venta de su producto o servicio. Ambos objetivos, los de la empresa y los del usuario, son los mismos. Es un win-win. Y entre medio de ambos objetivos se encuentra, llamémoslo, un impedimento, el formulario web.
Es como si en una carrera de atletismo, donde el usuario es el corredor y nosotros los que le animamos desde el lateral, estuviéramos haciéndole fácil el llegar a la línea de meta y justo cuando va a llegar, a sólo 1 paso de romper la cinta, se le interpone una persona en una ventanilla y le empieza a hacer preguntas sobre su edad, cuándo nació, si tiene hijos, etc. etc. El cliente estaba a punto de caramelo y le acabamos de quitar la ilusión del momento (y la nuestra de conversión).
Por eso es tan importante optimizar los formularios para la web, porque son el último paso antes de cumplir los objetivos que queremos. En este post voy a intentar recoger todas las buenas prácticas que se pueden aplicar para hacer formularios web usables, y que por tanto generarán una buena experiencia de usuario e intentaré poner ejemplos para que quede lo más claro posible.
Antes de empezar, y sólo para ser conscientes de la importancia que tiene la optimización de los formularios para la web, podemos ver a continuación el ejemplo real de lo que sucedió en la página web de Expedia.com. Expedia es una de las mayores agencias de viajes online del mundo. Pues bien, tenían en su página web de contratación de viajes un formulario web donde, entre otros pasos y campos, tenían los siguientes:
Parece que, después de analizar los datos de analítica del formulario web respecto a la conversión, se dieron cuenta de que estaban teniendo muchos abandonos o mala información completada en el campo “Nombre empresa”. Decidieron hacer una variante del formulario tal como éste, eliminando directamente ese campo:
¿Resultado? Más de 12 millones de dólares de beneficio al año, ¡por un simple campo!. Los usuarios estaban entendiendo (mal) que el nombre de la empresa que se les requería era el nombre de la empresa que disponía la tarjeta de crédito y muchos, al no saber cuál era, abandonaban el proceso de compra, porque Expedia, que es muy grande, no es la única empresa que provee viajes a través de Internet, y la distancia para el usuario de encontrar otras opciones ante cualquier dificultad está a tan sólo un click. Y aquí dos aspectos importantes:
- Primero: el usuario no se equivoca, lo está haciendo el planteamiento de la interfaz. Al estar el campo “Nombre empresa” dentro de la jerarquía visual de “Titular de la tarjeta” es totalmente comprensible que el usuario piense que se le está pidiendo el nombre de la empresa de la tarjeta y no la suya propia en la que trabaja, por muy raro que pueda parecer.
- Segundo: ¿os habéis fijado en que el campo “Nombre empresa” no era obligatorio?.
Fenomenal, un campo que se entendía mal y que por ende era opcional estaba provocando no ganar (por tanto pérdidas) 12 millones de dólares más al año, ahí es nada.
Una vez puestos en situación acerca de la importancia en la optimización de los formularios web, voy a intentar aportar puntos que son útiles para ofrecer la mejor usabilidad posible.
¿Qué grandes elementos o aspectos tiene un formulario web?
- Estructura y organización: cómo se muestra el diseño, qué tipo de datos y su forma de mostrarlos.
- Textos literales de los campos: son los textos que acompañan a los campos de completitud de datos, para una mejor explicación.
- Campos de completitud de datos: son los propios campos donde los usuarios deben introducir sus datos personales u otros, así como radio-buttons, check-boxes, etc.
- Botones: son los click to action del formulario, es decir, los puntos a partir de los cuales se sigue en el proceso de completitud o bien se termina completando.
- Ayuda y retroalimentación: a medida que el usuario lo va completando, cómo ayuda la interfaz en ello, con qué tipo de información y cómo se presenta.
Índice de contenido
- 1 Estructura y organización de un formulario web
- 2 Textos literales de los campos o etiquetas
- 2.1 No incluir el texto aclaratorio del campo únicamente dentro del campo
- 2.2 Las etiquetas de los campos deben ser cortas y perfectamente descriptivas
- 2.3 ¿Dónde ubicar las etiquetas de los formularios web, a la izquierda con alineación izquierda, a la izquierda con alineación derecha, arriba…?
- 2.4 No usar mayúsculas para las etiquetas
- 2.5 Los textos de las etiquetas deben ser cortos
- 2.6 Relacionar la etiqueta con su campo adecuadamente
- 2.7 Otras recomendaciones
- 3 Campos de completitud de datos
- 3.1 Hacer enfoque en el campo elegido
- 3.2 Para el caso de dispositivos móviles, ofrecer el teclado apropiado a la finalidad del campo a rellenar
- 3.3 Maquetar correctamente el uso del tabulador
- 3.4 ¿Campos preseleccionados o no?
- 3.5 ¿Qué formato utilizar para los campos de fecha?
- 3.6 Utilizar un tamaño adecuado de campo
- 3.7 Si se van a incluir radio-buttons o check-boxes (y son pocas opciones) hacerlo en vertical, no en horizontal
- 3.8 En dispositivos móviles, dejar la suficiente separación entre campos para una pulsación cómoda sin errores.
- 4 Botones
- 5 Ayuda y retroalimentación
- 5.1 Respecto a los campos obligatorios
- 5.2 Si incluímos ayudas contextuales a los campos, deben estar visibles
- 5.3 Mostrar los errores en los campos concretos donde se producen, no en un mensaje general (o en un lugar descontextualizado)
- 5.4 Habilitar la validación de cada campo en el mismo momento de completarlo y no en el envío del formulario
- 5.5 Aprovechar los códigos de color
- 6 Conclusión
Estructura y organización de un formulario web
La estructura y organización del formulario tiene que ver con su layout (diseño visual), pero también con la optimización en cuanto a información del mismo. Recomendaciones de usabilidad y de UX:
Solicitar única y exclusivamente los campos necesarios
Cada campo de más que solicitemos al usuario es una posible barrera a la conversión. Recordemos que el formulario es un “impedimento” entre el usuario y su objetivo final, la compra. Aquí deberíamos ser implacables. Cada campo que solicitemos al usuario tiene que estar más que justificado. Deben estar los campos en su mínima expresión, y deben ser los suficientes como para poder tramitar correctamente la solicitud del usuario. Mi recomendación aquí es estudiar todo el proceso o flujo de trabajo que se produce entre la solicitud del usuario y el envío del producto o servicio. Es decir, hay que analizar todos los pasos que se producen entre los distintos departamentos para poder realizar todo correctamente. Es aquí donde se descubre que determinados campos pueden ser evitados en la primera solicitud al cliente, lo que implica optimizar los campos solicitados y mejorar la conversión. Si trabajas en Usabilidad y Experiencia de Usuario, o bien en diseño, o desarrollo, y te piden poner campos que sabes que no son necesarios en la primera compra o registro del cliente recuérdales el caso de Expedia; un sólo campo supuso una diferencia de 12 millones de dólares; con eso tendría que ser más que suficiente como para que fueras escuchado.
Si se piden datos sensibles (DNI, teléfono, edad…) explicar porqué
Cuando los usuarios se encuentran con la petición de un dato que consideran sensible, en ese mismo momento se les pasa por la cabeza si verdaderamente merece la pena enviar el formulario.
Y bajo ningún concepto queremos algo así. Por eso, debemos pensar antes si es absolutamente necesario incluir una petición de este tipo para poder ofrecerle nuestro producto o servicio. Si no lo es entonces mejor no ponerlo. Con esto estaremos mejorando ampliamente la conversión de nuestra página.
Ahora bien, si es necesario, entonces explicar por qué, ser claros con el usuario. A los usuarios nos gusta la claridad y si alguien nos explica por qué se nos está pidiendo el DNI y es razonable, no existirá ningún problema. Por ejemplo, si en la compra de unas entradas de cine a través de un formulario web pido el teléfono (y es necesario en mi proceso de compra) y el texto explicativo que acompaña al campo dice “Lo utilizaremos para enviarte el código de las entradas y que puedas entrar con él si lo deseas” no sólo no me parecerá mal sino que me parecerá genial, y no sólo habremos obtenido el dato sino que habremos mejorado la experiencia de uso del usuario.
Ordenar la información de forma lógica
Las personas cumplimos mejor las tareas si lo hacemos en bloques de información que tienen sentido. En los formularios web debemos organizar los datos solicitados en grupos que van a ayudar al usuario a completarlo. Debemos ponernos en su lugar, y ver el formulario bajo su punto de vista, no desde el de la aplicación. Además, podemos aprovechar la potencia de la programación para hacer más fácil el proceso de relleno al usuario, de hecho debemos hacerlo, porque sino ¿qué diferencia habría entre rellenar un formulario en la web y hacerlo en uno en papel?.Por ejemplo, si el usuario nos dice que su código postal es el XX.XXX entonces ese código postal nos está diciendo dónde está ubicado, con lo que ya tendremos rellenada la ciudad, la provincia o estado y el país, cuatro campos en uno. Por tanto, debemos solicitar unos campos antes que otros, para ayudarnos de ellos para la completitud del formulario. Otro ejemplo, si vamos a darle opción al usuario de solicitar factura, podemos simplemente incluir un campo que diga si quiere que reutilicemos los datos que ya nos ha dado antes, 4-5 campos auto rellenados en un click.
¿Campos en una o en varias columnas?
Esta es una de las grandes preguntas que siempre se realizan a la hora de abordar el diseño de un formulario web. Respuesta: En mi opinión, la distribución del formulario en una sola columna es mejor que en dos. Veamos por qué. Para el usuario es más natural y tiene que realizar menos saltos visuales entre la información cuando la encuentra en una columna que en varias. Además, con el mayor uso de la navegación que se está produciendo actualmente hacia el móvil, la interacción del usuario es más acorde a este layout y va a necesitar menos adaptación que si está desarrollado en varias columnas.
Sólo cuando los campos tienen relación entre si, como por ejemplo los de código postal, provincia, ciudad, país, puede tener sentido ponerlos en una misma fila (aunque habrá que valorar su disposición también con el diseño). También sería un buen ejemplo el de tarjeta, con los campos de fecha de caducidad y el de seguridad CVV. Pero en general, será siempre mejor el diseño a una sóla columna que en varias. Viéndolo visualmente para el ejemplo de varias columnas, el usuario hará una de estas dos cosas, o variaciones similares entre ambas:
Y como se observa, el usuario no sigue un movimiento natural sino que o bien tiene que volver sobre sus pasos hacia arriba o bien tiene que realizar demasiados impactos visuales, con el riesgo que supone de dejar de completar un campo que sea obligatorio, y del tiempo invertido en completar el formulario.
En cambio, con una sóla columna (y con el caso de campos relacionados entre si):
Textos literales de los campos o etiquetas
¿A qué me refiero exactamente con el texto literal del campo? A esto:
Ayudan a aclarar al usuario lo que debe rellenar.
Recomendaciones:
No incluir el texto aclaratorio del campo únicamente dentro del campo
Es decir, no hacer cosas como esta:
Podemos ver este uso en un formulario web real:
Aunque puede existir un argumento a favor de utilizarlo respecto a que el formulario web se acorta en altura, existen muchos otros argumentos en contra relacionados con la usabilidad del formulario por las que es preferible no hacerlo.
La razón es que se ha comprobado que los usuarios son más propensos a rellenar campos que están vacíos, que no campos que ya aparecen rellenados (aunque sea el texto aclaratorio del campo). Con lo que, en el mejor de los casos perderán más tiempo buscando el campo que tienen que rellenar, y en el peor de los casos pueden obviarlo (más grave si es un campo obligatorio), con lo que le hacemos entrar en una dinámica de envío-error, etc.
Otra de las razones para no utilizar únicamente los literales dentro del campo es que si el usuario está utilizando el tabulador del teclado para pasar de campo a campo, el cursor va a llegar al foco del mismo antes de que a él probablemente le de tiempo de leer lo que tiene que rellenar, con lo que le estaremos obligando a quitar el foco para saber lo que tiene que hacer.
Una nueva razón para no utilizarlos es que si el usuario quiere comprobar que los datos que ha introducido son correctos antes de enviarlo, ¿cómo lo va a hacer?, ya que los literales que aparecían están sobreescritos con los datos que ha introducido, con lo que más vale que sean correctos, porque no tiene forma de saberlo.
Entonces, ¿cuál sería la mejor forma de mostrarlo? Así:
o bien así:
Ahora bien, si por alguna razón no hay más remedio que ganar espacio, también se puede buscar una solución intermedia donde, el literal está únicamente dentro del campo, y cuando el usuario hace foco en él entonces se desplaza a la parte superior del propio campo, es decir, algo como ésto:
Las etiquetas de los campos deben ser cortas y perfectamente descriptivas
De lo que los usuarios tienen que rellenar. Tenemos que evitar que rellenar el formulario para el usuario sea tedioso. Los usuarios no leen en la web, ojean, y por ello debemos mostrarles la información de forma sencilla y breve. Debemos evitar cosas como esta:
Lo mismo, pero optimizado, se puede conseguir así:
¿Dónde ubicar las etiquetas de los formularios web, a la izquierda con alineación izquierda, a la izquierda con alineación derecha, arriba…?
Recordando lo que se ha comentado unos párrafos más arriba acerca del uso de una o varias columnas, aquí el argumento es similar. Es mejor ubicar las etiquetas de los formularios en la parte superior de los campos, ya que los usuarios no tienen que buscar por separado las etiquetas del campo y asociarlo a su campo correspondiente, sino que el movimiento natural hacia abajo realiza la asociación mucho más eficientemente. De hecho, en el 2006 se hizo un análisis de eyetracking acerca de cómo consumían los usuarios los distintos tipos de formulario según donde se situaban las etiquetas, a la izquierda, a la izquierda con alineación derecha, o arriba del campo, y los resultados fueron concluyentes. Aquí se muestran las imágenes de dicho estudio de eyetracking:
Como se puede comprobar, los impactos visuales que tiene que realizar el usuario para entender y completar el formulario web con los campos en la parte superior son menos caóticos que en los otros dos casos.
Las ventajas que proporciona la alineación de las etiquetas en la parte superior del campo son:
- Mejores tasas de completitud del formulario: sólo por esta razón ya compensa al resto de razones (tanto a favor como en contra). Recordemos que el objetivo del usuario es cumplir con lo que venía a hacer a la página (compra, solicitud de más información, etc.) y cuanto antes lo haga mejor. Él no venía a rellenar ningún formulario necesariamente.
- Es más fácil para los usuarios “leer” el formulario y generará menos errores.
- Permite un mejor tratamiento de los idiomas si la página lo requiere. Se dispone de todo el espacio superior horizontal para escribir, y no se depende del número de palabras para que el diseño del formulario quede bien igualmente.
Desventaja de la alineación de las etiquetas en la parte superior del campo:
El formulario web necesitará más espacio vertical. Sin embargo, creo que compensa sobradamente. Por otra parte, los que llevamos en esto desde que empezó Internet, recordamos aún cómo las webs antiguamente se empeñaban en incluir todo el contenido en el primer pantallazo de la página, independientemente de lo saturada que resultara. La evolución de las páginas y el uso habitual del scroll con el ratón, o sobretodo el uso de los móviles y el movimiento hacia abajo natural, ha hecho que los usuarios entiendan perfectamente que pueden desplazarse por la página sin que ello suponga un problema de uso, sino más bien al contrario, un mejor tratamiento de la información. El problema es mayor cuando se intenta hacer más pequeño el formulario y aglutinar toda la información posible en el menor espacio posible, para evitar que el usuario tenga que hacer scroll. Esto es un recuerdo de etapas pretéritas superadas ya.
Pero como todo en la vida, también existen excepciones y de hecho se pueden utilizar estos argumentos por otros motivos en nuestro favor. Es decir, si por alguna razón necesitamos que el usuario se detenga un momento para que piense exhaustivamente en el campo que va a rellenar, entonces adelante, podemos poner las etiquetas a la izquierda. Pero si lo que queremos es que compren lo antes posible, entonces hagámoslo lo más fácil posible.
No usar mayúsculas para las etiquetas
Aunque para pocas palabras pueden funcionar bien, no lo hacen para un número de palabras mayor, y no podemos usar letras mayúsculas en unas si y en otras no, debe existir coherencia. Se ha demostrado que a los usuarios les cuesta un poco más leer letras mayúsculas, así que es mejor no utilizarlas. Evitar este tipo de uso:
Los textos de las etiquetas deben ser cortos
Se deben evitar etiquetas demasiado largas. Con esto permitimos que el usuario escanee rápidamente los datos solicitados. Si los textos son largos estaremos obligándole a pasar demasiado tiempo interpretando la información. Por ejemplo, como veíamos antes:
Relacionar la etiqueta con su campo adecuadamente
Es decir, evitar cosas como esta:
En este caso, la legibilidad del formulario para el usuario no es adecuada ya que la equidistancia entre las etiquetas y los campos es idéntica entre todas ellas con los campos superiores e inferiores, y en consecuencia al usuario le cuesta mucho más relacionar la información. Así, la solución es la siguiente:
Esto tiene relación con las leyes de la Gestalt, y una de ellas específicamente, la de proximidad. Esta ley nos dice lo siguiente: “Los elementos aislados, pero con cierta cercanía tienden a ser considerados como grupos.” (Leyes de la Gestalt).
En el ejemplo visto antes con la misma equidistancia entre literales y campos, la mente del usuario está viendo lo siguiente:
En el segundo caso, con las etiquetas asociadas a su propio campo, lo que el usuario está viendo es lo siguiente:
Volviendo a la definición de la ley de proximidad “Los elementos aislados, pero con cierta cercanía tienden a ser considerados como grupos.” Para el usuario será mucho más evidente y entenderá mejor la información si se lo hacemos sencillo y agrupamos la información adecuadamente.
Otras recomendaciones
Existen otras recomendaciones respecto a las etiquetas de los campos sobre las que no voy a entretenerme demasiado por obvias, como por ejemplo que los textos tengan suficiente contraste y sean legibles, que su tamaño sea adecuado para su lectura, etc.
Campos de completitud de datos
Tal y como comentaba antes, estos campos son los espacios donde los usuarios rellenan su información o la seleccionan. Recomendaciones de usabilidad y de experiencia de usuario sobre ellos:
Hacer enfoque en el campo elegido
Si le indicamos de alguna forma al usuario que el campo que va a rellenar es el que tiene el foco, entonces será más claro para él que ese es el que está rellenando cuando entre en el. Veamos un ejemplo de una empresa que lo está aplicando correctamente, BBVA:
Vemos un ejemplo a continuación que no lo está haciendo, cuando hay foco en el campo. No existe ninguna distinción entre el campo en foco y el resto (más allá de que el cursor esté en el campo, lo cual es muy pobre):
Para el caso de dispositivos móviles, ofrecer el teclado apropiado a la finalidad del campo a rellenar
Si el dispositivo que está utilizando el usuario es un smartphone y el campo que le pedimos es numérico, como por ejemplo un teléfono, en ningún caso utilizará letras para rellenarlo. Si al hacer foco en el campo cargamos el teclado por defecto le aparecerá el de escritura. ¿Qué tendrá que hacer el usuario en el 100% de los casos? cambiar al numérico.
¿Por qué no hacerlo nosotros por él? ¿es que no queremos que rellenar el formulario sea lo más sencillo posible? En este caso, podemos usar la potencia que nos da el propio dispositivo para ayudar al usuario. Aquí podemos ver un ejemplo de este mal uso:
¿Cómo debería aparecer correctamente? Así:
Maquetar correctamente el uso del tabulador
Algunos usuarios utilizan el tabulador para pasar por cada campo a rellenar. Y sucede en muchos casos, que la programación del formulario provoca que en lugar de pasar por el orden lógico de visualización de los campos del formulario web, cada salto del tabulador sea totalmente imprevisible. Esto, que parece obvio, sucede en multitud de ocasiones y su corrección en el código es muy simple.
¿Campos preseleccionados o no?
Depende. Recordemos que los usuarios suelen pasar por alto campos que ya aparecen rellenados o lo aparentan. Así que debemos ser muy cuidadosos a la hora de autorrellenar un campo por el usuario. ¿En qué casos tendría sentido? por ejemplo cuando sepamos que al menos el 90% de nuestros usuarios son de un país. Con esto estaremos facilitando la vida al 90% de ellos. O incluso si el usuario ya está logado en la página y tenemos sus datos personales entonces es una buena práctica incluir los datos que él ya aceptó en su momento facilitarnos. Con esto estaremos optimizando la conversión del formulario.
Pero si no está logado o bien no tenemos claro en qué porcentaje de completitud está un campo, entonces es mejor dejar que sea el usuario el que lo elija, y por supuesto no debemos preseleccionar por él el valor de dicho campo. Por ejemplo, podemos ver en la siguiente imagen de la página de Atrápalo que se autorrellena el campo de teléfono con el código del país (España) y también el país de residencia porque probablemente la amplia mayoría de los usuarios que completan este formulario sean españoles.
¿Qué formato utilizar para los campos de fecha?
Un campo de fecha mal diseñado puede llevar al traste la conversión de un formulario o cuanto menos generar malas experiencias de usuario y costes para la empresa, si por ejemplo un usuario quería comprar un billete de avión para una fecha y por el mal diseño del selector lo ha comprado para otra y no se ha dado cuenta.
Si se solicita la fecha de nacimiento se debe evitar incluir tres selectores desplegables para el día, mes y año, ya que suponen para el usuario más clics de los necesarios y además en dispositivos móviles no va a ser cómodo por el consiguiente desplazamiento. Por tanto, no es aconsejable usarlo. Veamos un ejemplo de lo indicado.
En este caso sería más cómodo para el usuario escribir directamente en un sólo campo toda la fecha, ayudándole con los caracteres para evitar problemas de uso, por ejemplo, si el usuario utiliza espacios, guiones, barras, puntos, etc. entre sus fechas debemos ayudarle y no obligarle a rellenarlo de una sola forma. Utilizar este tipo de desplegables es el camino más fácil al abandono del formulario. Que se note que queremos que convierta en nuestra página y que queremos ayudarle. Por ejemplo, en la siguiente imagen podemos ver que cuando el usuario escribe un punto o un guión es la programación del campo el que ayuda al usuario a incluir el formato adecuado, evitando que se generen errores continuos en su introducción. El campo fecha suele ser el que más problemas genera en los usuarios a la hora de cumplimentarlo, así que se debería hacer especial esfuerzo en ayudarlo:
Sin embargo, si la fecha a incluir por el usuario está muy cercana en el tiempo, entonces podemos ofrecerle también un calendario donde se muestren los días siguientes. Por ejemplo, si va a escoger el día concreto para la entrada al cine, teatro, etc. ya que probablemente su compra sea en unos días.
Utilizar un tamaño adecuado de campo
Si utilizamos campos donde se espera que los caracteres a incluir sean determinados, debemos adaptar el tamaño del campo a esos caracteres. Es decir, si por ejemplo le hacemos rellenar al usuario el código postal, no incluir un campo de este tipo:
Por ejemplo, a continuación vemos el mal uso:
Y lo mismo bien planteado:
Es mucho peor la legibilidad de las opciones en horizontal que en vertical.
En dispositivos móviles, dejar la suficiente separación entre campos para una pulsación cómoda sin errores.
Según un estudio realizado por el MIT Touch Lab acerca de la mecánica utilizada por los seres humanos con las yemas de los dedos, se observó que la anchura media del dedo índice en las personas es de unos 16-20 mm. Traducido a píxeles, son entre 45 y 57 px.
Por tanto, en un formulario web presentado en dispositivo móvil, donde los usuarios tienen que pulsar en cada campo para rellenarlo, los elementos no deberían estar a menos de esa distancia entre la parte superior del campo y la parte superior del siguiente. Veámoslo de forma gráfica y sencilla. Debemos evitar el formato del formulario de la izquierda y utilizar el de la derecha (que se ha adaptado para el ejemplo):
Con ello evitaremos pulsaciones en elementos que el usuario no deseaba pulsar voluntariamente. Una vez más, hagámoslo fácil y prevengamos errores.
En el ejemplo del formulario visto, simplemente incorporando los literales de las etiquetas en la parte superior de cada campo ya hubiéramos evitado este problema y además habríamos mejorado la usabilidad del formulario en ese sentido.
Botones
Son uno de los grandes protagonistas del formulario, y antes de ver recomendaciones que mejoran la usabilidad, hay que hacer un comentario hacia los botones tipo “Limpiar”, “Restablecer”, “Borrar” o similares.
La función de estos botones es la de eliminar por completo los datos introducidos por el usuario en el formulario web. Su uso se generalizó en el pasado como una forma de hacer algo similar a lo que sucedía (y sucede aún) en la aparición de ventanas, donde tenemos que tomar una decisión, y suele existir una opción “Cancelar”. En este contexto de uso de la ventana es totalmente recomendable. Pero en el caso del formulario web, en ningún caso.
Lo único que provocan estos botones en los usuarios son clicks accidentales que hacen que ¡todos los datos introducidos se borren! y es muy probable que esto haga que el usuario se vaya directamente del sitio ante su frustración. Además, al estar en la parte inferior del formulario junto con el probable botón de “Aceptar” o “Continuar” lo único que hará será consumir tiempo en el usuario en la interpretación del mismo. Vamos, lo que no queremos en ningún caso.
Volviendo al ejemplo de la carrera sería como si justo cuando el usuario está llegando a meta, y antes de cruzar la cinta, le hacemos rellenar el formulario, amablemente lo rellena y entonces, en ese último esfuerzo, cuando ya está todo hecho, le ponemos dos botones y le decimos, venga, clica en uno. Ay de él como se equivoque, porque tiene que volver al inicio de la carrera. “Con todo el cariño, adiós, os deseo lo mejor” y a este usuario no lo volveremos a ver.
Alguno puede que estéis pensando, hombre David, esto ya no lo hace nadie. ¿Seguro?…
A veces una imagen vale más que mil palabras. Año 2017: La web dependiente del Ministerio de Hacienda, que tendría que estar al servicio del ciudadano, aplicando la no usabilidad y generando malas experiencias de uso. Salvo que lo hagan a propósito, para recibir el menor número posible de solicitudes…que todo es posible.
Así, el botón “Limpiar” o similar en un formulario web debe desaparecer. Y esta recomendación de Nielsen tiene nada menos que 17 años.
Veamos las recomendaciones sobre el uso de los botones en los formularios web.
Distinguir entre acciones probables frente a posibles
Si en un formulario se da la misma importancia y peso visual al botón más probable frente al posible, lo único que conseguiremos serán usuarios frustrados. Si vemos el formulario anterior:
se está utilizando el mismo peso visual para las opciones “Limpiar” y “Enviar”. Si el usuario está rellenando el formulario, ¿qué es lo más probable que haga?, que lo envíe. ¿Es “posible” que quiera restablecerlo?, si, aunque muy poco probable (además de ser una mala práctica ya indicada anteriormente). Y sin embargo, ¿qué está proponiendo el formulario al usuario con esos dos botones? un balanceo de un 50%-50% de clics, porque los usuarios quieren enviar cuanto antes la información que tan cuidadosamente han completado y si se equivocan de botón vuelta a empezar, en el mejor de los casos…Claramente, la interfaz está ayudando muy poco, por no decir nada, al usuario. ¿Cómo mostrar entonces los botones?
o también así:
Aquí hemos rebajado el peso visual del botón “Limpiar” y el que se lleva todo el protagonismo es el que más probablemente quiera ser pulsado por los usuarios. En cualquier caso, insisto en que el botón “Limpiar” en el formulario no tiene sentido y sólo puede llevar al usuario a error, así que la recomendación es eliminarlo. Aquí lo he utilizado para los ejemplos para seguir con el caso real que hemos visto, pero estas buenas prácticas son aplicables a botones como Anterior o Cancelar.
Posición de los botones del formulario web
Aquí hay varios casos posibles:
- El formulario se ha dividido en varios pasos o pantallas y existe un botón anterior y siguiente, y un botón aceptar finalmente.
En este caso, el orden natural de los botones es “Anterior” a la izquierda y “Siguiente” a la derecha. Y en el último paso del formulario “Siguiente” se convertirá en “Enviar” o “Confirmar” o “Comprar”, o mejor aún “Comprar billetes”, “Reservar habitaciones, etc. Aquí hay que cuidar un detalle en la ubicación del botón “Anterior” y es que no debe estar demasiado cerca del último campo rellenado por el usuario, ya que debemos evitar clics involuntarios que den al traste con el trabajo de rellenado del formulario web. Por ejemplo, debemos evitar esto:
Y plantear esto en su lugar: - El formulario tiene una sola pantalla de solicitud de datos
En este caso, pueden convivir dos botones, “Aceptar” y “Cancelar” o “Limpiar” (aunque ya he comentado que no es una buena práctica incluirlo). Aquí mi opinión es que es mejor ubicar el botón “Aceptar” a la derecha y “Cancelar” a la izquierda. Digo mi opinión, porque existen argumentos a favor y en contra en muchos artículos de Usabilidad y UX, y sigue siendo un debate abierto. En el artículo que escribí hace tiempo sobre la ubicación de los botones Aceptar-Cancelar puedes ver todos los argumentos que doy personalmente en favor de poner el botón Aceptar a la derecha y que para mí es el que mejor experiencia de usuario provoca.
Hacer botones contextuales
Evitar textos demasiado genéricos como “Enviar” o “Aceptar”. Hacer textos que pongan en contexto al usuario respecto a la acción que va a tomar y que le inciten a ello. Por ejemplo, es mejor un texto como “Comprar mis billetes” que un simple “Confirmar”:
Ayuda y retroalimentación
El simple hecho de incorporar un formulario web en el proceso de consecución de los objetivos del usuario en la web va a hacer que inevitablemente se produzcan entradas de datos erróneas. Pensar que el 100% de los usuarios va a completar correctamente el formulario es una utopía.
Sabiendo esto, es necesario que ayudemos al usuario con los errores que se produzcan y que pueda terminar enviando el formulario. Y una máxima, el formulario web debe ser intuitivo y nunca debería necesitar una explicación por si mismo. Si no es intuitivo entonces es que es necesario rediseñarlo. A partir de aquí, ayudemos al usuario todo lo posible.
Recomendaciones de usabilidad para ayudar al usuario con el formulario web:
Respecto a los campos obligatorios
- Se indica al final de los mismos que “El * indica campo obligatorio”.
Esta frase es una aclaración o instrucción hacia el usuario acerca de la forma de rellenar el formulario. ¿Por qué incorporar una frase que da instrucciones sobre cómo rellenar una información al final, cuando o bien he rellenado todo el formulario o bien me he ido porque he visto que había que rellenar demasiados datos (y quizá eran pocos los obligatorios)? Es posible que se pueda llegar a pensar, “bueno, así tengo todos los datos del usuario”…¿y si se está perdiendo a una buena parte de los posibles clientes porque no quieren perder el tiempo en rellenar tantos datos?, desde luego no compensará esta pérdida de clientes para obtener unos datos más de los usuarios, además de que quizá el usuario que lea esta frase al final le provoquemos una sensación de pérdida de tiempo en rellenar más campos de los que eran necesarios. Aquí vemos un ejemplo de lo comentado: - No existe ninguna frase explicativa acerca de que el * indica campo obligatorio:
Aunque el asterisco sea un estándar y pensemos que todo el mundo sabe qué es, no es así. Igual que pensar que al clicar en el logo de una página web volvemos a la página de inicio. He participado en test con usuarios donde no todos los usuarios eran conocedores de ello, y no es un problema del usuario, simplemente es una situación real; por eso se han incluido en el menú de muchas páginas la opción “Inicio”. Una vez más, facilitémosle el trabajo y su (nuestra) conversión. - Si todos los campos son obligatorios entonces lo ideal es informar al usuario al principio y evitar incluir el *. Por ejemplo mediante esta frase “Todos los campos son obligatorios”. Evitaremos ruido visual en el formulario y quedará más elegante.
- Si existen menos campos obligatorios que opcionales entonces lo mejor es no incluir la indicación del * para campos obligatorios y sí incluir un “Opcional” al lado de cada campo que lo sea. Sin embargo, mi recomendación es no incluir ningún campo opcional en el formulario, salvo que los beneficios de obtenerlos sean mayores que la conversión de los usuarios que perdamos por no estar dispuestos a rellenar estos datos adicionales. En mi opinión el formulario web debe llegar a su mínima expresión posible para cumplir con el objetivo del envío o contratación. Si podemos obtener los campos opcionales más adelante sin merma de la experiencia de usuario ¿por qué no hacerlo?.
- Si existen más campos obligatorios que opcionales entonces indicar al principio del formulario web que “Los campos con * indican datos obligatorios”.
Si incluímos ayudas contextuales a los campos, deben estar visibles
Salvo que sean mayores que los 100 caracteres o que puedan incorporar una imagen de apoyo; entonces es mejor incluir un icono de más información o un “¿Qué es esto?” y que al clicarlo o ponerse encima se muestre toda la información. ¿En qué casos se puede producir esta situación? por ejemplo cuando se muestra el campo CVV en el pago con tarjetas. No todo el mundo sabe que es un código de seguridad, y dónde puede encontrarlo. Para ello lo mejor es explicarlo y ayudar con una imagen representativa. Por ejemplo:
Mostrar los errores en los campos concretos donde se producen, no en un mensaje general (o en un lugar descontextualizado)
Es decir, evitar esto:
La recomendación es indicar la solución en cada campo de forma contextualizada:
Aquí le decimos al usuario en qué campo específico se ha producido el error y qué debe hacer para solventarlo. Y nunca llevar a otra pantalla distinta del formulario donde se han producido los errores. Podemos ver un ejemplo de lo que actualmente sucede en la página web de la Moncloa donde si hay errores en el formulario no sólo no se indican de forma adecuada, sino que además redirigen al usuario a otra página. Tremendo.
Habilitar la validación de cada campo en el mismo momento de completarlo y no en el envío del formulario
Con esta recomendación estaremos evitando envíos y correcciones constantes, y prevenimos al usuario acerca de lo que debería completar. Por otra parte, no debemos hacer validaciones hasta que el usuario haya dejado de hacer foco en el campo o hasta que sepamos con seguridad que no es correcto mientras se completa. Muchas veces nos encontramos formularios donde nada más empezar a escribir ya se está indicando que el formato no es correcto, y hasta que no se termina de completar es cuando se indica que es correcto; esto es una molestia evidente y una mala práctica. Me refiero a por ejemplo:
La forma correcta sería:
¿Y por qué no mejorarlo aún más especificando cuáles son los errores? en lugar de que el usuario tenga que preguntarse dónde está el error. Unas pocas líneas de código más pueden mejorar la conversión, con lo que compensará sin ninguna duda. Por ejemplo así:
Aprovechar los códigos de color
En este caso, los rojos deben utilizarse para indicar un error, el amarillo para indicar una recomendación como por ejemplo una contraseña débil, y el verde para los mensajes correctos. Pero por supuesto no debe ser la única forma de indicar los errores ya que las personas con problemas de visión, como las daltónicas, desconocerán lo que tienen que hacer.
Conclusión
Los formularios web son (de momento) un paso necesario en la consecución de los objetivos de los usuarios en su solicitud de información, de compra de servicios o productos, etc.. Cualquier mejora de las que he indicado que se incluyan en los formularios web hará, sin duda, que mejoren las tasas de conversión de la página. Con las recomendaciones propuestas y aglutinadas a partir de estos años de experiencia y de opiniones de excelentes profesionales que existen sobre el tema, espero haber ayudado un poco a que tu página pueda convertir mejor.
Hernán dice
Estupendo! Qué plugin existirá en WordPress u otro que permita construir algo así de bueno?
Saludos
David Gil Ripoll dice
Muchas gracias por tu comentario Hernán. ¡Si! A veces es complicado que un plugin tenga todas estas opciones disponibles, y toca meterse en las tripas a través de código. Si uno es experto entonces genial.
Jose dice
Gracias estoy comenzando en programación web y este articulo me cayo de perlas. Felicitaciones por compartir tus conocimientos.
David Gil Ripoll dice
¡Muchas gracias a ti José! Encantado de que te haya gustado y servido el contenido :).
Elisenda Vives dice
Genial artículo resuelve muchas dudas de como realizar un formulario de la forma correcta.
Gracias por compartirlo!!!!
David Gil Ripoll dice
Muy agradecido por tu comentario Elisenda. Me anima a seguir escribiendo 😉
InnovaOrigen dice
¡Impresionante! Este post se queda en mi Evernote. No vaya a ser que cualquier día internet se acabe y lo pierda.
Gracias por compartir!
David Gil Ripoll dice
Jajaja, muy agradecido por tu comentario. Contento de que puedas utilizar la información 😉
y@ss Quenaya dice
Gracias a sido muy util, mil gracias, todo muy bien explicado, muy detallado, muy logico todo, eso si es usabilidad de formluarios, Gracias.
David Gil Ripoll dice
¡Muchas gracias por tu comentario!
MIGUEL ALFONZO dice
Extraordinario!! Muchas gracias por compartirlo
David Gil Ripoll dice
Muchas gracias por tu comentario Miguel. Encantado de que te haya servido 🙂
David dice
Muy buena información en tan bien resumido post, gracias por el aporte. diseño web