[🛠] Operations Automation #5: Convertí un prototipo fallido en criterios de auditoría de UI

✨ Resumen de GPT-5.6 Sol

Un registro de cómo convertí las tarjetas enormes llenas de espacio vacío y una table rota en criterios comunes de auditoría de UI para búsqueda, filters, filas multilínea, descargas de la view actual y clasificación del riesgo de edición, en vez de corregir cada pantalla por separado.

Las tarjetas grandes y el espacio generoso arruinaron la pantalla

Estaba rediseñando una pantalla de gestión de vacaciones para empleados de oficina y administradores mayores de 50 años. Los requisitos pedían texto grande, áreas de interacción amplias y suficiente espacio. El prototipo interpretó esas palabras de la forma más simple y terrible posible.

Separó una cifra que cabía en una línea en tres —nombre del elemento → número grande → explicación auxiliar— y la colocó en una tarjeta enorme. Tres tarjetas ocuparon toda la primera pantalla, mientras que el trabajo que el usuario debía resolver en ese momento quedó desplazado hacia abajo. La pantalla de solicitud apiló calendar, resumen e inputs en grandes cajas blancas separadas; la table del historial dejó vacíos los valores esenciales y conservó solo los badges de estado. Incluso apareció scroll horizontal.

Cuando antes corregí una table y unos filters aplastados en un dispositivo mobile real, pensé que eliminar el overflow y los saltos rotos bastaba para mejorar la pantalla. Este prototipo mostró un problema más fundamental. Una pantalla que no se rompe y una pantalla que se puede usar son cosas completamente distintas.

Los criterios de auditoría de UI ya estaban rotos antes que la pantalla

El problema más grave era que esta pantalla había sobrevivido a un proceso de auditoría independiente.

La auditoría comprobaba si las routes se abrían, el texto se cortaba, los controls podían pulsarse y los colores o espacios estaban muy desalineados. Pero no obligaba a responder estas preguntas:

• ¿Puede el usuario encontrar en la primera pantalla el trabajo que debe resolver ahora?
• ¿Están reunidos en una sola view los valores necesarios para una misma decisión?
• ¿El espacio vacío explica la relación entre la información o solo rellena el tamaño del component?
• ¿La búsqueda, los filters, el orden, el recuento total y los resultados de una table forman un solo flujo?
• ¿Se puede descargar y reutilizar exactamente el resultado consultado?
• ¿Se distinguen los valores editables del historial que no debe sobrescribirse?

Si un problema no está en la auditoría, un Agent puede verlo y aun así aprobarlo. Por eso, en lugar de reducir el padding pantalla por pantalla, cambié primero los criterios comunes para que el mismo fallo no pudiera volver a pasar.

Collection reúne búsqueda, resultados y descarga

La referencia que más estudié fue la table de gestión de solicitudes de otra app de vacaciones. Su ayuda oficial también describe como una sola tarea la búsqueda por fecha, el filter de solicitudes y la aprobación o el rechazo en el modo de administrador web.¹ Lo que más llamaba la atención en la imagen de referencia no era la cantidad de funciones, sino la distancia entre ellas.

El período y el tipo de solicitud estaban justo encima de los resultados. Los campos de búsqueda se alineaban con sus columnas, y el número total de solicitudes y la descarga quedaban en la misma view. Los valores que debían leerse juntos —fechas, antes y después del cambio, diferencia de horas de trabajo— se agrupaban en varias líneas dentro de una cell en vez de añadir columnas sin límite. El estado y las actions disponibles continuaban en la misma fila.

Generalicé esa estructura como un contract común de collection, en vez de copiarla solo en una pantalla de vacaciones.

• Las tables, grids, listas densas y vistas de lista de calendar colocan el bloque search/filter justo encima de los resultados.
• Período y scope, búsqueda, filters rápidos, filters detallados, condiciones aplicadas, recuento total/actual, reset y descarga permanecen en la misma view.
• Los valores usados para la misma decisión se agrupan en cells multilínea como información principal → información secundaria → advertencia condicional.
• El contenido determina la altura de la fila. Usar varias líneas no justifica crear mini cards de altura fija.
• La descarga exporta todos los resultados que cumplen las condiciones actuales, no solo las filas visibles en la page actual.
• El export conserva el scope, período, búsqueda, filters, orden, hora de referencia y columnas de negocio visibles para el usuario.
• Los datos personales y materiales de auditoría no pierden la descarga por completo; aplican la misma autorización, masking y audit.

Comprobar solo que “hay un botón de descarga” volvería a fallar. También hay que comparar el recuento, filas representativas, filters aplicados, orden y masking de la pantalla real con el archivo descargado.

La forma de editar depende del riesgo de los datos

Corregir un valor directamente en una table es cómodo. Pero convertir todas las cells en Excel también permite sobrescribir aprobaciones, libros y pruebas legales como si fueran inputs comunes.

Por eso clasifiqué primero la naturaleza del cambio y después elegí el control de edición.

Naturaleza del cambio	Interaction predeterminada
Un valor reversible y de bajo riesgo	Inline edit con un affordance de edición visible
Cambios seguros repetidos en varias filas	Editable-grid mode explícito
Varios fields que requieren contexto cercano	Side panel que conserva la posición de la lista
Input o confirmación breve e independiente	Modal con un solo propósito
Cambio de alto riesgo, fecha de vigencia, autorización, versionado o append-only	Workflow independiente de preview-and-apply o correction

El double-click, Enter y F2 quedan solo como aceleradores para usuarios expertos. La entrada a la edición no se oculta únicamente detrás de ellos. Un grid necesita navegación con keyboard, indicación de cells modificadas, validation, undo, cancelación total, conflictos stale, preview antes de aplicar y readback después. La aprobación, el rechazo y los eventos de libro append-only no son objetivos de cell edit.

Separé las reglas comunes de auditoría del contract del producto

Si todo lo aprendido de la pantalla de referencia se escribiera como reglas exclusivas de Leave Operations, el siguiente project repetiría el mismo error. Pero si las etapas de aprobación, los documentos de promoción y las correcciones del libro de vacaciones entraran en un Skill común, el criterio compartido se convertiría en la especificación de un solo producto.

Por eso separé los límites.

Las reglas comunes y el Skill de auditoría de UI incluyen estos tipos de fallo:

• Convertir un scalar breve en una tarjeta independiente enorme
• Separar mecánicamente label, valor y denominador en tres líneas
• Alejar búsqueda y filters de los resultados
• Collection sin recuento total, reset ni descarga de la view actual
• Table que despliega valores relacionados en demasiadas columnas o fija la altura de filas multilínea
• Export cuya autorización o condiciones de la view actual difieren de la pantalla
• Edición oculta solo detrás de hover o double-click
• Sobrescritura de datos de alto riesgo, versioned o append-only mediante cells o popups comunes

La documentación de Leave Operations asigna esos principios por separado a cada page y view. Las tables de bandeja de aprobación, empleados, promoción, libro, conflictos de asistencia, resultados de mensajes y teléfono de trabajo reciben contracts de búsqueda, filter, orden y descarga. También separa las áreas que requieren cambios repetidos, como empleados y afiliación, de las aprobaciones y libros que no deben editarse directamente.

Las pantallas todavía no están corregidas

Este trabajo no mejoró la UI real del producto. Cambié las reglas comunes, el Skill específico de auditoría de UI y los contracts de pantalla de cada producto, y conservé la imagen de referencia junto con su hash original. Las pantallas desktop de Leave Operations todavía no están implementadas según esos contracts, y empleados de oficina y administradores mayores de 50 años aún no han terminado el trabajo por sí mismos desde la entrada normal.

Aun así, el siguiente prototipo no debería aprobarse por las mismas razones. El texto grande y las áreas de interacción suficientemente amplias siguen siendo requisitos, pero no deben convertirse en excusas para inflar la pantalla. El objetivo no es baja densidad de información, sino alta densidad de información con baja carga cognitiva.

Referencias

1. Centro de ayuda de Shiftee, Gestionar solicitudes. Describe el flujo del modo de administrador web para localizar solicitudes por intervalo de fechas y filter, aprobar o rechazar cada una y pasar a la siguiente. ↩