Qué probar antes de aprobar el rediseño de una aplicación de negocio

Imagina que las nuevas pantallas tienen buen aspecto. Tu proveedor te enseña a buscar un pedido, modificarlo y guardarlo. Ahora te pide que apruebes el rediseño para poder avanzar con el desarrollo.

Antes de dar el visto bueno, deja que alguien que vaya a usar la aplicación realice una tarea importante. Explícale la situación y el resultado que necesita, y observa qué hace. Quien sigue una presentación tiene a alguien que le indica el camino. Quien atiende una petición de un cliente tiene que encontrarlo por su cuenta.

Empieza por el trabajo que importa

Elige tareas que la gente haga a menudo o en las que un error pueda causar problemas. Si una situación excepcional cambia lo que la persona debe hacer, inclúyela también. El alcance adecuado depende de tu aplicación y de la decisión que tengas que tomar.

Veamos un ejemplo hipotético. Una persona encargada de los pedidos recibe una petición de un cliente para cambiar la dirección de entrega antes de que el pedido salga. Tiene que encontrar el pedido correcto, corregir la dirección y saber si el cambio se ha aplicado.

Prepara pedidos de muestra con datos de clientes inventados. Dale a esa persona un mensaje creíble del cliente y suficiente información para identificar el pedido. No introduzcas datos reales de clientes ni de la empresa en un prototipo que no esté preparado para protegerlos.

Después, pídele que gestione la petición. Evita darle instrucciones como «abre Pedidos, elige Editar y pulsa Guardar». Esos pasos le dan la respuesta que intentas averiguar.

La guía de Marieke McCloskey del 12 de enero de 2014 sobre escenarios de tareas explica esta diferencia: da a las personas un contexto significativo y un objetivo sin revelarles el recorrido por la interfaz.

Deja que lo intente quien probablemente lo usará

Busca a alguien que haga este tipo de trabajo o que probablemente vaya a hacerlo. Si el personal administrativo corrige pedidos, un responsable que ya conoce las pantallas propuestas no puede sustituirlo. Incluye otros perfiles cuando su trabajo plantee preguntas distintas.

Usa condiciones que importen para la tarea. Alguien que trabaja todo el día en un escritorio puede depender del teclado. Quien consulta pedidos desde el móvil se encuentra con otra pantalla y otra forma de introducir datos. Si la gente usa tecnología de asistencia, prepara la configuración correspondiente y comprueba si el prototipo la admite.

La guía de GOV.UK sobre pruebas de usabilidad moderadas explica cómo observar a usuarios reales o probables al intentar tareas creíbles. Puedes aplicar ese principio al trabajo concreto que necesitas revisar sin reproducir todo un programa gubernamental de investigación.

Fíjate en dónde mira la persona, cuándo duda, si se equivoca de camino o pasa por alto información. Escucha lo que cree que ha ocurrido. Si tienes que ayudarla, anota dónde y cómo. Terminar con indicaciones te dice algo distinto a terminar sin ayuda.

«Me gusta el diseño» es una opinión útil sobre las preferencias de alguien. «Pensaba que la dirección ya se había guardado, pero seguía en modo de edición» señala un problema concreto que puedes investigar.

Ahora imagina que el pedido ya se ha enviado

En el mismo ejemplo hipotético, el cliente pide el cambio demasiado tarde para una corrección normal. ¿Puede la persona entender en qué estado está el pedido y decidir qué hacer? Quizá necesite la aprobación de un responsable o tenga que ponerse en contacto con el equipo de expedición.

Decide cuál debería ser el siguiente paso en tu empresa y deja que la persona lo intente. Incluye las pantallas y opciones pertinentes si el prototipo puede mostrarlas. Busca un resultado claro: ¿sabe la persona si se ha cambiado la dirección, si alguien más tiene que actuar y qué respuesta puede dar al cliente?

Una advertencia simulada puede mostrar si el texto se entiende. No demuestra que la aplicación en funcionamiento vaya a impedir un cambio no autorizado ni a enviar un aviso al equipo de expedición. Deja esas preguntas para comprobaciones que puedan responderlas.

Elige un prototipo que pueda responder a tu pregunta

Un boceto puede ayudarte a hablar sobre lo que debería aparecer en una pantalla y a valorar si la idea propuesta tiene sentido. Un prototipo interactivo puede permitir que alguien encuentre un pedido, pase de una pantalla a otra e interprete una confirmación, siempre que esas partes estén preparadas. Explica a todos qué partes funcionan y cuáles son simulaciones.

Si quieres saber si la persona encuentra cómo corregir un pedido, deja que pruebe ese recorrido. Si estás decidiendo si entiende una advertencia, muéstrasela en la situación en la que aparecería. Preguntar si cree que podría usar una pantalla te da su predicción; observar un intento te muestra lo que hace de verdad.

En su relato del 27 de agosto de 2014 sobre el uso de prototipos en GDS, Katherine Alsop describió la diferencia entre una demostración estable para las partes interesadas y los prototipos que se modifican durante la investigación. También señaló que investigar con un servicio en funcionamiento puede revelar problemas de tiempo de respuesta y gestión de errores que no aparecen en un prototipo.

Esto importa al aprobar el trabajo. Un mensaje interactivo de «Guardado» puede ayudar a comprobar si la persona entiende el resultado. Para saber si se guardaron los datos correctos, si las peticiones repetidas se gestionan de forma segura y si los sistemas conectados recibieron el cambio, hacen falta comprobaciones adecuadas de la implementación. La seguridad, los permisos aplicados por el sistema y la velocidad también necesitan pruebas en las partes correspondientes de la aplicación en funcionamiento.

Observar a las personas con la configuración de asistencia que usan habitualmente puede revelar barreras prácticas. Como explica la guía del W3C para incluir a usuarios en la evaluación de la accesibilidad, esto debe acompañar a la evaluación frente a los estándares de accesibilidad. Completar estas tareas no demuestra que la aplicación cumpla esos estándares. Si el prototipo no admite una configuración necesaria, anota esa limitación y organiza la comprobación adecuada más adelante.

Sal de la reunión con una decisión que puedas explicar

Anota lo que has observado mientras aún lo tienes fresco. Deja constancia de estos puntos prácticos:

• Quién probó qué: el perfil de la persona, la tarea, el dispositivo y la forma de introducir datos, además de las partes que admitía el prototipo.
• Qué ocurrió: si llegó al resultado previsto, dónde tuvo dificultades y qué ayuda necesitó. Separa lo observado de las suposiciones sobre la causa.
• Qué cambiar y volver a probar: indica el texto confuso, la información que falta o el siguiente paso poco claro. Después del cambio, deja que alguien vuelva a intentar el trabajo afectado.
• Qué necesita una aplicación en funcionamiento: anota las preguntas abiertas, quién las comprobará y cuándo. En nuestro ejemplo, podrían ser quién puede aprobar un cambio tardío y cómo se avisa al equipo de expedición.

Así podrás aprobar la dirección que respaldan las pruebas, pedir cambios donde la gente tuvo dificultades o aplazar una decisión concreta hasta tener las pruebas adecuadas. Puedes hacer las tres cosas en partes distintas del rediseño. Aprobar las pantallas de pedidos no implica aceptar una integración con expedición que aún no se ha probado.

Si estás preparando el rediseño de una aplicación de negocio, nuestro trabajo de diseño puede servir para iniciar una conversación sobre quién usa la aplicación, qué necesita hacer y qué decisiones quieres tomar.