En una misma página de Cadulis, dos botones lanzaban la misma acción. No tenían el mismo nombre. No lo habíamos notado, porque conocemos nuestra herramienta de memoria, y ese es precisamente el problema. La ergonomía de un software se evalúa con quienes lo usan.
Desde octubre de 2024, la agencia de Metz UX-KEY observa el uso real de nuestra aplicación y nos envía cada mes un informe. Te mostramos cómo funciona su dispositivo y qué nos ha hecho corregir, antes de terminar con las preguntas de ergonomía que deberías hacerle a cualquier editor antes de elegir tu software.
Por qué la ergonomía de un software de campo cuenta el doble
Una pantalla mal diseñada, en la oficina, se tolera. En el terreno, el técnico sostiene su teléfono con una mano, a veces con guantes, a menudo entre dos intervenciones y con el cliente esperando. No tiene tiempo para buscar un botón. Tampoco para repetir una entrada fallida.
Y luego está todo lo que la oficina no ve: la pantalla bajo el sol en un tejado, la señal que se debilita en el sótano, un teléfono personal ya antiguo con la fuente aumentada.
Queda la repetición. Tres segundos perdidos en cada cierre de intervención, veinte veces al día, multiplicado por un equipo y por un año, termina pesando.
Cuando la herramienta molesta, termina siendo evitada. El técnico toma notas en una libreta, llama a la oficina, envía una foto por SMS. El software está instalado, pero ya no se usa. Lo mencionábamos en nuestro artículo sobre la digitalización de los equipos de campo y la resistencia al cambio; gran parte de esa resistencia se debe a detalles de ergonomía de software que nadie se ha tomado el tiempo de revisar.
El problema es que un editor está mal posicionado para verlos. Sabe dónde está cada función, nunca se equivoca de botón. De ahí el interés de una mirada externa, que parte de los datos de uso.
Cómo funciona la auditoría UX de UX-KEY
UX-KEY es una agencia de Metz, creada en 2019, especializada en la experiencia de usuario de software en línea para empresas (CRM, ERP, herramientas de RRHH).
Un script que observa el uso real
Se instala un script de recopilación en la aplicación. Registra los datos de interacción para rastrear la navegación de los usuarios. Según UX-KEY, solo recopila datos de carácter no personal, y la agencia publica sus políticas de conformidad con el RGPD y el reglamento europeo sobre IA.
La patente de su tecnología de análisis de recorridos, registrada en 2020, se refiere al seguimiento en tiempo real de los cambios de estructura de las páginas. Este punto es importante para una herramienta como la nuestra, donde las pantallas se recomponen constantemente (una planificación que se recarga, una ficha de intervención que se abre encima). El resultado toma, entre otras cosas, la forma de mapas de calor que muestran dónde hacen clic los usuarios.
Un análisis asistido, conclusiones humanas
Una IA ayuda a clasificar estos datos. Pero la auditoría en sí la realizan los diseñadores UX de la agencia, quienes interpretan los comportamientos y redactan las recomendaciones.
Un informe al mes, un tema por informe
Cada mes, recibimos un informe dedicado a un solo tema, por ejemplo la ergonomía de un recorrido, la accesibilidad, la visualización en móvil o la redacción de etiquetas. Los puntos de fricción se enumeran y las recomendaciones se priorizan.
Una auditoría única suele terminar en un cajón. Esta vuelve a la mesa todos los meses, y hay que decidir (corregir, planificar o asumir dejarlo así).
No somos el único software de campo en este caso. UX-KEY cuenta, por ejemplo, cómo hizo más intuitivo el seguimiento de obras y tickets de mantenimiento de DriveIM, una plataforma de gestión técnica para el sector inmobiliario.
Lo que la auditoría ha corregido en la ergonomía de nuestro software
Nada espectacular, solo defectos que ya nadie en nuestro equipo veía.
Dos botones, dos nombres, una sola acción
En algunas páginas, dos botones lanzaban la misma acción bajo dos etiquetas diferentes. Nosotros lo sabíamos. Un usuario, en cambio, ve dos nombres y busca dos funciones: se pregunta cuál elegir, duda, o peor, cree que le falta un paso.
Las reglas de accesibilidad web establecen el mismo principio a nivel de un sitio. El criterio 3.2.4 de las WCAG 2.2 exige que los componentes que tienen la misma función sean identificados de manera coherente. Hemos armonizado las etiquetas.
Botones demasiado juntos
En otros lugares, los botones estaban tan cerca unos de otros que un clic podía caer en el vecino. Con el ratón, aún se tolera. Con el pulgar, en una escalera mal iluminada, a veces se activa una acción no deseada.
La norma también da aquí una referencia. El criterio 2.5.8 de las WCAG 2.2, de nivel AA, establece un objetivo de al menos 24 píxeles CSS de lado, o un espacio suficiente entre dos objetivos más pequeños. Hemos revisado el espaciado de los botones afectados.
Por qué nadie nos lo había señalado
No se llama a su editor para decir que dudó dos segundos frente a un botón, o que hizo clic al lado una vez en la semana. Uno se queja, lo repite y se acostumbra. Este tipo de fricción se percibe sobre todo en los datos de uso, cuando alguien se toma el tiempo de analizarlos.
Lo que una auditoría UX no reemplaza
Una auditoría de ergonomía de software tiene sus límites. Muestra dónde se bloquean los usuarios; no siempre dice por qué, ni lo que necesitarían y aún no existe.
Los comentarios directos siguen siendo insustituibles. Un técnico que explica que introduce sus horas por la noche porque no tiene tiempo en el lugar le enseña algo diferente al editor que cualquier mapa de calor. La formación también mantiene su lugar, incluso con una herramienta bien diseñada.
Queda decidir. Corregir un defecto de ergonomía cuesta tiempo de desarrollo, que no se dedicará a otra cosa. El informe prioriza, el equipo decide.
Cinco preguntas de ergonomía que hacer antes de elegir tu software
No hace falta ser diseñador para evaluar la ergonomía de un software de intervención. Durante una demostración o una prueba, estas cinco preguntas bastan para hacer la selección.
- ¿Una misma acción tiene el mismo nombre en todas partes? Recorra tres o cuatro pantallas. Si “Validar”, “Guardar” y “Finalizar” parecen hacer lo mismo, sus técnicos dudarán.
- ¿Se pueden pulsar fácilmente los botones con el dedo? Haga la demostración en un teléfono, no en el ordenador del editor. Pruebe con el pulgar, usando solo una mano.
- ¿Cuántas pantallas son necesarias para cerrar una intervención? Cuéntelas. Cada pantalla de más se vivirá cien veces por semana.
- ¿Qué ocurre cuando se comete un error? Una acción destructiva debe pedir confirmación, y un error de introducción de datos debe poder corregirse sin tener que empezar de nuevo.
- ¿Cómo sabe el editor qué molesta a sus usuarios? Esta es la pregunta más reveladora. Una respuesta vaga (“nuestros clientes están contentos”) vale menos que un método: feedback de los usuarios, datos de uso, auditoría externa.
Un consejo más. Haga que uno de sus técnicos pruebe la herramienta, no solo la persona que firmará el contrato. En diez minutos de prueba, detectará lo que la mejor demostración no muestra, y sabrá si realmente la utilizará en el terreno.
¿Usted mismo es editor de un software? La guía de UX design para interfaces SaaS publicada por UX-KEY detalla el proceso, desde la investigación de usuarios hasta las pruebas.
Para el resto de la elección (funcionalidades, precio, compromiso), nuestra guía para elegir el mejor software de gestión de intervenciones repasa los demás criterios.
Ergonomía del software: un trabajo permanente
Cada nueva función añade un botón, una pantalla, una etiqueta, y por tanto una ocasión de enturbiar lo que antes era claro. El remedio se resume en pocas palabras: observar regularmente cómo se utiliza realmente la herramienta y corregir los pequeños detalles antes de que se conviertan en hábitos de evasión.
Lo hacemos con UX-KEY, un informe al mes. Y si quiere juzgar por sí mismo, pídanos una demostración en el teléfono, con sus propias intervenciones.
