Diseño de formularios
Los formularios son uno de los patrones de interacción para la obtención de datos de personas usuarias más extendidos.
Los encontramos cada vez que necesitamos registrarnos en un producto, reservar una habitación, realizar un pago, responder una encuesta, suscribirnos a un boletín e incluso realizar una búsqueda.
Sin embargo, rellenar un formulario no es de las actividades más apasionantes para la gente. Se siente como una obligación, requiere un esfuerzo mental y físico considerable, y se percibe como una tarea administrativa, no necesariamente gratificante, donde se deben incluir datos que son privados y a veces personales.
Si recordáis cuando describíamos la usabilidad como el grado de eficacia, eficiencia y satisfacción con el que una persona concreta puede usar un servicio o producto en un contexto específico; la eficiencia hacía referencia al balance de esfuerzo y resultados.
En este caso, el resultado de completar el formulario debe ser suficientemente valioso para que las personas deseen poner todos los recursos necesarios para rellenarlo.
Por eso la primera pregunta que debemos hacernos cuando necesitemos conseguir información de las personas a través de un formulario es: ¿Es realmente necesario? ¿Qué obtendrá la gente a cambio? ¿Estamos transmitiendo bien su valor?
Formulario para recoger mediciones del cuerpo en una aplicación de entrenamiento.
Rosenfeld Media
Lectura recomendada para aprender a diseñar formularios web.
Estructura: una columna mejor.
Empecemos por la estructura. Uno de los fallos históricos en el diseño de formularios es el de intentar colocar demasiados elementos en el mismo área visible. Probablemente se deba porque el origen de muchos de ellos es una traducción directa del formato en papel con todas sus limitaciones.
Diseño de formularios en papel y en una interfaz.
El problema de colocar todos los elementos en un mismo área es que forzamos una disposición en varias columnas, y esto genera más ruido visual y más esfuerzo para escanear y rellenarlo ya que debes ir saltando de un lado a otro de la pantalla, interpretando lo que se te pide y con el riesgo de pasar por alto algo importante.
En general preferiremos siempre los formularios dispuestos en una sola columna. Evitaremos siempre diseñar formularios con varias columnas porque estos serán más costosos de rellenar, más ambiguos, más propensos a los errores y menos intuitivos.
Evitar no quiere decir que los formularios de varias columnas no deban usarse bajo ningún caso. De hecho, cuando la longitud vertical del formulario sea tal que empuje información relevante hacia el fondo, es posible, que dos columnas puedan mejorar la tasa de completitud y conseguir un balance mejor.
En estos casos es conveniente hacer pruebas con usuarios para evaluar su eficiencia real.
Tamaño de los campos
Es importante mencionar que el ancho que ocupen los elementos deben dar una indicación del valor que se espera, es decir, si en un código postal esperamos 5 caracteres, el ancho de este campo no debería ocupar el 100% de la pantalla, sino el mínimo necesario para mostrar esos 5 caracteres.
Ahora bien, no siempre es posible crear un buen balance visual ajustando el ancho al mínimo necesario. En estos casos es posible que lleguemos a crear un grid de dos o más columnas donde sólo los campos 'pequeños' se ajusten a este grid y el resto sigan ocupando la visual de una columna.
Rotulado: disposición vertical preferible.
El rotulado hace referencia a la disposición y estilo de las etiquetas respecto a los campos de entrada (inputs).
Como norma general, la disposición vertical de las etiquetas mejora la usabilidad del formulario desde el punto de vista de su eficiencia: se completan más rápido y con menos carga cognitiva. Si éste es el objetivo del usuario, la disposición vertical es la opción preferida.
Imágenes del eyetracking realizado durante los tests con diferentes rotulados por Matt Penzo.
Sin embargo, los formularios no siempre se presentan en un espacio visual de forma aislada sino que conviven con más elementos. Además, como bien indica Caroline Jarrett, las etiquetas de un formulario no son simples palabras, sino que sirven de preguntas para extraer información significativa, y esto puede llevarnos a decidir usar otros tipos de alineamientos.
En casos de alineamientos a izquierda o derecha, debemos tener en cuenta los siguientes riesgos:
- La longitud de las etiquetas puede variar entre sí y al traducirse a otros idiomas esto es más difícil de controlar, forzando un mal balance visual, un espacio vertical adicional (si se van a dos líneas) y/o la necesidad de hacer trimming (cortar con elipsis).
- El alineamiento a derecha dificulta adicionalmente el escaneo sobre el alineamiento a izquierda.
- La disposición a izquierda o derecha fuerza su escaneo. Esto es beneficioso cuando los campos no son familiares a las personas y queremos forzar su lectura, pero perjudicial porque incrementa la carga cognitiva.
- Se requiere mayor espacio horizontal para este tipo de alineamientos y ajustarlo depende de la longitud de las etiquetas.
Decir que para idiomas que se escriben de derecha a izquierda, como el árabe, no he encontrado ninguna investigación, pero si aplicamos las mismas reglas que con los patrones de lectura, podríamos concluir que las reglas aplican de forma similar considerando su disposición en espejo.
Esta guía de Ahmad Shadeed es un recurso fantástico para diseñar considerando idiomas RTL (right-to-left).
Ahmad Shadeed
¿Podemos renunciar a las etiquetas?
Hace no muchos años vimos cómo Google Material introdujo en teléfonos móviles el uso de etiquetas flotantes en formularios de una manera muy ingeniosa.
Las etiquetas flotantes suelen colocarse visualmente dentro del campo de entrada y se desplazan hacia arriba cuando se toma el foco de dicho campo.
Las ventajas de este patrón son:
- Ahorra mucho espacio vertical, algo que es muy valioso en pantallas pequeñas.
- La etiqueta se mantiene visible mientras se escribe para evitar los problemas de memoria que pudieran surgir al tomar el foco y desaparecer.
- La animación le da un aspecto más ágil y estéticamente agradable lo que podría mejorar la usabilidad.
Entre los inconvenientes encontramos:
- La etiqueta actúa de placeholder (descripción o pista del valor aceptado por el campo), al seguir otras guías de diseño de contenido, puede resultar en una información ambigua si la gente no está familiarizada.
- Si el valor que aceptan los campos siguen reglas no conocidas por la gente, los placeholders se hacen imprescindibles y en este caso perdemos su uso.
- Si el campo requiere de máscaras para evitar errores de entrada, no podrá haber una transición lógica en el movimiento de la etiqueta.
- Si la etiqueta tiene demasiado contraste puede dar la impresión de que el formulario ya está relleno pero si el contraste es demasiado bajo, puede causar problemas de accesibilidad.
- La etiqueta reduce su tamaño considerablemente cuando se desplaza, con lo cual, la segunda ventaja no es tal al no ser tan legible.
Incluso si dejamos a un lado los problemas de usabilidad que tienen los placeholders colocados dentro de los campos, sustituirlos por una etiqueta flotante no es siempre la mejor opción como consecuencia de un problema de espacio vertical:
- La etiqueta sigue necesitando de un área legible suficiente mientras se está rellenando el formulario.
- Los mensajes de error siguen necesitando su espacio visible reservado.
Mi recomendación general es usar este tipo de etiquetas sólo en formularios cuyos campos son reconocibles, cuyos valores aceptados casi no tengan restricciones y por tanto no sean propensos a errores.
Elementos: cuantos menos, mejor.
Con el objetivo de evitar posibles errores y facilitar la entrada de datos, en los formularios podemos usar diferentes tipos de elementos entrada como:
- Texto
- Fecha y hora
- Colores
- Archivos
- Imágenes
- Números
- Password
- URLs
- ...
Gracias al correcto uso de estos elementos en interfaces web (y en interfaces gráficas en general donde adoptaremos la misma convención de nombres=, podremos ofrecer a las personas usuarias una validación y una indicación del formato que debe usarse.
Elegiremos siempre los elementos de acuerdo al tipo de entrada que esperamos para ajustarnos a los estándares y desde ahí podremos sofisticar nuestros componentes de entrada para aquellos dispositivos que permitan algo más de personalización.
En cuanto a su diseño, debemos trabajar tanto con las etiquetas y los placeholders ya mencionados como con las máscaras y los textos de ayuda y validación de errores que veremos a continuación.
¿Cuándo usar un elemento tipo check, radio, toggle o select?
Los elementos toggle son elmentos biestado (activo/desactivo) que se popularizaron en dispositivos móviles para evitar crear un formulario para cada opción de configuración. Se espera de ellos que tenga una función autosubmit, es decir, que tengan efecto en el momento de modificarlos y no sea necesario accionar nada más.
Los checkboxes también son elementos biestado, en los que cada elemento puede tener dos valores posibles: activo o desactivo; suelen usarse dentro de un formulario con más campos o bien cuando la acción de enviar datos debe hacerse de forma explícita. Los checkboxes nunca deben enviarse automáticamente como haríamos con los toggle buttons.
Cuando se hacen necesarios más de 5 checkboxes, es recomendable usar un elemento de selección múltiple, y si la lista es aún mayor a 10 elementos puede ser necesario un buscador en línea dentro del desplegable.
Por otro lado, los radiobuttons se hacen necesarios cuando sólo se puede seleccionar una opción dentro de un grupo. Al igual que con los checkboxes, cuando tenemos más de 3 opciones, es más adecuado usar un elemento de selección.
Máscaras: en entradas numéricas, siempre.
Las máscaras limitan los datos de entrada permitidos, por ejemplo fechas y horas, para asegurar que sólo se introducen valores válidos: horas dentro de un rango de 1 a 24. Bien usadas, las máscaras evitarán errores y además mostrarán una guía del formato esperado.
Algunos elementos con máscara habituales son:
- Entradas numéricas: para incrementar o decrementar valores.
- Sliders: para seleccionar valores dentro de un rango tales como porcentajes.
- Selectores de fecha: para añadir formatos de fecha de acuerdo a la localización de un sitio.
- Selectores de tiempo.
- Entradas de datos como números de teléfono, tarjetas de crédito, o direcciones postales también se beneficiarán de usar máscaras ya que en muchas ocasiones la cantidad de caracteres es tan larga que la máscara facilita una división en grupos más pequeños.
Ayuda y validación: concisos, útiles y claros.
La ayuda en formularios es muy necesaria tanto para entender valores válidos (cuando las restricciones no son estándares) como el formato esperado (cuando la máscara usada no es obvia).
La ayuda puede mostrarse como un elemento tipo tooltip (mostrándose únicamente cuando se sobrevuela un icono de información), o bien como un texto descriptivo (Help text o Hint text) siempre visible cuando la descripción del campo es muy importante y no es familiar.
- Usa tooltips siempre que incluyas información adicional, no necesaria pero útil a la hora de pedir datos a las personas usuarias.
- Los tooltips y help texts son microcontenido, por lo que recuerda escribirlos de forma concisa, clara y útil.
- Nunca uses los tooltips para información esencial. En estos casos usa help texts.
- Piensa en los help text como si fueran una etiqueta extendida, no para sustituirlas, pero sí para cuando ayuden su entendimiento.
- Los help texts no deben exceder el ancho del campo que acompaña.
Validación de errores
A veces es inevitable que las personas nos equivoquemos rellenando un formulario, por lo que la información que mostremos sobre los errores provocados deberá ser suficiente para:
- Entender dónde está el error.
- Saber cómo corregirlo.
Tanto si los campos llevan help texts, como si no, debemos mantener un espacio reservado para los errores junto a cada campo.
A la hora de mostrar las validaciones será necesario mostrarlas en ese espacio y debemos evitar saltos y cambios de altura del formulario provocados por los errores.
- No uses tooltips para mostrar un error de validación (no son tan accesibles ni están visibles permanentemente).
- Muestra el error sustituyendo el campo de descripción (help text).
- Deja los errores visibles hasta que se quite el foco del campo que lo contiene. No valides ni corrijas un error mientras el usuario escribe.
- No deshabilites el botón de enviar el formulario. Ante la confusión, es mejor enviar un formulario y esperar a recibir los errores que no poder enviar nada y no saber por qué aún no puede enviarse el formulario.
- Muestra confirmación de envío del formulario clara, y los siguientes pasos para el usuario.
Campos obligatorios vs opcionales (preferibles)
Por lo general, cuando diseñamos un formularios intentaremos pedir la mínima información necesaria para un fin concreto.
Teniendo en cuenta que debemos indicar si los campos son obligatorios u opcionales dependiendo de la cantidad que tengamos de cada tipo, en la mayoría de los casos será más conveniente indicar qué campos son opcionales ya que serán los que menos abunden.
- Para indicar campos obligatorios solemos usar el estándar (*), es decir un asterisco junto a la etiqueta del campo.
- Para indicar campos opcionales solemos incluir un texto junto a la etiqueta: (opcional).
En el caso de campos opcionales, puedes usar tooltips que expliquen por qué se solicita dicha información.
Agrupación: separar por categorías.
Cuando la información que se pida en un formulario sea de distinta naturaleza, puede ser conveniente agruparlos visualmente.
Cuando tratamos además con formularios muy largos, la agrupación puede llegar a requerir otro tipo de patrón conocido como Wizard, donde además de agrupar visualmente dentro de la misma vista, paginamos los campos en distintas secciones por las que vamos progresando a medida que rellenamos el formulario.
Los wizards tienen la ventaja de simplificar la tarea compleja de rellenar un formulario demasiado largo, si bien requiere de un análisis más profundo de qué información es necesaria en cada paso teniendo en cuenta que existe un riesgo de abandono mayor.
Llamadas a la acción: qué sucederá.
Por último y no menos importante tenemos que poner especial atención en las llamadas a la acción o textos que rotulan los botones para enviar la información recogida en un formulario.
Trataremos de evitar palabras vagas como 'Enviar' y buscaremos textos que realmente nos digan qué va a suceder cuando interactúe con ese botón, como por ejemplo:
- Crear cuenta
- Suscríbete
- Publicar artículo
- ...
Los contenidos de los botones deben ser muy concisos y específicos, usaremos muy pocas palabras que incluyan la acción claramente, y deberán ir ajustados también al tono general del producto.
Otras lecturas
Rachel Adnyana
The Manifest
Member discussion