¿Cuáles son algunas alternativas a la frase “? ¿Está seguro de que desea XYZ ” en los diálogos de confirmación?

Parte de la razón por la que las personas omiten mensajes largos se debe a la velocidad de lectura.

Por el bien de la discusión, suponga que alguien con una velocidad de lectura promedio, alrededor de 200 palabras por minuto. (*)

Si usa solo 20 palabras en un diálogo, está preguntando eso que el usuario dedique 6 segundos a leer y comprender lo que escribió.

Si bien eso no parece mucho, una pausa impuesta de seis segundos cuando está tratando de hacer algo puede parecer un tiempo terriblemente largo .

(*) Y no cometa el error de asumir que una baja velocidad de lectura significa poca inteligencia.

Entonces, tres sugerencias para usted, todas dirigidas a lograr la máxima claridad con el mínimo esfuerzo.

1. Sea lo más conciso posible
2. Identifique el artículo en riesgo
3. Nombre los botones para las acciones

Aquí hay un cuadro de diálogo de eliminación simple:

Reduzcamos el número de palabras al mínimo para que sea más fácil de leer:

Ahora, identifiquemos el elemento en riesgo y etiquetemos los botones para la acción:

Mucho mejor: más fácil de leer y más claro.

Otro ejemplo: un cuadro de diálogo de continuación.

Simplifique la redacción.

De nuevo, identifiquemos lo que está pasando y etiquetemos los botones para acciones.

Una mejora definitiva.

He aquí un pensamiento final. Evite los negativos , especia lly dobles negativos. Algunos hablantes nativos de inglés encuentran complicados los dobles negativos, y muchos de los que aprenden inglés como segundo idioma los encuentran confusos (especialmente si su lengua materna usa dobles negativos para enfatizar en lugar de invertirlos).

Comentarios

• O simplemente puede leer las pautas de Windows UX msdn.microsoft.com/en-us/library/aa511258.aspx donde realmente escriben sobre esto 🙂
• Creo que en realidad estás dando algunos malos ejemplos: 1. Es » OK «, no » De acuerdo «. 2. Si hace una pregunta de sí / no, las posibles respuestas deben ser sí o no, ciertamente no OK y Cancelar. 3. Si identifica los botones para la acción, debe hacerlo con ambos botones, no solo con uno (es decir, Eliminar / Mantener, no Eliminar / Cancelar). Aparte de eso, también creo que cualquier oración debe contener al menos un sujeto y un verbo. , pero eso es personal.
• @BaGi – Creo que puede haber leído mal mi respuesta: ‘ muestro una progresión de pobre a mejor. Tener una pregunta Sí / No con Aceptar / Cancelar como botones es ciertamente pobre, pero es demasiado común, y esto es lo que estaba señalando. Para abordar sus puntos … Donde hay un inverso simple, usarlo para el botón Cancelar tiene sentido, por lo que Eliminar / Mantener es mejor que Eliminar / Cancelar, pero esto no es ‘ t siempre es posible: ¿cuál ‘ es la inversa de Post? Publicar / Don ‘ t Publicar parece torpe. Y creo que todos mis ejemplos son oraciones completas. Para tomar el último: » Continuar «: verbo; » Procesamiento de transacciones «: asunto.
• @Bevan: No ‘ ¿No crees que Post? Publicar / Don ‘ t Publicar es torpe. Save / don ‘ t save es lo que ve constantemente. En su última oración, » procesamiento de transacciones » no es en absoluto un sujeto, sino un objeto indirecto (consulte en.wikipedia.org / wiki / Object_% 28grammar% 29 ). Entendí que tus ejemplos muestran una mejora gradual, solo creo que el resultado final todavía contiene algunos defectos menores.
• @BartGijssens: Yo ‘ siempre prefiero Cancel a cualquier otra cosa … porque sin una sola neurona disparada, sé que no hace nada (efectivamente, una palabra menos para leer). El problema con » Don ‘ t save » es que puede usar » Deseche » en algún otro contexto (pobre).

Siempre me aseguro de mostrarle al usuario qué elemento se está eliminando (especialmente porque el diálogo puede ocultar el elemento en cuestión, pero también porque ver identificable el texto del cuadro de diálogo llamará la atención):

¿Eliminar «tu elemento favorito»?

También puedes inyectar un poco de humor aquí y allá, dependiendo del tipo de aplicación que estés creando:

Seguro que no quieres seguir sin ahorrar? [Sí, déjame en paz] [Ah, claro, gracias por recordármelo]

Si lo pruebas como usuario, notarás que los mensajes divertidos se notan con mayor frecuencia simplemente porque se destacan entre la multitud de mensajes genéricos y (si son lo suficientemente lindos) hacen que el usuario sonríe. ¿Qué más podrías pedir?

Comentarios

• O simplemente puedes seguir mi regla general: todos los botones de diálogo deben estar etiquetados como » D ‘ oh! «, incluso si hay varios botones.
• @ VirtuosiMedia Si hay dos botones, solo uno debe etiquetarse » D ‘ oh! » El otro debe etiquetarse » ¡Por qué eres pequeño…! »
• » … 14 usuarios hicieron clic en Do ‘ h, 5 usuarios hicieron clic en Nut y un usuario presionó la tecla M repetidamente. » – Jakob Nielsen
• » … Los 20 usuarios expresaron sorpresa por las luces rojas de emergencia, las sirenas y las advertencias de evacuación que se produjeron antes de la catástrofe nuclear. Los que sobrevivieron mencionaron más tarde que estaban divididos entre huir por seguridad y ver lo que había en el refrigerador. Conmovidos por la experiencia, parecían preguntarse si habían tomado la decisión correcta. »
• Sería más gracioso si dijera » Shirley » en lugar de » Seguramente «.

Google sugiere dos formas diferentes y ambas eliminan «usted «completamente.

Las pautas de escritura de diseño de Google sugieren lo siguiente:

Omita frases innecesarias

Puede omitir muchas frases introductorias comunes y llegar directamente al grano.

Más Diálogos de alerta de Material Design sugiere reformular la pregunta para eliminar el «¿estás seguro?»

Alertas con barras de título

Utilice las alertas de la barra de título solo para situaciones de alto riesgo, como la posible pérdida de conectividad. Los usuarios deben poder comprender las opciones basándose únicamente en el título y el texto del botón.

Si se requiere un título:

• Use una pregunta o declaración clara con una explicación en el área de contenido, como «¿Borrar almacenamiento USB?».
• Evite las disculpas, la ambigüedad o las preguntas, como «¡Advertencia!» o «¿Estás seguro?»

Es mejor no tener tales diálogos, en su lugar , implemente la funcionalidad de deshacer.

El cuadro de diálogo es inútil el 95% del tiempo, entonces, ¿por qué forzarlo a la gente? ¿Está tratando de ayudar a la gente? o está tratando de culpar al usuario «oye, confirmaste que querías eliminar ese elemento importante, ¡no me culpes!

Adivina qué, las personas aprenden a ignorar estos diálogos, siempre confirman inconscientemente cualquier acción que acaban de hacer.

Así que ese es el enfoque equivocado para resolver el problema.

El problema aquí es: la acción del usuario puede tener efectos no deseados si se realiza por error.

Una mejor solución para eso El problema sería permitirle al usuario deshacer su cambio.

Si le permites deshacer las eliminaciones, obtendrás dos cosas buenas:

• No tendrás que molestar el usuario con uso menos diálogos.
• Los usuarios pueden recuperarse de eliminaciones no intencionales.

Implementar deshacer es mucho más difícil que mostrar un cuadro de confirmación.

¿Eliminar este elemento?

¿Continuar?

Directo al grano.

Una cosa fundamental para recordar es que la gente ignora los mensajes «¿Estás seguro?». Tienes que obligarlos a pensar en la decisión. Aquí está uno de mis favoritos.

Comentarios

• Estos se vuelven irritantes si tiene que eliminar muchas cosas (» leads «, en este caso), pero esto funciona bien cuando ‘ estás tomando una » no volver » acción (por supuesto, podría programar para que no haya ‘ t ningún tipo de acción también)
• Yo ‘ no estoy seguro de qué los » no pueden deshacer » los medios de la casilla de verificación. Si no ‘ t lo marco, ¿podré deshacer la operación? ¿O el botón » No volver » no se activará hasta que lo marque? Este diálogo casi se siente como un formulario en sí mismo, incluido el manejo de errores y la administración del estado de los elementos de la IU. Si cometo un error en este diálogo, ¿aparecerá un diálogo que me diga qué hice mal? 😉
• @Rahul: Estoy de acuerdo contigo. El concepto aquí es bueno (si no puede ‘ t admitir Deshacer) pero el etiquetado es realmente extraño. Incluso el botón » Sin vuelta atrás «. Creo que No se puede deshacer es como una » Estoy de acuerdo con los términos » tipo de confirmación, pero esa ‘ es solo mi suposición
• Esto es absolutamente terrible.
• @Bennett, a los clientes les encantó. Horrible para ti es genial para otra persona. Lo que importa son los clientes. Para todos los demás, buenos puntos en la redacción de deshacer.

Lo que «tienes es gramaticalmente correcto, pero entiendo su punto.

Podría intentar dividir el mensaje en dos frases:

Este elemento se eliminará, ¿ ¿Seguro?

Esto mueve la parte importante de la pregunta al frente donde es (con suerte) más probable que se lea.

También tendería a evitar mensajes sobre acciones que se pueden deshacer y reducir el número de acciones que se pueden deshacer al mínimo absoluto.

Comentarios

• Y, por supuesto, reemplace this item con el nombre real del elemento.
• @Jared – sí – explíquele lo que va a hacer.

Para los mensajes críticos, desea ser lo más claro posible y asegurarse de que el usuario lea el mensaje.

Mensajes como

Al hacer clic aquí, acepta que …

¿Está seguro de que desea …

Piérdase en el usuario, el usuario lo lee como yada, yada, yada, lo que sea … y hace clic en sí sin mirar.

Para que el usuario lea el mensaje, debe estar en el orden correcto.

• Nombre la acción que sucederá
• luego la advertencia
• luego la pregunta
• luego la acción realizar.

Está a punto de enviar su solicitud. Esta acción no se puede deshacer. ¿Desea continuar? Haga clic en sí para continuar o haga clic en cancelar

Esto es un poco largo, pero si necesita que el usuario lea el mensaje, esta es la forma más segura de hacerlo.

Comentarios

• Su mensaje, aunque es mejor que yadayada , todavía tiene un problema – ¿por qué hago clic en » sí » para continuar, en lugar de » continuar » botón? Algo como esto sería mejor: Your application is ready to submit. If you continue, this can not be undone. Would you like to continue? [Continue] [Cancel]
• @Jared, Buen punto, suena mejor y sería más corto.
• ¿Qué tal un ¿versión? » ¿Enviar su solicitud? Esto no se puede deshacer. [Continuar] [Cancelar] » (De hecho, en muchos casos decir que la acción no se puede deshacer no es útil de todos modos).

Las Directrices de interfaz humana de Apple para Mac OS X tienen mucho que decir sobre cuadros de mensaje (paneles de alerta).

Los nombres de los botones deben corresponder a la acción que realiza el usuario al presionar el botón, por ejemplo, Borrar, Guardar o Eliminar . El botón más a la derecha del cuadro de diálogo, el botón de acción, es el botón que confirma el texto del mensaje de alerta. El botón de acción suele ser, pero no siempre, el botón predeterminado.(Tenga en cuenta que en los métodos Cocoa, el botón situado más a la derecha siempre se denomina botón predeterminado aunque no lo sea). Para obtener más información, consulte «Descartar cuadros de diálogo».

El problema con la API del cuadro de mensaje de Windows es que no le permite especificar los nombres de los botones que desea, sino que requiere que utilice su propio cuadro de mensaje o utilice el Sí / No integrado / Aceptar / Cancelar botones.

Para leer más, aquí hay un artículo interesante que habla sobre los problemas con los cuadros de mensaje en general: Por qué los cuadros de mensaje son Evil .

Comentarios

• Los problemas en la API del cuadro de mensajes de Windows son resueltos por API de diálogo de tareas . (Nuevo en Windows Vista)

No siempre se trata de estas acciones explícitas como eliminar, borrar, save..etc .. Puede haber ciertos escenarios en los que el usuario puede salir sin saberlo de un proceso crítico en curso.

Por ejemplo: el usuario está en medio de un pago y pulsa el botón Atrás.

En este escenario, el usuario debe ser alertado.