it-swarm-es.com

¿Deben los botones desactivados dar retroalimentación cuando se hace clic?

Me preguntaba si podría ayudarme con un problema de UX que estoy enfrentando con "botones deshabilitados en dispositivos móviles"

Tenemos algunos campos de entrada diferentes como parte de un proceso de incorporación móvil. Estos formularios tienen bastantes campos y actualmente deshabilitamos el botón siguiente hasta que esos campos estén completos. Pero, si el usuario toca el botón deshabilitado, mostrará un mensaje de error en línea en los campos de entrada no completados.

Hemos estado debatiendo si es una mejor experiencia para el usuario mostrar comentarios cuando el usuario toca el botón deshabilitado para mostrar que falta algo o si los botones deshabilitados generalmente nunca deberían tener ninguna reacción, ya que están deshabilitados.

28

Al final, ambas formas conducen al mismo resultado. Ya sea que se trate de un error en línea o tal vez una burbuja con comentarios, el usuario sabe por qué no puede continuar (que se adhiere a visibilidad del estado del sistema ).

El punto sobre los elementos deshabilitados que nunca tienen una acción es comprensible, pero aferrarse estrictamente a esta regla no es realmente útil para el usuario. Si pudiera tener una mejor experiencia de usuario con su producto por el pequeño precio de no cumplir con una regla al 100%, diría que vale la pena. De todos modos, no lo estás rompiendo por completo, solo te estás desviando un poco.

Dicho esto, personalmente creo que dar esta retroalimentación de esta manera podría considerarse más moderno o "más genial" . Entonces, especialmente si te diriges a un público más joven, diría que sería una mejora.

Un inconveniente aquí puede ser que algunos usuarios, que están muy acostumbrados a las "viejas formas", podrían encontrar esto inesperado y, por lo tanto, molesto. Pero eso parece una pequeña posibilidad.

También otra cosa a considerar: Usuarios con discapacidad visual . Sus lectores de pantalla pueden captar mensajes de error en línea muy bien (hasta donde yo sé), pero un globo de diálogo puede ser complicado. Por lo menos, simplemente debería tomar el enfoque del sistema al aparecer.


Algo así parece ser una buena forma de hacerlo:
A disabled button showing a speech bubble with reasons on why it is disabled
Fuente

Puede mostrarlo al hacer clic en el botón o tener un botón más pequeño (?) Colocado encima, que a su vez no rompe el regla de botón deshabilitado más.

23
Big_Chair

Si esto no fuera móvil , diría que sería mejor que se muestre un mensaje junto al botón deshabilitado que dice

Complete los campos obligatorios restantes (marcados con *)

o algo por el estilo (se requiere forjar palabras).

Pero para dispositivos móviles , donde no tiene esa propiedad, tener el botón activo (no deshabilitado) y que le diga al usuario qué campos aún necesita completar cuando se hace clic parece razonable. No deshabilitaría el botón pero seguiría respondiendo a los clics, pero tal vez podría decir (No se puede enviar todavía) vs (cuando se completan todos los campos obligatorios) Enviar .

No olvides la accesibilidad. Hay varias cosas que puedes hacer allí. Una de ellas es que puede hacer que la "pista" que el usuario con discapacidad visual escuche para el botón sea diferente y más larga de lo que se muestra visualmente, si el usuario está utilizando los lectores de pantalla populares para dispositivos móviles (VoiceOver para iOS, TalkBack para Android ) Detalles aquí y aquí . Por ejemplo, el mensaje podría decir "Complete los campos de nombre, apellido y correo electrónico". Asegúrese de probar con lectores de pantalla.

10
T.J. Crowder

Así es como lo hace el proceso de registro de Google. Debería ser muy similar a su proceso. Tenga en cuenta que el botón primario siempre está habilitado, ¡solo cambia su función!

  1. Se le presenta una forma bastante autoexplicativa.

empty form

  1. El botón Siguiente tiene el color primario y se puede hacer clic en él. Tenga en cuenta que el botón secundario lo lleva a un proceso completamente diferente (iniciar sesión en este caso).

Active next button

  1. Después de enviar el formulario no válido a través del botón Siguiente , se desplaza al primer formulario no válido y se validan todos los controles (incluso cuando no están sucios). controles de camino al botón Siguiente .

Invalid controls

La única diferencia para usted es que parece tener campos opcionales. Puede marcarlos con (opcional) o reunirlos en una forma completamente opcional que, además de un Siguiente , tiene un Saltar (Esto se usa muy a menudo para números de teléfono).

Si su formulario crece demasiado, piense si todos los datos requeridos son realmente necesarios al registrarse. Si el usuario mismo activa acciones que requieren más datos, como una compra en línea tienda: es mejor solo entonces requerir un método de pago y una dirección.

7
knallfrosch

Siguiendo el concepto de "decisiones informadas", siempre es mejor proporcionar a los usuarios suficientes instrucciones para que no cometan errores en lugar de dejar que descubran que lo que hicieron estuvo mal. Si los campos del formulario requieren marcado con un asterisco * o de alguna otra manera junto con las otras intenciones de diseño, el formulario se completará correctamente y no debería ser necesario desactivar el botón de envío. Recomiendo no usar botones deshabilitados a menos que sea realmente necesario.

4
Ren

Para mí, parece que en realidad no ha deshabilitado el botón "siguiente", simplemente alteró su comportamiento. Entonces en lugar de

enabled (action a) ↔︎ disabled (no action)

ahora tienes

enabled (action a) ↔︎ enabled (action b)

Eso en sí mismo no es necesariamente un problema a menos que lo represente como realmente desactivado. Si lo hace, sus usuarios esperarán que otros botones "deshabilitados" tengan comportamiento. Cuando encuentran un botón realmente deshabilitado (es decir, sin comportamiento), pueden tener la impresión de que el botón está roto, ya que la expectativa es que los botones "deshabilitados" darán retroalimentación (o al menos tendrán alguna acción).

Esta es, según tengo entendido, su solución actual:

current solution

El usuario no obtiene ninguna indicación de cuál de los dos últimos botones reaccionará a la interacción.

Considere en cambio una distinción visual entre "habilitado", "deshabilitado pero no realmente" y "deshabilitado de verdad", por ejemplo:

proposed solution

De esta manera tiene una distinción entre el estado ordinario, el estado de retroalimentación y el estado realmente deshabilitado.

2
Zano

Creo que la forma en que lo has descrito tiene sentido. Incluiría un asterisco en todos los campos obligatorios, aunque todos son obligatorios. Incluso podría tener una nota en la parte superior indicando que todos los campos son obligatorios. Cualquier cosa para ayudar al usuario a comprender qué hacer en un formulario complejo es lo mejor.

0
David Saunders

Como en el espacio de pantalla vertical móvil es (casi) ilimitado, simplemente agregaría un mensaje visible permanente justo encima del botón deshabilitado.

Debe completar el nombre, número de teléfono móvil y aceptar nuestros T&C antes de poder continuar.

Dado que el mensaje solo aparecerá si alguien se desplaza hacia abajo hasta el botón Siguiente, solo será visible para los usuarios que busquen el botón sin haber completado todos los campos necesarios. Y puede dejar la política desactivada = sin reacción intacta.

0
Falco

Al observar cómo los usuarios usan mi aplicación, he visto que una parte importante de los usuarios sigue presionando los botones deshabilitados, especialmente aquellos que tienen menos conocimientos técnicos. Esto sucedió incluso cuando el botón deshabilitado estaba claramente atenuado.

Mi solución generalmente es activar una respuesta de validación si se presiona un botón deshabilitado. Al observar el comportamiento antes y después de implementar dicho mensaje de validación, esto tuvo el efecto deseado.

La otra solución es no deshabilitar el botón de acción y hacer que se muestre un mensaje de validación como lo haría normalmente ( ejemplo en stackexchange).

0
Tom

Primero haría algunas pruebas de usabilidad para ver si algo de esto importa. No puede garantizar una excelente experiencia de usuario sin incluir al usuario, ¿verdad? Haga algunas pruebas de usabilidad para ver si los usuarios se confunden sobre por qué el botón está deshabilitado. Sus usuarios particulares pueden entender por qué está deshabilitado y esto podría no ser un problema. Agregar burbujas de ayuda u otras cosas es solo agregar complejidad a su interfaz que no sabe que necesita.

Si sus usuarios hacen clic constantemente en el botón deshabilitado, entonces debe determinar por qué. ¿Están haciendo clic porque no parece deshabilitado? Tal vez es un problema de accesibilidad visual? ¿Están haciendo clic porque se saltan accidentalmente uno de los campos obligatorios? Esto sucedió una vez donde el usuario tuvo que marcar la casilla para aceptar los términos y con el resto del contenido en la pantalla, no lo vieron. Luego, cuando llegaron al final del formulario, no entendieron por qué el botón estaba desactivado.

0
John