Experiencia de Usuario — Principios Profundos

Los principios de experiencia de usuario de GM Transport van más allá de las reglas de componentes. Definen cómo piensa el sistema sobre las personas que lo usan: qué esperan, cuándo tienen tiempo de leer, cuándo están bajo presión y cómo reaccionan cuando algo falla. Este documento desarrolla esos principios con el nivel de detalle necesario para tomar decisiones de diseño e implementación coherentes.

El usuario como protagonista del flujo

El diseño de GM Transport parte de una premisa fundamental: el usuario sabe lo que quiere hacer. No llega a la aplicación a explorar; llega a completar una tarea. El diseño no debe interponerse entre el usuario y esa tarea.

Esta premisa tiene consecuencias estructurales:

La pantalla de inicio muestra el estado más relevante de la operación activa, no un dashboard genérico de bienvenida.
Los flujos no interrumpen con confirmaciones innecesarias ni mensajes informativos que el usuario no solicitó.
Las acciones frecuentes están en el primer nivel de navegación. Las acciones raras están disponibles pero no ocupan espacio visual prominente.

La diferencia entre un diseño que respeta esta premisa y uno que no: en el primero, el usuario completa su tarea y sale. En el segundo, el usuario trabaja contra la interfaz para llegar a donde necesita ir.

Arquitectura de información

Jerarquía de contenido

Cada pantalla organiza su información en tres niveles:

Nivel primario — La información o acción más importante del contexto. Visualmente dominante. El usuario la ve sin buscar.
Nivel secundario — Información de soporte que confirma o amplía el nivel primario. Visible pero no compite.
Nivel terciario — Metadatos, identificadores, detalles administrativos. Disponibles pero subordinados.

Un error frecuente es elevar contenido terciario al nivel primario porque “el usuario podría necesitarlo”. La regla es la opuesta: todo sube de nivel solo si hay evidencia de que el usuario lo necesita en ese contexto, no como precaución.

Densidad de información

La densidad de información varía según el contexto de uso:

Contexto	Densidad adecuada
Operación en campo (móvil, moverse, apuros)	Baja. Pocos elementos, texto grande, acción obvia.
Revisión de datos (escritorio o tablet, tiempo disponible)	Media. Tablas, filtros, múltiples columnas.
Configuración o administración	Alta. Formularios completos, múltiples campos, ayuda contextual.

El mismo dato puede mostrarse a densidades diferentes según quién lo consume y en qué situación. Un conductor que ve una lista de trayectos necesita menos columnas que un coordinador que administra esa misma lista.

Flujos críticos

Definición

Un flujo crítico es aquel que, si falla o genera confusión, tiene consecuencias operacionales directas: un registro incorrecto, un reporte con errores, un viaje sin salida registrada.

Los flujos críticos de GM Transport reciben tratamiento especial de diseño:

Se documentan y prueban de forma independiente antes de cualquier otro flujo.
No se modifican sin validación con usuarios reales en contexto de uso.
El feedback de estos flujos es siempre explícito: el usuario sabe con certeza que la acción se completó.

Principios aplicados a flujos críticos

Confirmación explícita, no implícita. En acciones irreversibles o de alto impacto (registrar salida de viaje, confirmar conciliación fiscal, enviar reporte al SAT), el sistema pide confirmación activa. No es un diálogo de “¿estás seguro?”; es un resumen de lo que se va a hacer seguido de una acción afirmativa con texto descriptivo (“Confirmar salida” en lugar de “Aceptar”).

Feedback inmediato, persistencia diferida. El usuario recibe confirmación visual en el momento en que completa la acción, incluso si la sincronización con el servidor aún no ocurrió. El sistema guarda localmente y sincroniza en background. El usuario no espera.

Reversibilidad donde sea posible. Si una acción puede deshacerse, se ofrece esa opción. Si no puede deshacerse, el diseño hace todo lo posible para que el usuario comprenda eso antes de ejecutarla.

Errores de usuario, no errores del sistema. Cuando el usuario introduce datos incorrectos, el sistema lo informa con precisión: qué campo tiene el problema y por qué. No muestra errores técnicos. No muestra errores genéricos. El mensaje de error es accionable: el usuario sabe exactamente qué corregir.

Estados de pantalla

Toda pantalla que cargue datos externos existe en uno de cuatro estados. Diseñar solo el estado “con datos” es un error: los otros tres son igualmente parte de la experiencia.

Estado de carga

El indicador de carga comunica actividad, no inacción. El usuario ve que el sistema está trabajando. Las reglas:

El indicador de carga ocupa el espacio donde aparecerán los datos, no un overlay que bloquea toda la pantalla.
No se muestra texto adicional junto al indicador de carga salvo que la operación sea larga y el usuario necesite saber qué está ocurriendo (“Descargando facturas del SAT…”).
Si la carga tarda más de 10 segundos, se muestra información de progreso cuando esté disponible.

Estado vacío

El estado vacío no es un error. Es una condición normal que ocurre cuando el usuario llega antes que los datos (primera sesión, filtros muy restrictivos, período sin actividad).

Un estado vacío bien diseñado:

Muestra un ícono relacionado con el contenido esperado, no un ícono genérico de “sin datos”.
Explica brevemente por qué está vacío en ese contexto específico.
Ofrece una acción que lleve al usuario al siguiente paso cuando tiene sentido.

Un estado vacío mal diseñado muestra solo “No hay datos” y deja al usuario sin orientación.

Estado de error

El error no es una excepción; es parte del flujo normal en software operacional. La conexión se pierde, el servidor responde tarde, los datos del servidor tienen un formato inesperado.

Un estado de error bien diseñado:

Describe qué salió mal en términos de usuario, no en términos técnicos.
Ofrece una acción de reintento cuando tiene sentido.
No bloquea toda la pantalla si el error es parcial (un componente falla mientras otros cargan correctamente).

Lo que nunca aparece en un mensaje de error al usuario: códigos HTTP, nombres de excepciones, rutas de archivo, stack traces.

Estado con datos

Es el estado donde el diseño pasa de la arquitectura de información a la presentación detallada. Las reglas generales:

Los datos se presentan en el orden en que el usuario los necesita, no en el orden en que llegan de la API.
Las listas se paginan o cargan de forma incremental. Nunca se cargan todos los ítems en memoria antes de mostrar el primer elemento.
Los elementos interactivos de una lista tienen área táctil completa, no solo el texto.

Formularios

Los formularios son los puntos de mayor fricción en cualquier aplicación. El diseño los trata como flujos que deben optimizarse para la tasa de completitud, no como colecciones de campos.

Cuántos campos mostrar

La regla es directa: mostrar solo los campos necesarios para completar la acción en ese momento. Si un formulario tiene más de cinco campos visibles simultáneamente, se divide en pasos secuenciales.

Esto no significa siempre usar un stepper con pasos numerados. A veces la división correcta es mostrar campos adicionales de forma progresiva: el campo B aparece cuando el campo A tiene un valor que lo hace relevante. El usuario nunca ve un formulario vacío con veinte campos por rellenar.

Validación

La validación ocurre en el momento correcto para el usuario, no para el sistema:

No validar en tiempo real mientras el usuario escribe. Interrumpe el flujo de escritura.
Sí validar cuando el usuario sale del campo (evento onBlur / focusOut). En ese momento ya terminó de escribir.
Sí validar todos los campos al intentar enviar el formulario, incluso los que ya pasaron su validación individual.

El mensaje de error aparece inmediatamente debajo del campo afectado. No en un alert. No en un banner al inicio del formulario. Debajo del campo.

Campos obligatorios

Los campos obligatorios no se marcan con un asterisco que requiere leer una leyenda. El sistema parte de que todos los campos visibles son necesarios. Si un campo es opcional, se indica explícitamente con la etiqueta “(opcional)” junto al nombre del campo.

Estado del botón de envío

El botón de envío se desactiva durante el procesamiento. No desaparece, no muestra un spinner separado: el propio botón muestra el indicador de carga en su interior. El usuario sabe que su acción se está procesando sin perder el contexto de lo que acaba de hacer.

Navegación

Principio de navegación predecible

El usuario siempre debe poder responder tres preguntas sin pensar:

¿Dónde estoy?
¿Adónde puedo ir desde aquí?
¿Cómo vuelvo al punto anterior?

El diseño responde a estas preguntas de forma visual y estructural. El elemento activo en la barra de navegación responde a la primera. La propia barra responde a la segunda. El botón de retroceso (nativo o en el AppBar) responde a la tercera.

Profundidad de navegación

Los flujos de la aplicación no tienen más de tres niveles de profundidad:

Pantalla principal (bottom navigation).
Sección o lista dentro de esa pantalla.
Detalle o formulario de un ítem.

Si un flujo requiere un cuarto nivel, es una señal de que la arquitectura de información necesita revisión, no que se debe agregar otro nivel de navegación.

Retroceso y pérdida de datos

Cuando el usuario navega hacia atrás desde un formulario con cambios sin guardar, el sistema pregunta antes de descartar. La pregunta es concreta: “¿Descartar los cambios en este formulario?”, no “¿Estás seguro?”. Las opciones son “Descartar” y “Continuar editando”.

Esta regla aplica solo cuando hay cambios reales que se perderían. No se interrumpe la navegación hacia atrás cuando el formulario está vacío o sin modificar.

Retroalimentación del sistema

Cuándo dar feedback

El sistema da feedback en cada momento en que el usuario podría dudar si su acción tuvo efecto. Los momentos obligatorios:

Al completar una acción que guarda o envía datos.
Al completar una acción que tarda más de medio segundo.
Al completar una acción que puede fallar (operación de red, escritura en disco).
Al recuperar conexión después de haber operado offline.

Los momentos donde el feedback es innecesario o contraproducente:

Al navegar entre pantallas dentro del flujo esperado.
Al abrir o cerrar elementos de interfaz (menús, acordeones, modales sin datos).
Al iniciar una operación que dura menos de 300ms (el resultado es visible antes de que el feedback sea perceptible).

Cómo dar feedback

El canal de feedback depende de la urgencia e importancia de la información:

Tipo	Canal	Cuándo
Confirmación de acción exitosa	SnackBar breve (3s)	Registro guardado, sincronización completada
Error recuperable	SnackBar con acción de reintento (4s)	Error de red, timeout
Error crítico no recuperable	Estado de error en pantalla con instrucción	Datos corruptos, acción imposible
Proceso en progreso	Indicador en el componente afectado	Upload, descarga larga, cálculo intensivo
Operación offline	SnackBar informativo + indicador persistente	Guardado local sin sincronizar

El SnackBar es para información transitoria. Los errores que requieren acción del usuario no pertenecen a un SnackBar: pertenecen al estado de pantalla.

Accesibilidad como realidad operacional

La accesibilidad no es solo cumplimiento normativo. En el contexto operacional de GM Transport, es una necesidad práctica:

Los usuarios trabajan en condiciones que degradan temporalmente su capacidad de interacción: vibración, guantes, fatiga, distracción.
Las pantallas se usan en ángulos no óptimos y bajo iluminación variable.
Los dispositivos varían en tamaño, resolución y calidad de pantalla.

Diseñar con los estándares WCAG AA como mínimo no es hacer concesiones al diseño; es asegurar que el software funciona en las condiciones reales en que será usado.

Resumen

El usuario de GM Transport llega a la aplicación a completar una tarea. El diseño no se interpone.
La jerarquía de información tiene tres niveles: primario, secundario y terciario. Solo sube de nivel lo que el usuario necesita en ese contexto.
Los flujos críticos tienen tratamiento especial: confirmación explícita, feedback inmediato, reversibilidad donde sea posible, errores accionables.
Toda pantalla con datos externos maneja los cuatro estados: carga, vacío, error y con datos. Los cuatro tienen diseño explícito.
Los formularios muestran solo los campos necesarios. La validación ocurre al salir del campo, no durante la escritura.
La navegación tiene máximo tres niveles de profundidad. El retroceso siempre funciona. Los cambios sin guardar se confirman antes de descartar.
La accesibilidad es una necesidad operacional, no solo normativa. Las condiciones de campo degradan temporalmente la capacidad de interacción del usuario.