Nuestra aplicación web tiene tres operaciones diferentes que proceden de la siguiente manera:
Aquí es donde nuestras tres operaciones no están alineadas. En un caso, la opción es Continuar/Cancelar, en otro es Listo/Cancelar y finalmente tenemos Finalizar/Cancelar.
¿Cuál de estos es el mejor? ¿Hay una mejor alternativa? Si es así, ¿hay argumentos de apoyo?
Por lo general, trato de mantenerme alejado de las etiquetas de botones genéricas como estas y ser lo más específico posible. Sus etiquetas me parecen muy "base de datos" y me recuerdan las herramientas diseñadas por programadores para dominios muy abstractos (como ... editores de bases de datos).
Consulte esta pregunta relacionada sobre el posicionamiento del botón Aceptar/cancelar para más discusión:
¿Aceptar/Cancelar a la izquierda/derecha?
En mi respuesta allí, me vinculé a la investigación de Jakob Nielsen sobre los botones OK/cancelar , donde señala que:
A menudo es mejor nombrar un botón para explicar lo que hace que usar una etiqueta genérica (como "OK"). Una etiqueta explícita sirve como "ayuda justo a tiempo", dando a los usuarios más confianza para seleccionar la acción correcta.
Por ejemplo, algunos ejemplos:
Además, podría considerar omitiendo la alternativa . En algunos casos, esto puede tener sentido. Creo que es bueno incluir una opción de "cancelar" si el usuario está a punto de hacer un compromiso significativo, como comprar algo o una operación CRUD que involucra una gran cantidad de datos.
Pero para algo simple, como tuitear, especialmente cuando hay una reversión fácil disponible después de la operación de confirmación, debería estar bien omitir el botón explícito "cancelar", ya que generalmente es obvio que no continuar no confirmará nada.
Un gran ejemplo es el formulario de comentarios de StackExchange, que solo tiene un botón "Agregar comentario" y no hay forma de ocultar el formulario o cancelarlo. ¿No quieres agregar un comentario? ¡No hagas clic en "Agregar comentario"!
Suena como un asistente. Aquí hay un ejemplo:
Next >
y Cancel
botones.Next >
.Finish
y Cancel
.Finish
, se completa la operación; Cancel
cancela todo.Otro enfoque es hacerlo un proceso de un solo paso, pero permitir deshacer. Esto puede o no ser posible, dependiendo de la operación.
Merge
y Cancel
.Merge
.Undo
. Si el usuario hace clic en Undo
, la operación se revierte.Dos puntos que me gustaría hacer:
1) Si el proceso de fusión real se inicia después de la segunda pantalla (con resúmenes), entonces el botón "Fusionar" debería estar en esa segunda pantalla. Lo que me lleva a decir que en el primero, el botón debería decir algo como "Vista previa de resultados de fusión" o similar porque este es el siguiente resultado que obtendrá el usuario, en el flujo de proceso que comenzó.
2) Esta es una especie de sugerencia espeluznante, pero quizás tenga sentido tener tres botones en la primera pantalla: "Vista previa de combinación", "Cancelar" y "Combinar sin vista previa". Esto ahorraría algo de tiempo para el usuario que sabe lo que está a punto de hacer y no quiere esperar las estadísticas y luego comprometerse con su decisión. Solo una idea...
Si en realidad no está realizando la "combinación" después de hacer clic en Combinar, no debería llamarla Combinar.
A menudo, lo que se usa en forma de etapas múltiples es una convención Continuar/Enviar. Continuar implica que debe continuar a la siguiente etapa, pero eso no implica que se haya comprometido todavía.
En el caso de una tienda en línea, el proceso de pago a menudo requiere que el usuario proceda a través de algunos formularios, proporcionando dirección y detalles de pago. No hasta que la página donde finalmente puedan confirmar el pedido sea un botón "Realizar pedido" o "Comprometerse a comprar".
Usaría un botón "Vista previa de combinación" o "Continuar" y luego en la página donde se comprometen, use un botón "Realizar combinación" o "Enviar".