UX y HTML5: Ayudemos a los usuarios a completar su formulario móvil (Parte 1)

Los formularios son una de las interacciones primarias más básicas que los usuarios tendrán con sus sitios web (y aplicaciones móviles). Unen a las personas y les permiten comunicarse. Les permiten comentar los artículos y explicarle al autor que no están de acuerdo con lo que han escrito. Permiten que las personas chateen directamente en una aplicación de citas para conocer a "el indicado". Ya sea para foros, pedidos de productos, comunidades en línea, creación de cuentas o pagos en línea, los formularios son una parte importante de la vida en línea de los usuarios.

Estamos en 2018 y tenemos más usuarios móviles que de escritorio en todo el mundo . Sin embargo, todavía tratamos a esos usuarios como ciudadanos de segunda clase de la web. Todo el mundo escribe y habla sobre la experiencia del usuario todo el tiempo. Entonces, ¿por qué, por qué, por qué tantos sitios web y productos todavía lo hacen mal? ¿Por qué su experiencia de usuario móvil está dañada para la mitad del mundo? ¿Por qué sigue siendo un dolor, por qué sigue siendo muy difícil reservar un vuelo y registrar una cuenta en un formulario móvil hoy? ¡Los usuarios esperan algo mejor!

Lectura recomendada : World Wide Web, Web occidental no rica

Esta es la primera parte de una serie de dos artículos. En este, resumiré algunas de las mejores prácticas esenciales para mejorar sus formularios móviles, incluida la capacidad de escaneo y legibilidad. Lo guiaré a través de la ubicación, el tamaño y la optimización de la etiqueta y la entrada. Veremos cómo elegir el elemento de formulario adecuado para reducir los costes de interacción. Finalmente, aprenderá cómo prevenir y tratar los errores en los formularios móviles.

En la segunda parte, analizaré más de cerca las capacidades móviles específicas y los elementos de formulario HTML5, e iremos más allá de los elementos de formulario clásicos para crear aplicaciones web y sitios web únicos y agradables.

Nota : Si bien la mayoría de las mejoras de código en este artículo están relacionadas con la web (porque no conozco Swift o Java), las mejores prácticas de usabilidad son válidas para las aplicaciones móviles .

Form Design 101: priorizando la escaneabilidad y la legibilidad

“Un formulario es el nombre, el valor, los pares, en una estructura para almacenar datos en una computadora vomitados como etiquetas y campos de entrada para el ser humano”. Esta es una cita directa de Luke Wroblewski en una conferencia. Al igual que él, creo que la mayoría de los problemas de usabilidad de los formularios provienen de esta tendencia a servir la estructura de la base de datos a los usuarios.

Arquitectura de información sólida

Para crear mejores formularios, primero debe alejarse unos pasos de la estructura de su base de datos. Trate de entender cómo los usuarios quieren completar los formularios. Aquí es donde se vuelve útil hacer algunas pruebas de usabilidad e investigación de usuarios en sus formularios. Los modelos mentales de usuario son un concepto de UX que puede ayudarte con eso. Nielsen Norman Group lo describe como “lo que el usuario cree sobre el sistema en cuestión”. Pídale a su evaluador que piense en voz alta y le diga cómo completaría el formulario. ¿Qué pasos esperan? ¿Qué viene primero? ¿Que viene despues? Esto le dará una mejor idea de cómo estructurar su formulario de una manera más fácil de usar.

La agrupación visual de campos que pertenecen juntos también ayudará a los usuarios a completar un formulario. En el código, use la etiqueta fieldset para agruparlos mediante programación. También ayudará a los lectores de pantalla a comprender la jerarquía.

Si el formulario es largo, no exponga todo por defecto . Sea inteligente con lo que muestra. Use la bifurcación de manera inteligente para mostrar solo los campos que la gente necesita. En un formulario de pago, por ejemplo, no muestre todos los campos detallados para todas las opciones de envío. Esto abrumará al usuario. Muestre suficiente información para ayudarlos a elegir la opción de envío correcta. Luego, muestre solo los detalles y campos relacionados con esa elección.

Los lapsos de atención del usuario se acortan con el tiempo: solicite cosas opcionales al final del formulario. Por ejemplo, si su formulario es una encuesta de satisfacción del cliente, solicite información demográfica al final. Mejor aún, complétalos automáticamente, si es posible. Pregunta a los usuarios solo lo necesario.

Finalmente, planifique con anticipación la localización: ¿Qué sucederá cuando se traduzca su formulario? ¿Qué pasará, digamos, con el alemán? ¿Seguirá funcionando tu diseño?

Colocación de etiquetas y optimización de entrada

El diseño de una sola columna funciona mejor

Debido a la falta de espacio, no obtiene infinitas opciones para colocar etiquetas y campos en las pantallas móviles:

• Presente los campos en un diseño de una sola columna . No hay espacio en el móvil para varias columnas. Los formularios de varias columnas tampoco son una gran idea en el escritorio.
• En el modo vertical, es mejor colocar la etiqueta en la parte superior del campo para que los usuarios puedan ver lo que hay en el campo cuando escriben.

• En el modo horizontal, la altura de la pantalla se reduce. Es posible que desee colocar etiquetas a la izquierda y entradas a la derecha . Pero pruébalo para asegurarte de que funciona.

Para obtener más información sobre la colocación de etiquetas, consulte "Usabilidad de formularios móviles: coloque etiquetas sobre el campo" del Baymard Institute.

Las etiquetas deben ser claras y visibles y funcionar sin contexto

Recuerde que tan pronto como se enfoca un campo, el teclado se abre y ocupará al menos un tercio del área de la pantalla. En pantallas móviles pequeñas, los usuarios también tendrán que desplazarse para completar el formulario. Esto significa que perderán parte del contexto mientras completan el formulario. Planifique en consecuencia:

• Sus etiquetas deben ser texto claro y visible que se pueda leer y comprender sin contexto. El usuario debe poder completar cada par de etiqueta y campo como una tarea separada, incluso si pierden contexto.

• Evite la jerga, las abreviaturas y el lenguaje específico de la industria siempre que pueda.
• Se consistente. Si usa "cliente" en una etiqueta una vez, quédese con esa palabra. Evite usar "clientes" más tarde porque podría confundir a los usuarios.
• El tamaño de la fuente debe ser lo suficientemente grande. Pruebe su formulario en dispositivos reales lo antes posible y ajuste el tamaño en consecuencia.
• El texto en mayúsculas puede ser difícil de leer para algunos usuarios. Es posible que desee evitar el uso de texto en mayúsculas en las etiquetas.
• La copia de la etiqueta debe ser breve y escaneable. Si un campo necesita aclaración, no lo ponga en la etiqueta. Utilice una descripción de campo en su lugar.

Mejores prácticas de tamaño de entrada

Si es posible, el tamaño del elemento de entrada debe coincidir con el tamaño del contenido esperado . Esto ayudará a los usuarios a completar rápidamente el formulario y comprender lo que se espera.

Uso de máscaras para evitar dividir las entradas en el móvil

No divida las entradas solo por formatear . Es especialmente molesto en dispositivos móviles, donde los usuarios no pueden usar el teclado para navegar entre campos. Requiere toques adicionales solo para ir al siguiente campo para completar el formulario. Puede que estés pensando: "Pero automáticamente pondré el foco en el siguiente campo cuando obtenga el número requerido de caracteres en ese campo". Eso podría funcionar. Pero habrá tomado el control de la interfaz de usuario, que se vuelve impredecible para el usuario. Además, sería un fastidio si los enviaras automáticamente al siguiente campo y necesitaran corregir algo en el último campo. Finalmente, es más complicado adivinar qué es obligatorio con entradas divididas. Por lo tanto, dejemos de jugar al juego "Pero qué pasaría si" y simplemente no dividamos las entradas.

Lo entiendo: aún desea poder formatear los datos de su usuario en pequeñas partes para ayudarlos a completar sus campos. Y tienes toda la razón en eso. Para ello, podrías utilizar mascarillas . En lugar de dividir una entrada, solo coloque una máscara encima para ayudar visualmente al usuario a completarla. Aquí hay un ejemplo de video de cómo se vería una máscara para ayudar a los usuarios a completar un campo de tarjeta de crédito:

Las máscaras ayudan a prevenir errores al guiar a los usuarios al formato correcto. Evite revelarlos gradualmente: muestre el formato directamente. Además, evite poner valores falsos en la máscara . Los usuarios pueden pensar que ya está lleno. Es por eso que reemplacé los números con una pequeña "X" en mi demostración. Encuentre lo que funciona mejor para su tipo de entrada.

Por último, recuerda que algunos datos pueden variar entre países y, en ocasiones, también cambia el formato (números de teléfono, por ejemplo). Planifique en consecuencia.

Descripciones de campos eficientes

Mostrar descripciones de campo eficientes puede marcar la diferencia entre una experiencia de formulario fluida y dolorosa.

¿Para qué se pueden usar las descripciones?

Las descripciones pueden ayudar a los usuarios de muchas maneras. Aquí están algunos ejemplos.

• ¿Qué estás pidiendo exactamente?
  

  Por cualquier motivo relacionado con la base de datos, algunas empresas de envío solicitan los campos "Dirección 1" y "Dirección 2". Esto es muy confuso para los usuarios, pero es posible que no tenga otra opción aquí. Agregue campos de descripción para ayudar a los usuarios a comprender lo que deben poner en cada campo.

  

  Lo mismo ocurre con las siglas y abreviaturas. Sé que dije que deberías evitarlos, pero a veces no puedes. Si trabaja con formularios complejos para una industria en particular, por ejemplo, es posible que tengan su propio conjunto de abreviaturas. Es posible que cualquier nuevo usuario que necesite completar el formulario no esté familiarizado (todavía) con esas abreviaturas. Tener una descripción disponible en algún lugar les ayudará.

• ¿Por qué necesita esta información?
  Los usuarios pueden ser reacios a brindarle información personal si no entienden por qué la necesita y qué hará con ella . Pero a veces aún necesita solicitar dicha información por razones legales (como la fecha de nacimiento de un sitio web que vende alcohol). El uso de descripciones de campo aquí ayudará a los usuarios a comprender por qué se necesita este tipo de información.
  
  

  En los sitios web de comercio electrónico, es posible que desee solicitar el número de teléfono del usuario en caso de que el repartidor necesite comunicarse con él. Esta es una razón legítima. Entonces, nuevamente, use descripciones para explicar a los usuarios de comercio electrónico por qué necesita su número de teléfono.

  

“¿Dónde encuentro la información?”
Si sus usuarios necesitan encontrar cierta información en otro lugar para completar un formulario, dígales dónde encontrarla. Trabajé en una aplicación móvil que permite al usuario rastrear su casa. Los usuarios necesitaban emparejar la aplicación con el dispositivo de monitoreo usando un número de serie. No es muy fácil encontrar este número de serie en el dispositivo; requiere alguna instrucción. ¿Añadimos un poco ? junto al campo del número de serie. El botón abre un modal que muestra una imagen y alguna indicación para ayudar al usuario a comprender dónde encontrar el número de serie en el dispositivo de monitoreo. Los sitios web de comercio electrónico hacen lo mismo con los códigos promocionales: brindan indicadores que indican a los usuarios dónde encontrar los códigos.



• “¿Cómo debo formatear la información?”
  Algunos campos necesitan un formato particular . En este caso, use descripciones para que los usuarios conozcan las reglas de formato por adelantado. Aquí están algunos ejemplos:
  • Número de teléfono: ¿debo poner el código de marcación internacional (+xx) delante del campo?
  • ¿Hay una longitud máxima? Twitter en dispositivos móviles hace un buen trabajo con eso.
  • Cuando se trata de cantidades monetarias, ¿el formato es una coma (como 10 000) o un espacio (como 10 000)?
  • ¿Qué formato esperas para las fechas? Te dejaré comprobar en Wikipedia qué pesadilla es esa. La diferencia entre DD MM AA y MM DD AA puede causar *muchos* problemas a los usuarios al reservar en línea.
  Tenga en cuenta que muchos de esos problemas de formato se pueden resolver con máscaras de entrada. Llegaremos a eso más adelante en el artículo (o puede saltar directamente si está impaciente).

  

Cómo mostrar descripciones

En los ejemplos anteriores, vimos algunas formas de mostrar las descripciones de los campos. Aquí hay un resumen de lo que debe hacer:

• Las descripciones en línea deben ser directamente visibles y mostrarse junto al campo.
• Si necesita descripciones más detalladas con mucho contenido, puede usar información sobre herramientas o modales . La información sobre herramientas generalmente se activa al pasar el mouse sobre el escritorio y al tocar en el móvil. Lo mismo ocurre con los modales: ábralo cuando el usuario toque el icono de ayuda o el enlace "ver más", por ejemplo.

Tenga cuidado con los marcadores de posición

Lo entiendo: es tentador eliminar campos en dispositivos móviles para ganar espacio y usar marcadores de posición en su lugar. Todos hemos ido por ese camino. Pero por favor no lo hagas. La especificación HML5 es clara al respecto: "El atributo de marcador de posición representa una breve pista (una palabra o frase corta) destinada a ayudar al usuario con la entrada de datos". Y he aquí por qué:

• El marcador de posición desaparece cuando el usuario comienza a escribir. Luego, el usuario debe confiar en la memoria a corto plazo para recordar lo que se supone que debe poner en el campo . Si no pueden, deberán vaciar el campo para ver la indicación.
• Es difícil para los usuarios verificar dos veces los campos antes de enviarlos porque los campos ya no tienen ninguna indicación de etiqueta.
• Es difícil recuperarse de los errores una vez que se ha enviado un campo porque, nuevamente, no hay una etiqueta para ayudar al usuario.

Incluso si usa marcadores de posición con etiquetas, es posible que aún tenga algunos problemas. Es difícil distinguir la diferencia entre un campo lleno y un campo con un marcador de posición . Soy un diseñador de UX que escribe sobre diseño de formularios móviles e incluso uno de ellos me engañó la semana pasada. Si me sucede a mí, les sucederá a sus usuarios, confíe en mí. Por último, la mayoría de los marcadores de posición tienen texto de color gris claro, por lo que es posible que también tenga algunos problemas de contraste.

Si desea profundizar más en este tema, hay un gran artículo llamado "El atributo de marcador de posición no es una etiqueta", y también Joshua Winn y FeedbackGuru detallan por qué es una mala idea. Nielsen Norman Group también escribió un artículo sobre el tema, llamado "Los marcadores de posición en los campos de formulario son dañinos".

Los marcadores de posición no son obligatorios en HTML5 . Desde el punto de vista de la usabilidad, ciertamente no necesita un marcador de posición en cada campo de su formulario. Pero con la adopción masiva de Bootstrap y otros marcos, parece que mucha gente simplemente copia y pega componentes. Esos componentes tienen marcadores de posición, así que supongo que la gente se siente un poco obligada a agregar algo al marcador de posición en el código. Si los marcadores de posición de su formulario se ven como "Complete su — etiqueta — aquí", lo está haciendo mal.

Sin embargo, las etiquetas dentro de los campos podrían funcionar bien para formularios cortos en los que los campos son predecibles . Los formularios de inicio de sesión son un buen candidato para esto. Pero no use el marcador de posición HTML5 para codificar esto. Use una etiqueta real en el código y muévala con CSS y JavaScript.

Desde el éxito del diseño de materiales de Android, ha comenzado a surgir un patrón: la etiqueta flotante. Esta etiqueta está dentro del campo cuando el campo no está completo, por lo que ocupa un poco menos de espacio vertical en el dispositivo móvil. Cuando los usuarios comienzan a interactuar con el campo, la etiqueta se mueve sobre el campo.

Esto parece una forma interesante de ganar algo de espacio, sin encontrarse con los problemas de "marcadores de posición en lugar de etiquetas" citados anteriormente. Sin embargo, no resuelve el problema de que los usuarios puedan confundir un marcador de posición con contenido rellenado.

Reducción de costos de interacción para formularios exitosos

Reducir el costo de interacción (es decir, la cantidad de toques, deslizamientos, etc.) de los usuarios que logran su tarea lo ayudará a crear una experiencia de formulario perfecta. Existen diferentes técnicas para lograrlo. Veamos algunos de ellos en detalle.

Un estudio mágico en Internet me dijo que redujera la cantidad de campos

Más campos significan menos conversiones, ¿verdad? Es posible que haya encontrado el estudio "redujimos nuestro formulario de suscripción de 11 a 4 campos, y aumentó las conversiones en un 160 %". Es un clásico. Y si miras su formulario de contacto, tiene sentido. ¿Por qué querrían los usuarios rellenar 11 campos solo para ponerse en contacto con la empresa? No se puede pedir un compromiso tan grande de personas que apenas te conocen, ¿verdad?

Comience preguntando solo por información útil. ¿Por qué necesita el género de una persona para crear una cuenta para ella? ¿Por qué tiene dos líneas para la dirección si su formulario de suscripción es para un servicio en línea?

Pide solo la información que necesites. Y luego pide la información en contexto. Si tiene un sitio web de comercio electrónico, los usuarios pueden estar más inclinados a darle su dirección en la sección de envío del proceso de pago que cuando se registran. ¡Hará que su formulario de registro de comercio electrónico sea mucho más fácil de completar en el móvil!

Además, no confíes ciegamente en todas las estadísticas y estudios que encuentres en Internet. ¿Recuerdas el estudio de 11 campos a 4? Bueno, otro estudio más reciente mostró que al reducir los campos de 9 a 6, las conversiones se redujeron en un 14%. Impactante, ¿no? ¿Por qué? Bueno, eliminaron los campos más atractivos. Para resumir, volvieron a 9 campos, pusieron el más importante en la parte superior y listo, las conversiones aumentaron un 19,21 %.

La conclusión es que, si bien estos estudios son interesantes, esos sitios web no son su sitio web. No confíes ciegamente en el primer estudio que encuentres en Internet.

¿Entonces que puedes hacer? Prueba. Prueba. ¡Y prueba!

• Realice algunas pruebas de usuario para ver el tiempo de finalización de su formulario móvil.
• Medir abandonos.
• Medir problemas con ciertos campos.
• Medir la frustración asociada a determinados campos. ¿Qué tan dispuestos están los usuarios a dar esa información? ¿Qué tan personal es esa información?

Optimización de interacciones táctiles

Cómo hacer que los controles sean táctiles

Si sus campos son demasiado pequeños o difíciles de alcanzar, los usuarios cometerán errores y necesitarán interacciones adicionales para lograr sus objetivos. ¿Recuerdas la ley de Fitt? También podría aplicarlo al diseño móvil: haga que sus etiquetas, campos y controles de formulario sean fáciles de tocar aumentando el tamaño del objetivo táctil . Para etiquetas en la web, un poco más de relleno puede aumentar el área táctil. A veces, también deberá agregar algunos márgenes entre los elementos para evitar toques perdidos.

Además, no olvide vincular las etiquetas con sus componentes mediante el emparejamiento for valores de ID. De esa manera, si el usuario pierde un toque en la etiqueta, el campo correspondiente seguirá teniendo el foco.

Steven Hoober realizó una investigación de usuarios sobre áreas táctiles. Encontrará un resumen en “Diseñar para el tacto”. Basándose en lo que descubrió, construyó una pequeña herramienta de regla de plástico: la plantilla táctil móvil. La herramienta podría ayudarlo a asegurarse de que sus áreas táctiles sean lo suficientemente grandes para los formularios móviles y, en general, para el diseño móvil.

Para obtener más información sobre el diseño táctil, puede leer lo siguiente:

• “Diseño amigable con los dedos: tamaños de destino ideales para pantallas táctiles móviles”
• “La Zona del Pulgar: Diseño para Usuarios Móviles”

Proveer retroalimentacion

Los usuarios de dispositivos móviles no tienen un mouse (no es broma), por lo que no obtienen la respuesta de "clic" que reciben los usuarios de escritorio cuando presionan un botón. Los usuarios de formularios móviles necesitan comentarios claros cuando interactúan con los elementos:

• Proporcione un estado de enfoque para el campo de formulario con el que interactúa el usuario.
• Proporcione retroalimentación visual cuando el usuario interactúe con un botón .

No soy un gran admirador del efecto dominó del diseño de materiales en los botones. Pero debo admitir que las animaciones en Android brindan una respuesta clara cuando el usuario interactúa con un botón.

Respetar el orden de los botones siguiente y anterior

Finalmente, respete los botones siguiente y anterior en los teclados móviles. Los usuarios pueden usarlos para navegar rápidamente por los campos. El orden de tabindex debe coincidir con el orden visual de los campos y componentes.

Evite los menús desplegables en dispositivos móviles si es posible

Los menús desplegables (el elemento de selección HTML) en la web requieren muchas pestañas e interacciones. Por lo tanto, como dijo Luke Wroblewski, deberían ser la interfaz de usuario de último recurso. Muchos otros componentes de la interfaz de usuario funcionan mejor que los menús desplegables en muchas situaciones.

Los controles de segmento y los botones de radio son buenas alternativas a los menús desplegables si tiene entre dos y cuatro opciones. ¿Por qué ocultar las opciones en un menú desplegable cuando puede mostrarlas todas directamente en una pantalla? Tenga en cuenta que, al igual que los botones de opción, los controles de segmento se excluyen mutuamente.

Una lista de países es un buen candidato para un componente. Un menú desplegable de más de cien países es una pesadilla de interacción en dispositivos móviles. Está bien si está buscando Afganistán (al principio de la lista) o Zimbabue (al final de la lista). Si está buscando Luxemburgo, terminará en un juego de desplazamiento para llegar a la mitad de la lista, yendo demasiado lejos hasta la letra M, tratando de volver a la L, y así sucesivamente.

Los menús desplegables largos se pueden reemplazar por campos de entrada de texto predictivo . Cuando el usuario comience a escribir L, la interfaz propondrá nueve países. Si agregan una U, ¡voilá! — Luxemburgo es. Cuatro interacciones en lugar de dos, frente a seis o siete interacciones de desplazamiento con el menú desplegable.

Si necesita que los usuarios elijan una fecha, olvídese de dividirla en un menú desplegable de día, mes y año como la gente está acostumbrada a hacer en los formularios en papel. Reemplace los menús desplegables de fechas múltiples con un selector de fechas . El type=date funciona en la mayoría de los casos. Pero es posible que tenga algunas necesidades especiales y termine creando su propio selector de fechas en JavaScript, especialmente si está en el negocio de reservas (hoteles, automóviles, vuelos).

En su artículo "Mobile DropDowns Revisited", Klaus Schaefers explica cómo el uso de un selector de fechas para las fechas de llegada y salida hizo que las interacciones fueran un 60 % más rápidas.

Sigamos con el negocio de las reservas. Supongamos que el usuario necesita agregar varios viajeros a su itinerario. Puede **reemplazar el menú desplegable* con un * paso a paso** para seleccionar el número de pasajeros. Un paso a paso es un control que permite al usuario aumentar y disminuir valores simplemente tocando los botones + y - . Eso tiende a ser más rápido cuando se deben agregar menos de seis personas. También es más intuitivo. A continuación se muestra un ejemplo de un paso a paso utilizado en la aplicación de Airbnb nativa de Android para seleccionar huéspedes y en el sitio web optimizado para dispositivos móviles de Kayak para agregar pasajeros.

Una última alternativa a los menús desplegables es la vista de lista. Las opciones se enumerarían en una subvista específica, como botones de radio , por ejemplo. Así es principalmente como funciona la configuración de Android.

Volverse inteligente con la finalización automática

Si desea disminuir el costo de interacción de su formulario, sea inteligente. No solicite información que pueda detectar automáticamente o adivinar en función de otra información que los usuarios le hayan proporcionado. Autocompletar y prellenar todo lo que puedas.

Lugares y Direcciones

Si el usuario busca un lugar o necesita ingresar una dirección, puede ofrecer autocompletado para ayudarlo. A medida que escriben, una API completará el resto de la dirección por ellos. Esto también reduce los errores.

Podrías usar:

• API de lugares de Google
• Algolia Places, que se basa en OpenStreetMap

En Francia y muchos otros países, puede adivinar la ciudad según el código de área. Entonces, si un usuario francés ingresa un código de área, podría autocompletar automáticamente o al menos proponer la ciudad. Mi país, Luxemburgo, es pequeño (no se burlen de mí). Mi código de área está vinculado a mi calle. Entonces, si ingreso mi código de área, el formulario debería incluso sugerir mi calle.

Tarjetas de crédito

Otra área donde la detección automática es fácil son las tarjetas de crédito. No es necesario preguntar al usuario qué tipo de tarjeta de crédito tiene. Puede detectar esto automáticamente en función de los números iniciales que ingresan. Incluso hay una biblioteca que puede hacer el trabajo por usted.

Uso de Autocompletar HTML5 (Autocompletar)

El atributo de autocompletar HTML puede rellenar campos en función de las entradas anteriores del usuario. Este atributo tiene un estado activado y desactivado. Algunas personas inteligentes han comenzado a trabajar en una especificación para hacer esto más poderoso y extender el atributo de autocompletar para los campos de formulario. El WHATWG también tiene una lista interesante.

Chrome y otros navegadores móviles ya admiten algunos de los valores extendidos para tarjetas de crédito y nombres. Esto significa que los usuarios pueden rellenar formularios con su nombre y datos de tarjetas de crédito que utilizan en otros sitios web.

En resumen, cuando deba elegir entre diferentes sistemas, cuente la cantidad de interacciones que cada uno requerirá.

Los errores ocurren: manejo de errores en formularios móviles

El último paso en nuestro viaje hacia mejores formularios móviles es el manejo de errores y equivocaciones. Podemos intentar reducir los errores para aliviar la carga cognitiva del usuario. También podemos ayudarlos a recuperarse de los errores, porque no importa cuán bueno sea el diseño de su formulario, los errores ocurren.

Evitar errores al llenar los formularios

“Más vale prevenir que curar”, solía decir mi madre. Eso también se aplica al diseño de formularios: la prevención de errores mejorará la experiencia de su formulario móvil.

Limitación de formato explícito

“Sé conservador en lo que haces. Sé liberal en lo que aceptas de los demás”. Este principio de robustez también se puede aplicar a los campos de formulario. Si es posible, permita que el usuario ingrese datos en cualquier formato.

Si cree que necesita limitar lo que un usuario puede ingresar en el campo, comience por preguntarse "por qué". En el campo de la experiencia de usuario, tenemos una técnica llamada “los tres porqués”. Si la respuesta es “porque bla, bla, base de datos”, tal vez sea hora de cambiar las cosas. Por ejemplo, ¿por qué rechaza caracteres especiales como e, a y o en el campo de nombre de usuario? Escribí un artículo explicando cuán groseros son los formularios para mí cuando intento ingresar "Stephanie" como nombre de usuario. Todavía estoy tratando de encontrar una buena razón para eso (aparte de las razones de la base de datos).

Si tiene una buena razón para solicitar un formato específico a los usuarios, indíquelo por adelantado . Puede usar marcadores de posición HTML5 para dar a los usuarios una pista sobre cómo deberían verse los datos, pero nuevamente, tenga cuidado con eso. También puede utilizar todas las técnicas de descripción de campos explicadas al principio de este artículo. Finalmente, las máscaras de entrada pueden guiar a los usuarios hacia el formato correcto.

Marcado de campos obligatorios (y opcionales)

No espere a que los usuarios envíen un formulario a medio completar para informarles sobre los campos obligatorios. Si un campo es obligatorio, los usuarios deben saberlo . Marcar los campos obligatorios con un asterisco ( * ) y una leyenda se ha convertido en un patrón estándar para los formularios. Lo bueno es que no ocupa mucho espacio. El problema es que no tiene valor semántico, por lo que puede causar problemas de accesibilidad si está mal codificado y si confía en los hábitos de las personas con la interacción de formularios.

En su lugar, podría marcar explícitamente los campos obligatorios y opcionales con las palabras "requerido" (u "obligatorio") y "opcional". Tanto el Instituto Baymard como Luke Wroblewski están de acuerdo en eso. Esto evita la ambigüedad con formularios largos en dispositivos móviles, como cuando se usa un desplazador, se procede con otra cosa, luego se regresa y no se recuerda si los campos obligatorios se marcaron con un asterisco o con otra cosa.

Eventualmente, la decisión sobre cómo marcar esos campos dependerá del diseño y la longitud del campo y del contexto. La mejor manera de saber si ha tomado la decisión correcta es, nuevamente, probar el formulario.

Valores predeterminados sensibles

Tenga cuidado con las opciones seleccionadas por defecto en los formularios . Cuando solicité mi trabajo anterior, había un formulario de información. El estado civil era opcional. Hicieron el primer elemento en el menú desplegable, "divorciado", el campo predeterminado. Por lo tanto, podía no responder (porque era un campo opcional) y dejar que el sistema creyera que estaba divorciado, o corregir esto y revelar mi estado civil real, incluso si no quería hacerlo.

Además, ten cuidado con el género. Nuevamente, tenga una opción para las personas que no quieren revelarlo; deja en claro por qué estás preguntando por su género; mejor aún, pregunte por los pronombres, o no pregunte si realmente no es necesario. If you are interested in this topic, I recommend “Designing Forms for Gender Diversity and Inclusion.” And if the gender is optional, again, don't auto-check the first choice, otherwise people won't be able to uncheck that radio button and choose not to answer.

Smart defaults, on the other hand, can help users avoid mistakes when filling a form. Unless you're in a Dr. Who episode, you're not supposed to book a hotel in the past. Booking.com understands that. When you open the date-picker on the website, the default date is set to the current date and you can't select a date in the past. When you select a return date, the default is the day after the departure date.

Less Painful Password Experience

I've written about password-less authentication, but you can't always use those techniques. Users will eventually have to create a password and enter it in a mobile form. And most of the time, that experience sucks. Here are a few ideas on how to make it better and help users avoid mistakes.

• When Creating An Account
  I won't get into the details of what kind of passwords you should require and how many characters they should be composed of — plenty of articles on that topic are on the web — just make up your mind about your password criteria. When users create an account, be proactive, not reactive. For the love of Cthulhu, don't let people guess. Tell users your password criteria up front .
  
  A lot of websites now show you a gauge for password strength telling you in real time what is missing . This is an interesting and excellent pattern. KLM uses it in its sign-in form:

  

  But there are still some big problems with this design.

1. They don't tell users their password criteria up front. Users who want to generate a password (using a password manager, for instance) must first guess that they need to first interact with the field in other to see the password criteria.
2. They limit the password's length to 12 characters, but they never tell users how many characters are left. Sure, let's add "counting the dots" to the cognitive load of building a password with so many criteria. After 12 characters, you can keep on typing on the keyboard, and nothing will happen.
3. What happens if, like me, you reached the 12-character limit but haven't met all of the criteria? Well, you would just have to delete the entire password and start over again.
4. Finally, you must enter the password twice. How is a user supposed to remember and retype the password that they just created based on those criteria while counting the dots?
5. Back to 1, generating a password with a password manager.

If KLM wanted to make this form better, it could provide a mask/unmask option for the password. Doing so, it would not need to ask for the same password twice. Users could visually check that the password they typed is the one they want.

• Al iniciar sesión
  En un formulario de inicio de sesión, una opción de enmascarar/desenmascarar contraseña mejoraría enormemente la experiencia del usuario.
  Amazon tiene un historial interesante de iteración de contraseñas en su formulario de inicio de sesión. Solía ​​tener una versión en la que no se podía ver la contraseña. La siguiente iteración permitió a los usuarios revelarlo. Luego, la contraseña se reveló de forma predeterminada y podía ocultarla. Así es como se ve en 2015:

  

  Amazon probó la última versión y el 60% de las personas sospechó. Por lo tanto, reemplazaron la casilla de verificación sin marcar "ocultar contraseña" con una casilla marcada "mostrar contraseña". Esto mostraría la contraseña en caracteres más pequeños, debajo del campo, mientras el usuario escribe. Así es como se ve al momento de escribir este artículo:

  

  Como puede ver, siempre hay margen de mejora.

Validación en línea

Si está familiarizado con los principios de usabilidad, es posible que conozca la ley de proximidad de la Gestalt. En dispositivos móviles, evite el resumen de errores en la parte superior de la página, sin información contextual, después de que el usuario haya tocado el botón Enviar.

En su lugar, los mensajes de error deben ubicarse cerca de los propios errores .

Validación en tiempo real

Tampoco necesita esperar hasta que los usuarios presionen el botón de enviar. Puede validar campos y mostrar comentarios mientras el usuario los completa .

Algunos consejos:

• Como se mencionó anteriormente, los campos de contraseña se beneficiarían de la validación en tiempo real y la retroalimentación de cada pulsación de tecla.
• También es posible que desee validar los nombres de usuario en tiempo real cuando se crean las cuentas, para asegurarse de que estén disponibles. Twitter hace un buen trabajo al respecto.
• No valide cada pulsación de tecla. Espere hasta que el usuario haya terminado de escribir. (Use el blur de JavaScript para formularios web, o simplemente espere unos segundos para detectar la inactividad).

Nota : *Mihael Konjevic ha escrito un buen artículo sobre "Validación en línea en formularios: diseño de la experiencia". Explica el concepto de “ recompensa temprana, castigo tardío ”.*

"Si el usuario está ingresando los datos en el campo que estaba en un estado válido , realice la validación después de la entrada de datos".

"Si el usuario está ingresando los datos en el campo que estaba en un estado no válido , realice la validación durante la entrada de datos".

El color importa

No digo que el color importe solo por mi actual color de cabello pelirrojo, rosa y morado. El color realmente importa en el diseño de formularios.

Hay algunas convenciones en la web que no quieres romper. Los usuarios que no son daltónicos saben que el rojo es para errores, el amarillo es para advertencias y el verde es casi siempre para confirmación o éxito. Lo mejor es quedarse con estos tres colores. Sin embargo, el rojo puede hacer que la gente se sienta ansiosa. El usuario podría pensar que ha cometido un error realmente grave. Usar naranja o amarillo para los mensajes de error podría causar menos pánico. El problema con el amarillo y el naranja es que es difícil encontrar tonos amigables para los daltónicos.

Hablando de daltonismo: el color no debe ser la única forma de transmitir un mensaje de error . Este es un criterio de accesibilidad.

En el siguiente ejemplo a la izquierda, el campo con un error está en naranja y el campo que se ha corregido se ha vuelto verde. Utilicé una herramienta de prueba para daltónicos para tomar la captura de pantalla en el medio: ya no se puede distinguir entre el borde gris predeterminado y el verde. Agregar algunos íconos en la última captura de pantalla asegura que los mensajes de error se transmitan a las personas daltónicas.

Recuperación de errores: escritura de mensajes de error fáciles de usar

En este momento, hemos hecho todo lo posible para ayudar a los usuarios a completar nuestros formularios y evitar errores. Pero a veces, a pesar de nuestro mejor esfuerzo, ocurren errores. Es hora de descubrir cómo ayudar a los usuarios a recuperarse de esos errores.

Primero, recuerde: no secuestre el control del sistema. Si un problema no es crítico, el usuario debería poder continuar interactuando con el resto de la interfaz tanto como sea posible. Evite los mensajes de error de alerta de JavaScript y los modales que bloquean a los usuarios siempre que sea posible. Además, si tu formulario necesita algún permiso, solicítalo en el flujo de uso. Si no se otorga el permiso, no lo considere un error porque no lo es. Tenga cuidado con la copia que utiliza aquí.

No eres un robot y tus usuarios tampoco

Los robots son geniales, lo sé. Pero no eres un robot, y tampoco lo son tus usuarios. Sin embargo, muchos mensajes de error todavía están mal escritos. Aquí hay algunos consejos cuando se trata de mensajes de error amigables para los humanos:

• Nunca muestre un mensaje de error sin formato, como “Se ha producido un error de tipo 2393. El servidor no pudo completar la operación.” En su lugar, explique lo que sucedió en lenguaje humano y por qué sucedió .
• Nunca muestre un mensaje de error sin salida, como "Se ha producido un error". En su lugar , sugiera formas de recuperarse del error . Escriba una copia procesable.
• Nunca muestre un mensaje de error vago, como "No se pudo encontrar un servidor con el nombre de host especificado", con un botón "Intentar de nuevo". En su lugar, haga que los mensajes de error sean informativos y coherentes . Por favor, no suenes como un robot.
• No asuma que las personas conocen el contexto de un mensaje. Sus usuarios no son expertos en tecnología. En su lugar, explíqueles en un lenguaje sencillo, sin jerga técnica, cómo recuperarse de este error .

Cuidado con el lenguaje que usas en los mensajes

Escribas lo que escribas, evita hacer que la gente se sienta estúpida por un error. Si es posible, omita las palabras negativas ; tienden a asustar a las personas y hacerlas aún más ansiosas. En su lugar, utilice un tono cortés, positivo y afirmativo.

No culpe a los usuarios por los errores ; culpar al sistema en su lugar. El sistema no guardará rencor, lo prometo. Dirija la atención del usuario hacia cómo el sistema no pudo procesar la acción y explíquele cómo encontrar una solución .

Un pequeño truco es leer tu propio mensaje en voz alta. Te ayudará a saber si funciona o si es demasiado duro o demasiado casual, etc.

También puede ser creativo con los mensajes de error e incorporar imágenes y humor para hacerlos menos amenazantes. Sin embargo, esto realmente dependerá de la identidad y el tono de su marca.

Para ayudarlo a escribir mejor el mensaje de error, le sugiero que lea lo siguiente:

• "Una lista de verificación de microcopia de 6 puntos para equipos de productos sin escritores de UX"
• “El arte del mensaje de error: escribir textos claros y útiles para cuando las cosas salen mal”

Hora de enviar el formulario

El usuario ha rellenado el formulario, no hay más errores y todo se ve bien. ¡Finalmente, es hora de enviar el formulario!

La primera regla es, no enmascare el botón de enviar . ¡Seriamente! Me pregunto a qué mente retorcida se le ocurrió esta idea, pero la he visto en algunas formas. El botón Enviar se mostraría solo una vez que todos los campos obligatorios se hayan completado sin ningún error. Es molesto para el usuario preguntarse si algo anda mal o si el botón del formulario no se ha cargado o si el sitio web está roto, etc.

Si no desea que los usuarios puedan presionar el botón de envío si faltan campos obligatorios o hay errores de validación, use el atributo HTML disabled en la entrada de submit . Deberá volver a habilitar el botón con JavaScript una vez que el formulario sea válido y esté listo para enviarse.

Si tiene un llamado a la acción principal y secundario, use el color, el tamaño y el estilo para mostrar la jerarquía .

Si se pregunta si el botón de confirmación debe aparecer antes o después del botón de cancelación, yo también (y muchas otras personas). Si está creando una aplicación nativa, siga las pautas del sistema operativo. Se ha vuelto particularmente divertido desde que Android cambió las posiciones de los botones en su cuarta versión. En la web es más complicado porque no hay pautas reales. Independientemente del sistema operativo, aquí hay algunas pautas generales para los botones de envío optimizados para dispositivos móviles:

• Dar la llamada a la acción con verbos descriptivos y procesables.
• Proporcione comentarios visuales cuando el usuario lo toca.
• Si tienes dos botones, haz que destaque la acción principal .
• A menos que esté trabajando en un formulario empresarial administrativo muy específico (en cuyo caso, tendrá muchos desafíos para optimizar para dispositivos móviles), evite un botón de reinicio . Los usuarios pueden confundirlo con el botón de enviar y perderán todos sus datos por accidente.

Conclusión

En esta primera parte, he discutido muchas pequeñas técnicas para llevar su formulario al siguiente nivel y ayudar a los usuarios a completarlo. Algunas de estas pautas generales y las mejores prácticas móviles pueden no funcionar el 100% del tiempo, ese es el problema. con las mejores prácticas. Por lo tanto, siempre pruebe sus formularios en usuarios reales y dispositivos reales, y adapte las pautas a las necesidades y experiencia específicas de sus usuarios.

Además, realice algunas regresiones y pruebas funcionales automatizadas, de nuevo, en dispositivos reales. El emulador móvil de Chrome no será suficiente para probar formularios táctiles optimizados. Digo esto porque había lanzado un sitio web de comercio electrónico con un formulario de búsqueda que no funcionaba en dispositivos móviles. Solo hicimos pruebas automatizadas usando un emulador. Esto es lo que sucedió. El formulario de búsqueda estaba oculto bajo un icono de búsqueda. Puede tocar el botón, que abrió un cuadro con el campo de búsqueda. Funcionó emulando el movimiento del mouse como un evento táctil. Probamos tocando el botón y abrió la caja. Nadie intentó iniciar una búsqueda. Entonces, nadie (ni siquiera el cliente) vio que el campo de búsqueda desaparecía tan pronto como los usuarios intentaban interactuar con él. ¿Qué sucedió? Cuando el elemento de entrada recibió el foco, el botón perdió el estado de desplazamiento, por lo que cerró el cuadro con el campo. Las pruebas automatizadas no pudieron detectar esto porque la entrada no perdía el foco. Entonces, lanzamos un sitio web de comercio electrónico sin funcionalidad de búsqueda en dispositivos móviles. No es una súper experiencia.

En la segunda parte de esta serie, veremos técnicas más avanzadas específicas para dispositivos móviles. Veremos cómo usar funciones geniales de HTML5 para formatear campos y cómo usar capacidades móviles para llevar la experiencia del usuario móvil al siguiente nivel.