{"id":5,"date":"2021-02-20T21:13:00","date_gmt":"2021-02-20T20:13:00","guid":{"rendered":"https:\/\/www.guille-rmo.com\/blog\/?p=5"},"modified":"2021-03-10T17:23:05","modified_gmt":"2021-03-10T16:23:05","slug":"pautas-para-disenar-formularios-eficientes-usables","status":"publish","type":"post","link":"https:\/\/www.guille-rmo.com\/blog\/pautas-para-disenar-formularios-eficientes-usables\/","title":{"rendered":"Pautas para dise\u00f1ar formularios eficientes y usables"},"content":{"rendered":"\n

\u00bfEs \u00e9ste otro art\u00edculo m\u00e1s sobre formularios? S\u00ed, lo es. Pero, tras haber le\u00eddo informaci\u00f3n de muchas fuentes, trabajar en el sector de la banca digital (donde hay formularios hasta en el caf\u00e9) y haber tenido que luchar con ellos en repetidas ocasiones, me he animado a reunir en estas l\u00edneas el conocimiento adquirido.<\/p>\n\n\n\n

Una sola columna evita confusiones<\/h2>\n\n\n\n

La distribuci\u00f3n vertical de los elementos de un formulario en una sola columna genera una lectura m\u00e1s sencilla, r\u00e1pida y natural para el usuario.<\/p>\n\n\n\n

Evitar una estructura de varias columnas ahorrar\u00e1 equivocaciones a la hora de comprender el orden (si lo hay) del formulario, campos sin cumplimentar, datos incorrectamente introducidos o la frustraci\u00f3n y el posterior abandono del proceso.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Por otro lado, las asociaciones entre campos que tengan una l\u00f3gica f\u00e1cil de comprender puede justificar disponerlos juntos y a la misma altura. Por ejemplo, un campo que recoja un nombre junto a otro de apellido, o un selector de c\u00f3digo de pa\u00eds al lado de un campo cuyo contenido sea un n\u00famero de tel\u00e9fono.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Utiliza correctamente cada tipo de campo seg\u00fan su contenido<\/h2>\n\n\n\n

Existen diferentes tipos de campos de texto. O, dicho de otra manera, hay modificaciones sobre el elemento \u00abcampo de texto\u00bb que han surgido por la necesidad de recoger distintos tipos de datos (num\u00e9ricos, cadenas de texto, fechas, selecciones, etc).<\/p>\n\n\n\n

Por ejemplificar: en el caso de un campo que vaya a recoger un n\u00famero de tel\u00e9fono, lo correcto ser\u00e1 utilizar uno que s\u00f3lo admita introducir d\u00edgitos y no letras. Evitaremos posibles errores y tambi\u00e9n ayudaremos, en dispositivos m\u00f3viles sobre todo, a que se muestre el teclado correcto (num\u00e9rico o alfab\u00e9tico) cuando el usuario haga foco en el campo en cuesti\u00f3n.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Etiquetas (labels<\/em>)<\/h2>\n\n\n\n

Existen diferentes opiniones y estudios sobre las ventajas y desventajas de situar la etiqueta encima del campo, a la izquierda o si utilizar un placeholder<\/em> dentro del mismo.<\/p>\n\n\n\n

No entrar\u00e9 a analizar dichos estudios y me limitar\u00e9 a dar mi punto de vista: con el objetivo de facilitar al m\u00e1ximo la lectura, ubicar la etiqueta encima del campo al que corresponde es la mejor opci\u00f3n. Adem\u00e1s, creo que de esta manera evitaremos dolores de cabeza a la hora de dise\u00f1ar el formulario en su conjunto.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Tip:<\/strong> evita la capitalizaci\u00f3n de las etiquetas, hacen m\u00e1s dif\u00edcil su lectura.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Los placeholders<\/em> no son etiquetas<\/h2>\n\n\n\n

A veces los placeholders<\/em> confunden m\u00e1s que ayudan. Esto se debe a que se suelen utilizar como etiquetas y, como es natural en su comportamiento, desaparecen cuando el usuario interact\u00faa con el campo. El efecto inmediato y negativo es que dejamos al usuario sin la capacidad de verificar, antes de enviar el formulario, la informaci\u00f3n que proporcion\u00f3.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La recomendaci\u00f3n es evitar su uso y, en el caso de querer proporcionar informaci\u00f3n extra, utilizar textos de ayuda fuera del campo que ayuden a completarlo con \u00e9xito.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Define la longitud de los campos proporcionalmente al contenido esperado<\/h2>\n\n\n\n

Reconozco que un formulario alineado es, en muchos casos, visualmente m\u00e1s atractivo y compensado.<\/p>\n\n\n\n

Aun as\u00ed, acomodar la longitud de cada campo al volumen de contenido esperado facilitar\u00e1 la lectura del formulario y guiar\u00e1 visualmente al usuario para una mejor comprensi\u00f3n del mismo.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La validaci\u00f3n \u00aben directo\u00bb es tu mejor aliada<\/h2>\n\n\n\n

Ayuda al usuario con feedback<\/em> (mensajes de ayuda) instant\u00e1neo en los campos que requieran un formato espec\u00edfico. No hay peor sensaci\u00f3n que terminar de completar un formulario con muchos elementos y que, al enviarlo, aparezcan errores que podr\u00edamos haber evitado con algunas directrices.<\/p>\n\n\n\n

Esto se ve muy claramente en los campos del tipo \u00abemail\u00bb, en los que los caracteres de arroba (@) y punto (.) deben estar presentes obligatoriamente. O, por poner otro ejemplo, en los campos de contrase\u00f1a, que suelen tener requisitos muy acotados y restrictivos para el usuario.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Reduce el n\u00famero de campos<\/h2>\n\n\n\n

La simplificaci\u00f3n de los elementos en pantalla reduce significativamente la carga visual y cognitiva del usuario. Si podemos aunar en un mismo campo nombre y apellidos o una fecha completa, mucho mejor.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n
\"\"<\/figure>\n\n\n\n

No ocultes opciones de selecci\u00f3n (si son pocas)<\/h2>\n\n\n\n

El usuario agradece tener la informaci\u00f3n disponible a la vista.<\/p>\n\n\n\n

Partiendo de esta premisa, en casu\u00edsticas en las que las opciones entre las que el usuario debe elegir sean pocas (yo suelo poner el l\u00edmite en unas 5 o 6), lo correcto es usar radio buttons<\/em> o checkboxes<\/em>. De esta manera estar\u00e1n visibles desde el primer momento en el que el usuario visualiza la interfaz.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Para casos donde el n\u00famero de opciones sea alto, es adecuado el uso de combos<\/em> (tambi\u00e9n llamados selects<\/em>).<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Campos obligatorios VS campos opcionales<\/h2>\n\n\n\n

Lo cierto es que el aprendizaje nos sugiere que todo campo que tiene un asterisco, normalmente en su etiqueta, es obligatorio. Contrario a esto, yo veo m\u00e1s adecuado marcar con un \u00abOpcional\u00bb los campos o elementos que el usuario pueda dejar sin completar.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

La raz\u00f3n es la siguiente: en mi experiencia (y seg\u00fan he le\u00eddo en otras fuentes), los campos opcionales para el usuario suelen ser menos numerosos con respecto a los campos obligatorios. Esto me hace pensar que tiene m\u00e1s sentido distinguir los primeros con un \u00abOpcional\u00bb, por ejemplo, que a\u00f1adir un asterisco a cada uno de los campos requeridos obligatoriamente y, en consecuencia, saturar la interfaz con estos elementos que comparten el mismo significado.<\/p>\n\n\n\n

Agrupa los elementos de formulario relacionados<\/h2>\n\n\n\n

Esto ayudar\u00e1 a escanear mejor el formulario y a identificar r\u00e1pidamente los grupos de datos que le estemos pidiendo al usuario.<\/p>\n\n\n\n

Ejemplos comunes de agrupaci\u00f3n de datos en formularios son:<\/p>\n\n\n\n