Para diagnosticar una aplicación confusa, observa sus pantallas, controles y respuestas mientras alguien intenta realizar una tarea que la aplicación admite. Busca el primer punto en el que deja de estar clara la siguiente acción. Compara lo que la persona espera con lo que la aplicación hace y comunica. Un guardado fallido o una función ausente requiere una solución distinta a la de una etiqueta o una ruta poco clara.
Imagina que alguien intenta cambiar una reserva que ya existe. Abre varios menús, vuelve a la pantalla de inicio y pregunta a un compañero. Esa secuencia es un punto de partida para una observación. Por sí sola no puede explicar si después desinstalará la aplicación ni qué pantalla necesita un rediseño.
¿Por qué se pierde el siguiente paso en una aplicación confusa?
Las personas pueden entender el objetivo y aun así no detectar una acción o una respuesta poco clara. Buscamos la primera discrepancia visible entre la tarea que pretenden realizar y la pantalla que encuentran. No te decidas por una explicación hasta haber comprobado la operación. Lo que parece un problema de navegación también puede ser una solicitud fallida o un resultado que el producto no admite.
La redacción sugiere una acción distinta. Una persona puede esperar otra pantalla de revisión después de pulsar Continuar, mientras que la aplicación envía inmediatamente una solicitud. Las directrices de Apple para los botones recomiendan dejar clara su finalidad. Compara la expectativa con el efecto real antes de elegir una etiqueta sustitutiva.
El resultado sigue siendo incierto. Alguien vuelve a pulsar porque no sabe si la aplicación ha aceptado la solicitud. Examina qué se guardó realmente y qué comunicó la pantalla. Una confirmación ausente y una operación fallida requieren soluciones distintas.
Las indicaciones de entrada llegan después del error. Comprueba si el campo explica qué valor necesita.
Para el contenido web, el criterio del W3C sobre etiquetas o instrucciones exige etiquetas o instrucciones cuando el contenido requiere que se introduzcan datos. Usa esa referencia para las pantallas web incluidas en una aplicación. Las aplicaciones nativas necesitan una revisión independiente específica de la plataforma.
La ruta pierde su contexto. Alguien vuelve desde una pantalla de detalle y no puede recuperar el elemento que estaba cambiando. Registra ese punto de partida, la acción elegida y la pantalla resultante. Define la primera transición confusa con suficiente precisión para reproducirla.
¿Cómo diagnosticas una aplicación confusa?
Empieza con un resultado admitido y un estado inicial comparable. Usa una cuenta de prueba y datos de prueba seguros para las acciones que envían, cobran, eliminan o afectan a otra persona. Escribe el objetivo sin nombrar el menú o el control que conduce a él. Quieres averiguar qué puede encontrar y entender la persona antes de darle una explicación.
- Define la finalización. Para cambiar una reserva, ¿el resultado previsto es una solicitud enviada o una nueva reserva confirmada? Comprueba qué resultado pueden admitir esta versión y esta cuenta.
- Registra el estado inicial. Anota la versión de la aplicación, el dispositivo, el idioma, los permisos y si la reserva ya existe. La cuenta de un administrador puede mostrar una ruta distinta a la cuenta de un cliente.
- Observa sin nombrar el control. Pide a la persona que intente alcanzar el objetivo. Registra la pantalla que elige, la etiqueta que lee y lo que espera. Si ayudas, anota la ayuda; completar la tarea después no la borra.
- Comprueba el resultado por separado. Compara la respuesta visible con la reserva guardada. Vuelve a abrirla en la cuenta de prueba o consulta el registro de prueba del proveedor. Una pulsación o una pantalla que parece indicar éxito no demuestra que se haya producido la actualización prevista.
Si inspeccionas la aplicación por tu cuenta, registra lo que puedas reproducir y haz visible esa limitación. Tu conocimiento del producto cambia la tarea. Una observación posterior con alguien que no lo conozca proporciona pruebas distintas.
Analiza esta tarea ficticia de reserva
Piensa en una aplicación inventada para reservar clases que permite solicitar otra sesión. El proveedor debe aceptar esa solicitud antes de que cambie la reserva. Las notas siguientes muestran cómo investigar un malentendido. No hemos usado una aplicación, una cuenta ni un participante reales para este ejemplo, y no hemos probado la redacción propuesta.
| Observación | Nota |
|---|---|
| Tarea prevista | Mover una reserva de clase existente a otra sesión. |
| Acción y etiqueta exacta | La persona pulsa Cambiar reserva; el botón envía una solicitud. |
| Resultado esperado | La persona cree que la nueva sesión ya está reservada. |
| Estado real | La reserva original se mantiene mientras la solicitud espera aceptación. |
| Comprobación propuesta | Probar Solicitar un cambio y un mensaje que indique que la solicitud se ha enviado. |
La discrepancia observada se refiere a lo que significa la acción. Una etiqueta distinta es una hipótesis que debe probarse frente a la operación real. Si la solicitud nunca llega al proveedor, investiga también la operación fallida. Si la confirmación inmediata es esencial para el producto, se trata de una decisión de producto independiente, no de algo que pueda aportar la etiqueta de un botón.
Escribe una observación antes de interpretarla. “Abrió la reserva, pulsó Cambiar reserva y esperaba una confirmación” describe un comportamiento en este ejercicio ficticio. “La interfaz es mala” omite la pregunta que todavía debes responder.
Haz el cambio más pequeño que responda a la observación
Elige una solución que aborde la discrepancia registrada y conserve la operación prevista. Empieza por la redacción, las instrucciones o la respuesta cuando esas sean las partes inciertas. Un cambio en la estructura de navegación o un rediseño más amplio necesita una razón basada en la tarea. Mantén visibles los fallos funcionales para que una explicación más clara no oculte una operación que sigue fallando.
-
Prueba un borrador específico. Para la reserva ficticia, muestra una etiqueta de acción propuesta y el estado resultante en un borrador interactivo. Nuestras auditorías de UX y prototipos de aplicaciones siguen esta secuencia de la tarea al prototipo. Compara lo que la persona espera antes de pulsar con el estado que reconoce después; no describas la etiqueta propuesta como una mejora demostrada.
-
Comprueba una ruta de error. El criterio del W3C sobre identificación de errores para contenido web exige que un error de entrada detectado automáticamente identifique el elemento afectado y describa el error mediante texto. Un contorno de color por sí solo no ofrece esa explicación. Los controles nativos y una revisión de accesibilidad completa requieren sus propias comprobaciones específicas de la plataforma.
-
Comprueba la respuesta en pantalla y con tecnología de asistencia. Para el contenido web, el criterio del W3C sobre mensajes de estado aborda cómo poner los cambios de estado definidos a disposición de las tecnologías de asistencia sin apartar el foco del control actual. Comprueba qué aparece en la pantalla y qué pueden detectar las herramientas de asistencia. Un lector de pantalla, por ejemplo, es un programa que puede leer en voz alta el contenido de una interfaz. Este criterio seleccionado no certifica la aplicación, no fija un objetivo de tiempo de respuesta ni repara una operación lenta.
-
Sigue la transición web. Cuando la ruta de la misma cuenta o reserva pasa a una página web, incluye esa transición en la prueba. El desarrollo de sitios y aplicaciones web debe conservar la redacción de la tarea y el estado real al cruzar ese límite.
¿Qué debes comprobar después del cambio?
Repite la misma tarea prevista desde un estado comparable y registra lo que ocurrió. Mantén visibles junto al resultado la versión de la aplicación, el dispositivo, el idioma y la ayuda. Una comparación útil se centra en la tarea que observaste: si la persona encontró la acción, entendió su efecto y reconoció el resultado real. Deja abierta cualquier conclusión empresarial más amplia hasta que tengas pruebas que la sustenten.
Registra juntos la finalización y la ayuda, el primer desvío equivocado, los errores de entrada que la persona no pudo interpretar y si confundió una solicitud con una confirmación. Repite las comprobaciones pertinentes con el idioma y la configuración de accesibilidad que estás revisando. Examina las etiquetas más largas y la información disponible mediante esa configuración, en lugar de suponer que la pantalla en inglés representa todas las versiones.
Si ya registras acciones de la aplicación, como el inicio de una solicitud de cambio de reserva o su llegada al proveedor, comprueba que los registros coincidan con esos estados reales. Relaciona los cambios en las consultas de soporte con esa misma ruta. La ausencia de descargas de la aplicación es un problema de adquisición independiente; nuestra guía sobre una aplicación que no recibe descargas comienza antes de que alguien abra el producto.
Una repetición satisfactoria puede describir esa observación. No puede determinar por qué las personas desinstalan la aplicación ni atribuir un cambio de retención a la solución. Registra la siguiente pregunta sin resolver junto con la persona responsable de comprobarla.
Cómo podemos ayudarte
Empezamos por la tarea admitida, la primera transición poco clara y las pruebas necesarias para elegir una solución. Podemos convertirlo en un prototipo, comprobar la ruta implementada e incluir su equivalente web. Lleva una descripción de la tarea y del punto en el que se detuvo a una conversación sobre el proyecto. Elimina los nombres de clientes y otros datos personales de cualquier ejemplo que compartas.
