jueves, 28 de febrero de 2008

Formularios usables: 60 Directrices de Usabilidad

Artículos relacionados
[19-07-07] Formulario con varios botones. Implementación usable ...
[02-06-09]Formularios accesibles según las WCAG 2.0



Fuentes del artículo

60 Directrices para realizar formularios usables


Generales



1. Pida sólo la información absolutamente necesaria.

2. Infiera información a partir de otra disponible.

Por ejemplo, la provincia se puede inferir del C.P.

3. Reutilice los campos cuando sea posible.

Por ejemplo, el email puede servirnos en ocasiones como nombre de usuario.

4. No pida la información dos veces.

Por ejemplo, si el usuario ha rellenado la dirección de facturación, no le obligue a volver a rellenar la dirección de envío si no es necesario, pregúntele si quiere que sea la misma.


Textos



5. Proporcione un título al formulario que exprese claramente su función.

6. Si necesita instrucciones, que sean breves y comprensibles.

7. Utilice una nomenclatura clara y familiar, sin tecnicismos ni extranjerismos.

8. Sea consistente en el uso de los términos.

Es decir, use siempre las mismas palabras para los mismos conceptos.

9. No utilice preguntas complejas ni haga pensar al usuario.

10. Redacte siempre las opciones de forma afirmativa.

Por ejemplo, junto a un check escriba “Deseo recibir el boletín" en vez de "No deseo recibir el boletín".


Organización



11. Organice los campos en una sola columna de datos.

Sin entrar en las razones de accesibilidad que lo justifican (ver "75 Directrices de accesibilidad de Jakob Nielsen") me cuesta muchas discusiones hacer comprender que, apelotonando los datos en la misma línea o colocándolos en varias columnas, se pierde tanto a nivel de usabilidad que no merece la pena el espacio vertical que se gana.

Como siempre, hay muchos contextos de uso y excepciones justificables, como los formularios que se rellenan de forma repetitiva y constante, pero la excepción nunca puede convertirse en norma.

Una sola columna funciona mejor. Los formularios con dos columnas tienen más probabilidades de que los usuarios pasen por alto algunos campos, dado que crean un orden ambiguo de lectura. Sus ojos se moverán hacia donde espera encontrar el próximo campo, que será habitualmente hacia abajo, en vertical. No esperan a que se les indique mediante el parpadeo del cursor dónde mirar.

[En "Formularios largos: ¿una pantalla con scroll o varias páginas?" de Usolab (resumen en español del artículo "Caroline's Corner - Long Forms: Scroll or Tab?" de Caroline Jarrett)]


12. Organice los campos en grupos lógicos, utilizando para ello la mínima cantidad de elementos visuales (evitando así ruido visual).

13. Agrupe, si es posible, los campos obligatorios al comienzo del formulario.

14. Evite fragmentar la petición de información.

Por ejemplo, no pida por separado el tipo de vía, la calle, el número, etc. si no es estrictamente necesario.

15. Proporcione un diseño ordenado, alineando verticalmente todas las etiquetas y todos los campos entre si.


Todos los campos deben estar verticalmente alineados entre sí a la izquierda.

¿Cómo alinear las etiquetas entre sí: a la derecha, a la izquierda o las colocamos encima del campo?
  • Si tenemos que rellenar datos que son familiares (y no son muchos): Etiquetas en vertical encima del campo.
  • Cuando necesitemos ajustar el espacio vertical: Etiquetas a la izquierda del campo, alineadas a la derecha.
  • Hay que ajustar el espacio vertical, y los datos no nos son familiares o son complejos: Etiquetas al lado del campo, alineadas a la izquierda.

"Consejos para el diseño de formularios": resumen en español de las conclusiones de Luke Wroblewski



16. Sitúe las respuestas de los campos radio buttons y check box después de los mismos.

De esta manera se favorece la alineación vertical de todos los controles.

17. Utilice etiquetas estándar para agrupar campos y hacer más manejable la información(OPTGROUP, FIELDSET)

18. Si se utilizan radio buttons o checks box agrupe visualmente de forma clara y unívoca los distintos grupos de opciones.

19. Distinga visualmente los campos deshabilitados siguiendo las normas de facto (poniéndolos en gris claro)


Tipos de campos



20. El tamaño visible de los campos de texto debe corresponderse con la longitud del contenido que ha de introducir el usuario.

21. Homogeneice los anchos de los campos de texto cuando estos sean similares (evitando así ruido visual).

22. Dote a los campos de texto de flexibilidad para que admitan los datos en cualquier formato.

Por ejemplo, un campo para introducir el número teléfono debería admitir paréntesis, guiones, espacios; un campo para introducir importes debería admitir decimales con punto o con coma, etc.

23. Evite el uso de combos.

No las use por ejemplo para seleccionar el país, fecha o profesión a no ser que sea estrictamente necesario, en cuyo caso incluya una opción del tipo “Otros” que pueda englobar casos no recogidos en las opciones proporcionadas.

24. Evite que las combos recarguen la página para rellenar otros campos, pero cuando así sea, asegúrese de que el formulario conserva el mismo estado que tenía antes de recargar la página: con los mismos campos visibles o activos, y con todos los campos rellenos con los mismos datos que antes de la recarga.

25. Si se utilizan combos o radio buttons seleccione siempre una opción por defecto, asegurándose de que sea la más probable.

De lo contrario, el usuario no puede volver al estado inicial del formulario; si es necesario incluya una opción "Ninguna".


26. Si se utiliza un check box para presentar una única opción que no es obligatoria (recibir publicidad, aceptar unas cláusulas) no la marque por defecto.

27. Si se utilizan radio buttons asegúrese de que todas las opciones son claramente excluyentes.
  • No los utilice cuando las respuestas sean más de tres y complejas, o más de cinco y simples.
  • Siempre que se cumpla la regla anterior, utilice radio buttons en vez de combos


28. Si un radio button tiene más de dos respuestas, colóquelas en vertical, unas debajo de otras alineadas a la izquierda.


Funcionamiento



29. Valore la posibilidad de evitar, mediante JavaScript, que en determinados campos se pueda introducir determinados caracteres.

Por ejemplo, que en el campo DNI sólo se puedan introducir números y letras, haciendo que el resto de caracteres no se puedan teclear en el campo.

[A mí, personalmente, no me gusta esta práctica]

30. No implemente saltos automáticos del foco del formulario.

Por ejemplo, en los campos de cuenta, no haga que el foco se mueva sólo al siguiente campo cuando se ha rellenado el anterior.

Un error típico es introducir el salto automático entre campos de texto consecutivos y hacer innecesario el uso del tabulador.

Aunque este comportamiento puede parecer que facilita la tarea de introducción de datos, no es adecuado porque quita control a los usuarios, no es un funcionamiento estándar y es necesario mirar la pantalla para saber en que campo se está.

Todo ello puede provocar fácilmente errores, como por ejemplo, introducir datos pertenecientes a un campo en el siguiente cuando no se introduce el formato esperado por el salto automático.

[En "Controles de formularios en diseño web, radio buttons, check-boxes..." de Eduardo Manchón]

Además es un práctica prohibida en las WCAG 2.0 "3.2.2 On Input: Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)" aunque admiten que se implemente si se avisa antes al usuario de este comportamiento.


31. Asegúrese de que la tecla "Intro" realiza la acción principal.

32. Evite, mediante JavaScript, que el usuario pueda impacientarse y enviar dos veces el formulario.

33. Al implementar la validación de los formularios (o al limitar el tamaño de los campos) piense si su formulario puede ser utilizado por usuarios de otros países.

Por ejemplo, el C.P. o el teléfono no tienen la misma longitud en unos países que en otros; por ejemplo, en España hay usuarios que no tienen DNI sino tarjeta de residencia.


Ayudas



34. Identifique claramente los campos obligatorios y los opcionales mediante el literal (Obligatorio) u (Opcional), según si se van a marcar los obligatorios o los opcionales, colocando dicho literal detrás de la etiqueta del campo y por tanto antes del campo.



Para saber si marcar los obligatorios o los opcionales seguir las directrices de Luke Wroblewski:
  • Indique los campos obligatorios cuando sean menos que los opcionales.
  • Indique los campos opcionales cuando sean menos que los obligatorios.

Para saber por qué poner el texto (Obligatorio) u (Opcional) después del literal y no después del campo, o por qué se debe indicar mediante un texto y no mediante un asterisco, leer "75 Directrices de accesibilidad de Jakob Nielsen"



35. Incluir ayudas breves o ejemplos junto a los campos, pero sólo cuando sea realmente necesario para saber cómo ingresar un dato.

Asegúrese de que al leer en línea estas ayudas o ejemplos se lean antes que el campo, por ello, un buen lugar para colocarlas es encima del campo. Para comprender por qué colocarlas en esta posición leer: "75 Directrices de accesibilidad de Jakob Nielsen"


Botones



36. No incluya un botón "Reset" (es decir, de Limpiar o Borrar el formulario)

37. En los formularios de un sólo paso evite tener un botón "Cancelar" cuya función sea en realidad volver a la página anterior.

38. Distinga entre las acciones primarias y secundarias (volver, imprimir etc.) de su formulario.

Evite las secundarias, pero si ha de incluirlas distíngalas visualmente de forma inequívoca, destacando visualmente las primarias.

Por ejemplo, poniendo las acciones primarias como botones y las secundarias como enlaces.

39. Coloque los botones o enlaces que realizan las acciones primarias (por ejemplo el botón "Enviar") lo más cerca posible del último campo del formulario. No los separé del formulario mediante, por ejemplo, una línea.

40. Dé un nombre adecuado a los botones del formulario, relacionado con su acción y no de carácter general.

Por ejemplo, use "Buscar" en vez de un genérico "Aceptar".


Errores



41. Cuando se produzca un error al rellenar el formulario proporcione en la parte superior del mismo, y con suficiente contraste, un listado de los errores. Por cada error indique qué campo lo ha provocado, por qué motivo, cómo solucionarlo y un enlace al campo.

42. Destaqué los campos que han dado error pero no se base para ello únicamente en el color.

Acompáñelos de un icono de error que aparezca también en el resumen del comienzo de la página.

Repita el mensaje de error al lado del campo para no tener que volver a la lista inicial para saber qué error lo provocó. Ver un ejemplo de cómo mostrar los errores de un formulario.

43. Cuando se produzca un error, el formulario no debe resetearse, es decir, los campos no erróneos deben seguir manteniendo la información en ellos introducida.

44. Redactar claramente los textos de error mediante términos claros, sencillos y no técnicos.

No utilizar mensajes genéricos del tipo “No se ha podido enviar el formulario”.

45. Evite validar los campos uno a uno, cuando pierden el foco, mostrando inmediatamente un mensaje de error al usuario. A los usuarios les incomoda esta práctica.


Feedback



46. Cuando el usuario envíe el formulario, infórmele del resultado de su acción: indíquele si se ha realizado correctamente, qué datos se han enviado, cómo puede ponerse en contacto con los responsables del sitio si ha habido problemas o para hacer un seguimiento del mismo, o cómo puede modificar los datos enviados.

47. Si el proceso de envío es lento, incluya en la página un mensaje de "enviando datos".


Respuesta



48. Informe a los usuarios de por qué deben rellenar el formulario y cuándo y a través de que medio recibirán una respuesta.

49. Si es un formulario de contacto envíe un email automático confirmado que se ha recibido.

50. Si es un formulario de contacto, asegúrese de que la empresa tenga los mecanismos necesarios para responder de forma rápida y adecuada al mismo.


Legalidad



51. Incluya las cláusulas de protección de datos cuando sea pertinente.

Accesibilidad



52. Asocie explícitamente las etiquetas con sus controles mediante LABEL y su atributo "for".

53. Compruebe que el tabulador permite acceder a todos los campos en el mismo orden que el visual.

54. Mejore la experiencia del usuario mediante JavaScript y AJAX pero asegúrese que el formulario funcione correctamente sin ellos.

55. No establezca un límite de tiempo ajustado para complementar el formulario.


Formularios extensos



56. Si los formularios son muy extensos la solución no son las columnas, sino la división en páginas bien rotuladas que indiquen al usuario en que paso está del proceso (por ejemplo Paso 3 de 4).

57. Si el formulario se presenta en varias páginas hay que seguir el lema 1 tema = 1 página.

58. El usuario debe poder volver a los pasos anteriores.

59. No solicite información externa en medio del proceso mediante la abertura de una ventana nueva del navegador.

60. Evite la utilización de pestañas para crear formularios de varias páginas.


Fuentes




Artículos relacionados
[19-07-07] Formulario con varios botones. Implementación usable ...
[02-06-09]Formularios accesibles según las WCAG 2.0

28 comentarios :
gjose1234 dijo...

Que tal Olga, muy bueno tu post, bastante util sobre todo para hacerle entender a los clientes que quieres recolectar 10mil datos de los usuarios!! gracias!

Anónimo dijo...

El post de todos los tiempos sobre formularios. Enhorabuena.

Manu Medina Marsilla dijo...

Hola Olga,
Me gustaría añadir otro punto más que creo que es muy importante. Es el tema de los campos de fechas. Mucha gente lo pone con guiones otros con barras y a veces también si el campo lo rellenan gente extrajera pueden cambiar el orden del día y el mes. Para ello la mejor solución es poner el campo fecha con 3 desplegables, uno el Día, otro el més y en otro el año. Así nos evitamos un monton de problemas y visualmente es muy claro.
Gracias por este post tan recomendable.

Anónimo dijo...

Olga:

Muchas felicidades por tan buen artículo.

Me pareció también muy profesional el agregar, al final del artículo, las referencias o fuentes de información.

Luis

Anónimo dijo...

Gracias Olga por compartir unos conocimientos tan interesantes.

Estoy bastante o muy de acuerdo en casi todos los puntos, excepto en uno principalmente, que es el 45: "Evite validar los campos uno a uno, cuando pierden el foco". A mí personalmente me parece correcto y cómodo que si relleno mal un campo me indique al momento que está mal, ya que tengo la vista puesta en esa zona de la pantalla, además, así evito recibir un mensaje de error con las campos mal puestos una vez ya había enviado el formulario.

Otro tema sería el hecho que se requiere tener el javascript activado para ello, pero yo considero esta opción como un plus de calidad.

Un cordial saludo.

Anónimo dijo...

demasiado útil, gracias

Anónimo dijo...

Excelente aporte Olga.. gracias...!!

Anónimo dijo...

Yo añadiría que el foco esté siempre por defecto en el primer campo del formulario.

Olga Carreras dijo...

Contestando a Manu Medina, sobre poner las fechas en combos

Las combos no se deben utilizar para los campos fechas:

1. Es mucho más rápido escribir en un campo de texto que seleccionar de una combo.

2. La página pesa mucho menos con campos de texto que con combos.

Por tanto el usario baja antes la página y termina antes el proceso con inputs que con combos.

Los combos tienen además una razón de ser que debe respetarse:

Los combos se utilizan para evitar errores en la introducción de información, pero en ese sentido solo se deben utilizar cuando la importancia de la corrección de los datos sea tan crítica que obligue a ello.

No es razonable utilizar combos indiscriminadamente y para opciones innecesarias u otras demasiado largas.

Por ejemplo, si en el combo "país" se incluyen todos los países del mundo se hace muy difícil de utilizar.

El usuario escribe antes el nombre del país manualmente que seleccionándolo en un combo de más de 100 opciones.

Además "país" en la mayoría de los casos no es un campo crítico y su ratio de errores muy bajo.


Eduardo Manchón

Una buena opción es poner tres campos de textos, separados por una barra (/) y una ayuda contextual del tipo dd/mm/aaaa

Olga Carreras dijo...

Contestando a anónimo sobre poner el foco en el primer campo

En ese caso es importante que la colocación del foco en el primer campo no se realice en el onload de la página, sino nada más cargarse el campo.

De lo contrario, si colocas el foco en el primer campo cuando termina de cargarse la página, puede que el usuario ya hubiera puesto el foco en otro campo.

Olga Carreras dijo...

Contestando a Javier Seixas sobre el punto 45

Yo también creo que si esa validación en línea no hace más pesada la página y se realiza de forma inmediata con AJAX, puede ser una ayuda.

Pero lo cierto es que el exceso no suele ser una virtud, ¿realmente es necesario en un formulario bien diseñado y comentado llegar hasta este punto?

Si los estudios dicen que el usuario puede vivirlo como un exceso de control, y sentirse agobiado y frustando viendo mensajes de error cada vez que se le ocurre pasar por un campo, supongo que será cierto.

Me gustaría realizar un test de usuarios para comprobarlo por mi misma.

Anónimo dijo...

Muy bueno tu post, me dejas enlazarlo!

Anónimo dijo...

Muy buen resumen.

Lástima que despues llegue el director de cualquier unidad (cliente) y se le de por opinar en contra de todos los estudios de usabilidad.

Y aunque intentes razonar con argumento llega un momento que tienes que tragar porque al fin y al cabo no puedes ir en contra de tu cliente.

Anónimo dijo...

El post más completo que he visto sobre este tema. Gracias por compartir, Olga.

ghs dijo...

2. Infiera información a partir de otra disponible.

Por ejemplo, la provincia se puede inferir del C.P.

- depende del pais, se puede y no :)



23. Evite el uso de combos.

No las use por ejemplo para seleccionar el país, fecha o profesión a no ser que sea estrictamente necesario, en cuyo caso incluya una opción del tipo “Otros” que pueda englobar casos no recogidos en las opciones proporcionadas.

- en ese caso hay que utilizar javascript para mostrar otro campo y recojer los datos necesarios



25. Si se utilizan combos o radio buttons seleccione siempre una opción por defecto, asegurándose de que sea la más probable.

De lo contrario, el usuario no puede volver al estado inicial del formulario; si es necesario incluya una opción "Ninguna".

- entonces en una lista de suscripción de radio ruttons (ej. de 100€, 200€ y 1000€) que hacemos?? activamos por defecto el de 1000€ porque a nosotros nos va mejor o? para mi, en una lista de radios nunca se debe selecionar un valor por defecto. se deberia comprobar al enviar el formulario o mediante JS. en un select si que se puede meter un "seleciona..."



32. Evite, mediante JavaScript, que el usuario pueda impacientarse y enviar dos veces el formulario.

- esto se puede resolver mediante el lenguaje de programacion utilizado.



33. Al implementar la validación de los formularios (o al limitar el tamaño de los campos) piense si su formulario puede ser utilizado por usuarios de otros países.

Por ejemplo, el C.P. o el teléfono no tienen la misma longitud en unos países que en otros; por ejemplo, en España hay usuarios que no tienen DNI sino tarjeta de residencia.

- no se, no se,... aqui se pueden hacer varias cosas, pero eso depende de la persona que hace el formulario y las especificaciones del proyecto. dependiendo del pais, se pueden mostrar unos campos u otros. depende de muchas cosas.



47. Si el proceso de envío es lento, incluya en la página un mensaje de "enviando datos".

- se deberia utilizar JS para esto. y tampoco se puede saber si el envio es lento o rapido. todo depende del servidor que recibe los datos.



49. Si es un formulario de contacto envíe un email automático confirmado que se ha recibido.

- eso esta bien, pero muchas veces confirmaciones de esas van directamente a SPAM y el usuario no las ve nunca.



54. Mejore la experiencia del usuario mediante JavaScript y AJAX pero asegúrese que el formulario funcione correctamente sin ellos.

- si el formulario tiene que funcionar de la misma manera sin JS, nunca se podria representar la informacion del mismo modo. siempre habra comentarios del tipo: "joer... que pasa ahora..." "... en que me he equivocado..." "... que mas falta..."

Olga Carreras dijo...

La usabilidad es sentido comun, el uso de directrices implica usar también el sentido comun, por eso hay mucha gente a la que no le gusta que se pongan directrices, porque siempre hay quien no quiere o no sabe usar su sentido comun.

2. Infiera información a partir de otra disponible.

Cuando sea posible, evidentemente.

23. No entiendo el comentario, simplemente recoge el campo en un input de texto

25. Está claro que en una selección donde sea imposible una selección por defecto, pues no se pondrá poner una selección por defecto.

32. Mientras lo evites, evitalo de la mejor manera posible.

33. Mientras lo tengas en cuenta, resuelvelo de la manera más óptima

47. Sí, se pone con JavaScript, y aunque no sea lento el envío nunca está de más, puesto que si va rápido apenas aparecerá el mensaje y ya está.

49. ¿Y por eso vamos a dejar de hacerlo?

54. Te recomiendo mis artículos de AJAX accesible.

Anónimo dijo...

Muy bueno el post, felicidades.

Sólo un comentario sobre el punto 30. Reciéntemente he realizado un test de usuarios para una web de banca en el que habían tareas tipo transferencias, y te puedo asegurar que la gran mayoría de los usuarios esperaban que el cursor saltara de línea automáticamente al introducir la CC (y se quejaban si tenían que hacerlo a mano).

Anónimo dijo...

Hola Olga:

Una pregunta.

Uno de los puntos de revisión para la accesibilidad de forms, indica:

"Hasta que las aplicaciones de usuario manejen correctamente los controles vacíos, incluya caracteres por defecto en los cuadros de edición y áreas de texto"

Bien. No hay mayor problema. Incluyo el valor "value", ahora, me gustaría saber si hay forma alguna de hacer que este texto desaparezca al fijar el foco, que imagino que tendrá que ser con javascript, y esto es de todo menos accesible ¿verdad?

Muchas gracias.

Jorge Guevara dijo...

"Por desgracia, es a menudo el programador quien hace el diseño de los formularios"

Cómo que por desgracia, quien dijo que los programadores no sabemos de usabilidad, me parece que generalizar en este tema es algo irresponsable. Una de las labores del programador es buscar que sus interfaces sean lo más 'cómodas' para el usuario y combinar el código con el diseño de la mejor manera.

Interesante artículo de cosas que muchos programadores sabemos

Unknown dijo...

Hola, soy principiante en esto de las paginas dinamicas y con esto me salvaste. Muchas gracias.

Unknown dijo...

Hola Olga!
Muy bueno el post.
Personalmente se me complica el tema de hacer formularios a una sola columna. Yo diseño aplicaciones de negocio para una empresa de salud. Son herramientas complejas donde el usuario tiene que si o si cargar muchos datos y son de uso cotidiano.Tambien hay que tener en cuenta que hay capacitaciones para el uso de esta herramienta porque el negocio de empresa, los procesos internos tiene que ver con esto. Son aplicaciones de una intreaanet no son de uso masivo ni público.
Los formularios son grandes, el 80%de la pantalla son formularios.
Diseñar este tipo de herramientas a una sola columna es terminar haciendo escroles infinitos o diseñar menues eternos.
Ademas de dejar en blanco un gran porcentual de una pantalla widescreen.

Saludos,
Mariela

Wo Contenidos dijo...

Es de gran ayuda esta entrada. Muchas gracias¡

Ignacio dijo...

Excelente checklist Olga, estoy de acuerdo contigo en la respuesta a Manu Medina, sobre los campos fecha. En USERTIC (www.usertic.com) la empresa en la que trabajo muchos clientes nos sugieren poner las fechas como combos pero hemos comprado en varios test de usabilidad que los usuarios tardan demasiado en poner las fecha, sobre todo cuando son fechas del pasado.

Nosotros recomendamos usar campos con una máscara bien identificada

Olga Carreras dijo...

Alfonso marcos vidal
Ya no es es necesario en las WCAG 2.0

Alex Lillo
En las WCAG 2.0 se prohíbe porque es un cambio de contexto no solicitado por el usuario

Anónimo dijo...

Hola Olga. Veo que cuando los formularios son largos y los fragmentas en pasos no haces referencia a una pagina de resumen antes de terminar el proceso.

Mirulu dijo...

Hola Olga,

De caa a mostra un rango de fechas, a modo informativo ¿qué opció seria la más usable? p.e el cursos se realizará:

1.- del lunes 26 enero 2020 al martes 28 julio 2020

o bien la que yo creo que es mejor:

2.- Fecha de inicio - fin : 26/01/2020 - 28/07/2020

Saludos,

Olga Carreras dijo...

Hola, entiendo que hablamos de un texto informativo y no de un formulario, que tal:

Fecha de inicio: lunes 26 de enero de 2020
Fecha de fin: martes 28 de julio de 2020

Las fechas se comprenden mejor así.

Makrodownload - plugins wordpress dijo...

interesante articulo, gracias por compartir

Publicar un comentario