Patrones de diseño frustrantes que deben corregirse: Selector de cumpleaños

Los has visto antes. Patrones de diseño confusos y frustrantes que parecen estar persiguiéndote donde quiera que vayas, de un sitio web a otro. Tal vez sea un botón de envío deshabilitado que nunca comunica lo que realmente está mal, o información sobre herramientas que, una vez abierta, cubre el campo de entrada justo cuando necesita corregir un error. Están en todas partes y son molestos , a menudo tirándonos de un callejón sin salida a otro, en algo que parece una ratonera bien orquestada y mal diseñada.

Estos patrones no son maliciosos ni malvados. No tienen mucho en común con mensajes de cookies engañosos o CAPTCHA misteriosos disfrazados de bocas de incendios y pasos de peatones. No están diseñados con malas intenciones ni con malas intenciones: nadie se levanta por la mañana con la esperanza de aumentar las tasas de rebote o disminuir la conversión.

Es solo que a lo largo de los años, algunas decisiones de diseño más o menos aleatorias han sido ampliamente aceptadas y adoptadas y, por lo tanto, se repiten una y otra vez, a menudo sin ser cuestionadas o validadas por datos o pruebas de usabilidad. Se han convertido en patrones de diseño establecidos . Y a menudo bastante pobres . Apareciendo una y otra vez entre las quejas de los usuarios durante las pruebas.

En esta nueva serie de artículos, echemos un vistazo más de cerca a algunos de estos patrones de diseño frustrantes y exploremos mejores alternativas , junto con muchos ejemplos y preguntas para tener en cuenta al construir o diseñar uno. Estos conocimientos provienen de investigaciones de usuarios y pruebas de usabilidad realizadas por su servidor y colegas de la comunidad y, por supuesto, se hará referencia a todos ellos en cada una de las próximas publicaciones.

Comenzaremos con un patrón humilde y aparentemente inofensivo que todos hemos experimentado en algún momento: el infame selector de cumpleaños que con demasiada frecuencia resulta ser inaccesible, lento y engorroso de usar. Ya hemos escrito con mucho detalle sobre los selectores de fecha y hora perfectos, pero los selectores de cumpleaños merecen una conversación aparte.

Experiencia de usuario frustrante: Desplegable de cumpleaños/Widgets a partir de 2021

Cada vez que solicite una solicitud de empleo, abra una cuenta bancaria o reserve un vuelo, probablemente tendrá que ingresar su fecha de nacimiento . Obviamente, la entrada es una fecha , por lo que no debería ser muy sorprendente ver interfaces que usan un widget tipo selector de fecha-calendario bien adoptado (nativo o personalizado), o un menú desplegable para solicitar esa entrada específica .

Probablemente podamos detectar las razones por las que estas opciones suelen preferirse. Desde el punto de vista técnico, queremos asegurarnos de que la entrada sea correcta y detectar errores temprano . Nuestra validación debe ser lo suficientemente resistente como para validar la entrada, proporcionar un mensaje de error claro y explicar qué debe hacer exactamente el cliente para solucionarlo. Simplemente no tenemos todos estos problemas con un menú desplegable o un widget de calendario. Además, podemos evitar fácilmente cualquier configuración regional o diferencias de formato proporcionando solo las opciones que se ajusten a la factura.

Puede parecer que la mejor manera de evitar que ocurran errores es diseñar una interfaz de usuario de manera que los errores sean difíciles de cometer. Eso podría significar ser estricto y explícito en el diseño de formularios, básicamente permitiendo solo entradas bien formadas. Después de todo, proporcionar una entrada mal formada es imposible si todas las opciones disponibles están bien formadas. Pero aunque la entrada de hecho estará bien formada, no tiene que ser precisa, especialmente si proporcionar esa entrada es agotador y frustrante.

En la práctica, también cometemos errores similares con requisitos de contraseña demasiado complicados y rigurosos. No es raro ver a personas tan molestas por estos requisitos que colocan las contraseñas en una nota adhesiva en su pantalla o las ocultan en un archivo personal.txt en su escritorio, solo para poder volver a escribirlas si es necesario. Las contraseñas Wi-Fi corporativas y un SuperPIN complejo para la banca en línea son buenos ejemplos de eso en acción.

Resulta que las personas son muy creativas para torcer las reglas a su favor, por lo que cuando un sistema no se puede usar, no es seguro; y cuando una entrada de formulario no se puede utilizar, los datos que recibimos serán menos precisos y darán lugar a más errores. En última instancia, por supuesto, daría lugar a situaciones en las que los usuarios quedan bloqueados y se ven obligados a abandonar la interfaz de usuario ya que no pueden hacer ningún progreso.

Hay una otra cara de esa moneda también. Por supuesto, podríamos eliminar toda la complejidad y proporcionar siempre un solo campo de entrada, lo que permite a los usuarios escribir lo que prefieran. En la práctica, eso significa que realmente escribirán lo que prefieran, a menudo de una manera poco estructurada e ineficiente.

En el caso de una entrada de cumpleaños, en las pruebas de usabilidad, los clientes escriben cualquier cosa entre julio y julio y del 06 al 6 , a menudo con delimitaciones aleatorias y algunos errores tipográficos en el camino, y con un orden mixto de días, meses y años. Validar esa entrada después del envío no sirve bien a los usuarios porque no saben qué formato de entrada funcionaría. Obviamente tampoco satisface nuestras necesidades.

Con nuestro diseño, debemos proporcionar una guía respetuosa y directa , junto con una implementación técnica accesible. Esto nos lleva a algunas desventajas comunes de los menús desplegables y los selectores de fechas nativos.

Las trampas de los selectores de fechas nativos y los menús desplegables

Desafortunadamente, los selectores de fechas nativos , solicitados por <input type="date"> , vienen con muchas pesadillas de accesibilidad. En el momento de escribir, cuando se usan de forma inmediata, no son una opción muy accesible para prácticamente cualquier tipo de entrada de fecha. No solo hay muchos problemas con el lector de pantalla, sino también problemas de enfoque y diseño, mensajes de error confusos y genéricos.

He visto una buena cantidad de implementaciones que deshabilitan la entrada del teclado por completo (ver arriba), lo que requiere que los clientes usen exclusivamente el widget de calendario del selector de fecha nativo. Y esto es dolorosamente, dolorosamente lento. Sin un respaldo de entrada de teclado, los usuarios tienen que embarcarse en un largo viaje entre días, meses y años, tomando docenas y docenas de toques o clics .

Si bien conocemos la fecha de inmediato, la interfaz nos indica que naveguemos entre fechas y luego encontremos nuestra fecha en el resumen mensual una vez que lleguemos allí. Esa es la razón por la que estas experiencias son frustrantes.

En ese sentido, los menús desplegables son mucho más rápidos y fáciles de navegar. Se puede acceder a ellos de forma predeterminada y, además, en lugar de navegar entre meses y años, es suficiente ubicar los números correctos en 3 listas: días, meses y años. Pero los menús desplegables siguen siendo lentos. Tienen problemas de zoom. Pellizcar las opciones desplazables es agotador. Ocupan mucho espacio. La lista de años es larga. Y al especificar la entrada, debemos tocar el control, luego desplazarnos (generalmente más de una vez), buscar y seleccionar el objetivo y continuar con el siguiente menú desplegable. Tampoco es estimulante.

Por lo tanto, no es raro ver menús desplegables considerados la interfaz de usuario de último recurso y, por lo general, reemplazados por botones (por ejemplo, para filtros), interruptores, controles segmentados o cuadros de autocompletar que combinan la flexibilidad de un cuadro de texto con la seguridad de un <select> - caja. Los menús desplegables no son malos per se; es solo que los usuarios pasan mucho más tiempo del necesario completando los datos en ellos.

Y luego hay una pregunta sobre los valores predeterminados . Mientras que con los menús desplegables a menudo no usamos ninguna entrada de forma predeterminada ( mm/dd/yyyy ), con un selector de fecha necesitamos proporcionar algún punto de partida para la vista del calendario. En el último caso, irónicamente, la fecha de "inicio" suele ser alrededor de la fecha en que se completa el formulario, por ejemplo, el 15 de mayo de 2021 . Por supuesto, esto no parece óptimo, pero ¿cuál debería ser la fecha correcta ? Tenemos que empezar en alguna parte, ¿verdad?

Bueno, realmente no hay una fecha correcta sin embargo. Podríamos empezar temprano o tarde, hace 3 meses o mañana, pero en el caso de un recolector de cumpleaños, todas estas opciones son puras conjeturas. Y como tales, son un tanto frustrantes: sin ningún aporte, es posible que los clientes deban desplazarse desde 1901 hasta finales de la década de 1980, y con un conjunto de aportes, deberán corregirlo, a menudo saltando décadas de un lado a otro. Esa interacción requerirá una precisión impecable en el desplazamiento.

No importa la elección que hagamos, estaremos equivocados casi todo el tiempo . Es probable que esto sea diferente para un sitio web de reserva de hotel, o un servicio de entrega de alimentos, y muchos otros casos de uso, pero no para la entrada de cumpleaños. Esto nos lleva a la conversación sobre cómo evaluar objetivamente qué tan bien diseñada está la entrada de un formulario.

Evaluación de la calidad del diseño de formularios

El diseño puede verse como un asunto muy subjetivo. Después de todo, todo el mundo parece tener su propia opinión y preferencias sobre el enfoque correcto para un problema determinado. Pero a diferencia de cualquier tipo de autoexpresión o arte, se supone que el diseño resuelve un problema. La pregunta, entonces, es qué tan bien un diseño en particular resuelve un problema en particular. Cuanto más inequívoca sea la interpretación de la intención del diseñador, menos errores cometerán los clientes, menos interrupciones, mejor será el diseño. Estos atributos son medibles y objetivos .

En mi propia experiencia, los formularios son el aspecto más difícil de la experiencia del usuario. Hay muchas facetas difíciles , desde la microcopia y el diseño de formularios hasta la validación en línea y los mensajes de error. Obtener formularios correctos a menudo requiere que aparezcan errores de back-end y errores de terceros correctamente en el front-end y simplificar una estructura subyacente compleja en un conjunto de campos de formulario predecibles y razonables. Esto puede convertirse fácilmente en una pesadilla frustrante en aplicaciones heredadas complejas e integraciones de terceros.

Entonces, cuando se trata de diseño de formularios , en nuestros proyectos, siempre tratamos de medir la calidad de una solución particular en función de los siguientes 9 atributos:

• Modelo mental
  ¿Qué tan bien encaja nuestro diseño de formulario en el modelo mental del cliente? Cuando solicitamos datos personales, debemos preguntar exactamente el mínimo de lo que se requiere para ayudar a nuestros clientes a comenzar. No deberíamos pedir ningún dato confidencial o personal (género, cumpleaños, número de teléfono) a menos que tengamos una buena razón para ello y lo expliquemos en la interfaz de usuario.
• Complejidad
  ¿Cuántos elementos de entrada mostramos por página, en dispositivos móviles y de escritorio? Si un formulario contiene entre 70 y 80 campos de entrada, en lugar de mostrarlos todos en una página o usar un diseño de varias columnas, podría ser una buena idea usar un patrón de lista de tareas para dividir la complejidad en partes más pequeñas y manejables.
• Velocidad de entrada
  ¿Cuánto tiempo y esfuerzo necesita el cliente para completar los datos correctamente? Para una entrada dada, cuántos toques/pulsaciones de teclas/operaciones se requieren para completar el formulario con una información dada con precisión, suponiendo que no se cometan errores en el camino.
• Accesibilidad
  Cuando hablamos de la velocidad de entrada, debemos asegurarnos de admitir varios modos de interacción, principalmente usuarios de lectores de pantalla y usuarios de teclado. Esto significa etiquetas correctamente configuradas, botones grandes, etiquetas colocadas sobre el campo de entrada y errores comunicados correctamente, entre muchas otras cosas.
• Escalabilidad
  Si alguna vez necesitáramos traducir la interfaz de usuario a otro idioma o adaptarla a otro factor de forma, ¿qué tan sencillo sería y cuántos problemas causaría? (Un ejemplo típico de una solución problemática es un patrón de etiqueta flotante, y hablaremos de ello en una publicación separada).
• Gravedad de las interrupciones
  ¿Con qué frecuencia interrumpimos a los clientes, ya sea cargando controles giratorios, validación en línea temprana o tardía, congelando partes de la interfaz de usuario para ajustar la interfaz en función de la interfaz de usuario proporcionada (por ejemplo, una vez que se selecciona un país), la frecuencia de datos precargados incorrectamente, o datos autocorregidos incorrectamente?
• Tasa de éxito del formulario
  ¿Cuántos clientes completan con éxito un formulario sin un solo error? Si un formulario está bien diseñado, la gran mayoría de los clientes nunca deberían ver ningún error. Por ejemplo, esto requiere que toquemos el autocompletar del navegador, el orden de tabulación es lógico y hacer ediciones es convencional y obvio.
• Velocidad de recuperación
  ¿Qué tan alta es la proporción de clientes que logran descubrir el error, corregirlo y pasar al siguiente paso del formulario? Necesitamos realizar un seguimiento de la frecuencia con la que aparecen los mensajes de error y qué mensajes de error son los más comunes. Esa es también la razón por la que a menudo es una buena idea pasar por el servicio de atención al cliente y consultar con ellos primero de qué se quejan los clientes a menudo.
• Tasa de fallo de formulario
  ¿Cuántos clientes abandonan el formulario? Esto suele ocurrir no solo por la complejidad del formulario, sino también porque los clientes no pueden encontrar una manera de corregir un error debido a validadores agresivos o botones de "enviar" desactivados. También sucede porque el formulario solicita demasiada información confidencial y personal sin una buena razón.

Para comprender qué tan bien funciona un formulario, realizamos estudios de usabilidad con clientes que acceden a la interfaz en su propia máquina, ya sea un dispositivo móvil, tableta, computadora portátil o computadora de escritorio, en su propio sistema operativo, en su propio navegador. Pedimos grabar la pantalla, si es posible, y usar un protocolo de pensamiento en voz alta, para seguir dónde, cómo y por qué ocurren los errores. También estudiamos qué tan rápido se mueve el cliente de un campo de formulario a otro, cuándo se detiene y piensa, y cuándo ocurre la mayoría de los errores.

Obviamente, la gran cantidad de toques o clics no siempre sugiere que la entrada haya sido sencilla o engorrosa. Pero es más probable que algunos modos de entrada generen errores o causen confusión, y otros pueden ser valores atípicos , lo que requiere mucho más tiempo en comparación con otras opciones. Eso es lo que estamos buscando en las pruebas.

Ahora, veamos cómo podemos aplicarlo al problema de entrada de cumpleaños.

Diseñando una mejor entrada de cumpleaños

Si alguien te pregunta cuál es tu cumpleaños, probablemente tengas en mente una serie particular de dígitos. Puede estar ordenado en dd/mm/yyyy o mm/dd/yyyy , pero será una cadena de 8 dígitos que llevas repitiendo en todo tipo de documentos desde muy joven.

Podemos aprovechar este modelo simple de lo que es una entrada de cumpleaños con un campo simple de entrada única que combinaría las tres entradas: día, mes y año. Eso significaría que el usuario simplemente escribiría una cadena de 8 números, permaneciendo en el teclado todo el tiempo.

Sin embargo, este enfoque plantea algunos problemas:

• necesitamos admitir el formato automático y el enmascaramiento,
• necesitamos explicar la posición de la entrada de día/mes,
• necesitamos admitir el comportamiento del botón Backspace en la entrada,
• necesitamos rastrear y ocultar/mostrar/mostrar permanentemente el enmascaramiento,
• necesitamos admitir saltos en un valor específico (por ejemplo, mes),
• necesitamos minimizar los clics de ira y la navegación dentro de la entrada para cambiar un valor específico en los dispositivos móviles,
• Si no se usa la creación automática, debemos crear un conjunto de reglas de limpieza y validación para admitir cualquier tipo de delimitadores.

En su libro sobre patrones de diseño de formularios, Adam Silver argumenta que usar varias entradas en lugar de una entrada rara vez es una buena idea, pero es una buena opción para las fechas . Podemos comunicar claramente lo que representa cada entrada y podemos resaltar la entrada específica con estilos de enfoque. Además, la validación es mucho más fácil y podemos comunicar fácilmente qué parte específica de la entrada parece no ser válida y cómo solucionarlo.

Podríamos hacer la transición automática del usuario de una entrada a la siguiente cuando finalice la entrada, o permitir que los usuarios se muevan entre los campos por su cuenta. A primera vista, lo primero parece mejor ya que la entrada requeriría solo 8 dígitos, escritos uno tras otro. Sin embargo, cuando las personas corrigen errores, a menudo necesitan búferes de entrada : espacio dentro del campo de entrada para corregir la entrada existente.

Por ejemplo, es común ver personas escribiendo 01, dándose cuenta de que cometieron un error, luego cambiando la entrada a 010 y luego eliminando el primer 0, solo para terminar con una cadena invertida (y correcta): 10. Al evitar una transición automática de un campo al siguiente, podríamos causar menos problemas y hacer que la interfaz de usuario sea un poco más predecible y fácil de manejar.

Para explicar la entrada, necesitaríamos proporcionar etiquetas para el día, el mes y el año, y tal vez también mostrar un ejemplo de la entrada correcta. Las etiquetas no deberían ser etiquetas flotantes, pero podrían vivir cómodamente sobre el campo de entrada, junto con cualquier sugerencia o ejemplo que queramos mostrar. Además, cada entrada también podría resaltarse en el foco.

A lo largo de los años, no pude detectar un solo problema con esta solución a lo largo de los años de prueba, y no es de extrañar que el patrón se utilice también en Gov.uk.

Cuando necesita un selector de fecha después de todo

Si bien la solución anterior probablemente sea más que suficiente para una entrada de cumpleaños, es posible que no sea lo suficientemente buena para situaciones más generales. Es posible que necesitemos una entrada de fecha que sea menos literal que un día de cumpleaños, donde los clientes tendrán que elegir un día en lugar de proporcionarlo (por ejemplo, " primer sábado de julio" ). Para este caso, podríamos mejorar los tres campos de entrada con un widget de calendario que los usuarios también podrían usar. Una entrada predeterminada dependería de la fecha actual o de una fecha futura que la mayoría de los clientes tienden a elegir.

Adam proporciona un ejemplo de código simple para el patrón de fecha memorable en su sistema de diseño NoStyle. Resuelve mucho trabajo de desarrollo y evita muchos problemas de accesibilidad, y todo eso al evitar tocar los widgets del calendario o desplazarse innecesariamente por las ruedas desplegables.

Terminando

Por supuesto, un buen control de formulario depende del tipo de entrada de fecha que esperamos. Para los planificadores de viajes, donde esperamos que los clientes seleccionen una fecha de llegada, puede ser útil una entrada flexible con una búsqueda de calendario.

Sin embargo, cuando les preguntamos a nuestros clientes sobre su fecha de nacimiento , les pedimos una fecha muy específica, una cadena muy específica, que se refiere a un día, mes y año exactos. En ese caso, un menú desplegable es innecesario. Tampoco lo es una búsqueda de calendario, por defecto a un valor más o menos aleatorio. Si necesita uno, evite los selectores de fechas nativos y los menús desplegables nativos si es posible y use una solución personalizada accesible en su lugar. Y confíe en tres campos de entrada simples, con etiquetas y explicaciones colocadas sobre el campo de entrada.

También hemos publicado una extensa obra sobre el diseño de un selector de fecha y hora perfecto, junto con listas de verificación que quizás desee usar para diseñar o crear uno.

Artículos relacionados

Si encuentra útil este artículo, aquí hay una descripción general de artículos similares que hemos publicado a lo largo de los años, y algunos más están por venir.

• Configurador receptivo perfecto
• Comparación perfecta de características
• Control deslizante perfecto
• acordeón perfecto
• Libro de patrones de diseño de formularios de Adam Silver, publicado en SmashingMag
• Suscríbete a nuestro boletín electrónico para no perderte los próximos.