Revisa tareas completas, no pantallas aisladas
Para revisar una aplicación empresarial, pregunta si los usuarios previstos pueden completar sus tareas reales, entender el resultado y recuperarse cuando algo falla. Empieza por unos flujos representativos. Las pantallas atractivas solo son útiles cuando información, permisos y acciones respaldan el trabajo.
Mi trabajo con Customiser, Medaur HIMS y Digitrack implica revisión documental, historiales de pacientes e información financiera. En todos esos contextos, la unidad útil de revisión es una tarea: introducir la información, comprobarla, completar la acción y entender el estado resultante.
Elige tareas y define cuándo están completadas
Enumera las tareas frecuentes y las acciones menos frecuentes con consecuencias importantes. Incluye crear y buscar registros, corregir errores, aprobar trabajo y exportar información cuando corresponda. Utiliza datos realistas con permiso o ejemplos claramente sintéticos.
Escribe el resultado esperado antes de la sesión. «Revisa esta pantalla» genera opiniones sobre apariencia. «Encuentra la última versión aprobada y explica quién la aprobó» prueba la estructura de información y la comprensión. Evita indicar qué botones utilizar cuando eso forme parte de lo que necesitas descubrir.
Incluye personas con distintas responsabilidades y familiaridad. Un administrador que conoce todo el modelo de datos puede navegar por una pantalla que confunde a un usuario ocasional. Vincula las observaciones al rol y la tarea, en lugar de promediar a todos en un usuario genérico.
Comprueba la introducción y edición de datos
Inspecciona etiquetas, campos obligatorios, ejemplos y valores predeterminados. Cada campo debe explicar qué información corresponde sin depender de un texto provisional que desaparece al escribir. Cuando dos valores se parezcan, añade contexto suficiente para elegir el correcto.
Prueba la navegación con teclado y las correcciones habituales. ¿Puede una persona recorrer el formulario, editar un valor anterior y ver qué campos requieren atención? Si falla la validación, conserva la información válida y explica cómo resolver el problema junto al campo correspondiente.
Ejemplo de una herramienta ficticia de planificación: un coordinador introduce un cliente, selecciona un empleado y envía una cita sin hora de finalización. El formulario identifica el campo ausente y conserva los demás valores. Tras corregirlo, la conexión se interrumpe durante el envío. La herramienta comprueba si la cita se guardó antes de ofrecer un reintento y después muestra su referencia confirmada. Revisa toda la secuencia, incluido el acceso con teclado y si el coordinador entiende si otro envío crearía un duplicado.
Haz comprensibles el estado y las consecuencias
Revisa etiquetas como borrador, aprobado, enviado y completado frente al flujo real. Un estado debe describir algo que el sistema sabe, no un resultado deseado. Tras guardar o enviar, muestra qué ocurrió y si queda algún paso.
Para acciones con consecuencias importantes, aclara el registro afectado y el resultado antes de ejecutarlas. Cuando las reglas lo permitan, ofrece una forma de revertir la acción o corregir el registro. Utiliza confirmación solo cuando ayude a tomar una decisión significativa; los diálogos innecesarios repetidos se convierten en ruido de fondo.
Una herramienta hipotética de revisión documental debe distinguir aceptar un valor extraído de enviar todo el registro a otro sistema. Combinar ambas acciones en un botón «Hecho» sin explicación dificulta entender la responsabilidad y recuperarse de un error.
Revisa permisos, fallos y tareas prolongadas
Prueba cada rol con el acceso previsto. Confirma tanto lo que muestra la interfaz como lo que la aplicación permite realmente. Ocultar un botón no sustituye la aplicación del permiso subyacente. Los errores deben explicar el siguiente paso disponible sin exponer información privada ajena.
Prueba listas vacías, registros no disponibles, solicitudes fallidas y conexiones interrumpidas. La interfaz debe distinguir «no hay resultados» de «no se pudieron cargar». Ofrece reintentos seguros y comprueba que las acciones repetidas no creen duplicados.
Para procesos que tardan, explica si el trabajo está en cola, en curso, pendiente de revisión o fallido. Considera si la persona puede salir de la página y volver al resultado. Los indicadores de carga sin explicación dificultan saber si esperar, reintentar o pedir ayuda.
Observa el comportamiento y prioriza las correcciones
Pide a los participantes que expliquen qué esperan antes de acciones importantes y qué creen que ocurrió después. Registra dudas, retrocesos, suposiciones erróneas y tareas incompletas. Separa un problema observado de una preferencia visual; ambos pueden importar, pero necesitan pruebas distintas.
Prioriza por consecuencias y frecuencia. Una aprobación mal etiquetada puede ser más urgente que un espaciado incoherente. Agrupa problemas por su causa, como identidad de registro poco clara o lenguaje de estados inconsistente, en lugar de rediseñar cada pantalla por separado.
Vuelve a probar el flujo modificado con la tarea original y los roles afectados. Registra tarea, dificultad observada, consecuencia, corrección propuesta y comprobación de aceptación. Esto da a diseño y desarrollo un comportamiento específico que mejorar y una forma de verificarlo.
