Sistema interno: del relevamiento al sistema de diseño

Es un sistema de escritorio que el personal usa todos los días para administrar información y ejecutar operaciones internas. No lo usa una persona: lo usan siete perfiles con permisos, responsabilidades y rutinas muy distintas entre sí.

Ahí está la dificultad central del proyecto. Los siete entran por la misma puerta pero necesitan ver cosas diferentes, y en un entorno regulado un permiso mal asignado no es una molestia de usabilidad: es un riesgo operativo. Todo lo que se diseñó después tuvo que responder a esa restricción.

A eso se sumaba lo que le pasa a cualquier sistema que creció por capas durante años: módulos agregados en momentos distintos, con criterios distintos, y ninguna definición común de cómo debía comportarse una pantalla. Antes de rediseñar nada había que entender qué existía y por qué.

La primera etapa no produjo ni una pantalla. Se fue entera en entender el sistema tal como era y cómo lo usaba cada perfil: sesiones con referentes de cada área, observación de la operación real y una revisión de la plataforma existente pantalla por pantalla. De ahí salieron cuatro entregables:

• Siete user personas, una por perfil, con sus objetivos, sus frustraciones y su rutina real de trabajo —no la que decía el manual
• Mapa de sitio de la plataforma existente, que sirvió para ver la duplicación y los caminos muertos
• Matriz de roles y permisos: una grilla de perfil por acción, con tres estados posibles —permitido, denegado y condicionado— que se convirtió en la fuente de verdad del proyecto
• Journey map y un backlog de oportunidades de mejora, priorizado por impacto y esfuerzo junto con el equipo

Las frustraciones que se repetían marcaron el rumbo de todo lo que vino después: «si me equivoco en los permisos, puedo habilitar cosas que no corresponden», «necesito que el sistema me avise si algo está mal antes de enviarlo», «quiero ver la información sin tener que hacer tantos clics».

Esos tres reclamos se tradujeron en tres criterios de diseño —permisos explícitos, validación temprana y menos pasos por tarea— que después sirvieron para decidir cada vez que hubo dudas.

Con el relevamiento hecho, dibujé toda la plataforma en baja fidelidad antes de tocar un solo color. Trabajar en gris obliga a discutir lo que importa: qué información necesita ver quien decide, en qué orden, y qué pasa cuando algo sale mal.

La decisión que ordenó esta etapa fue no empezar por las pantallas sino por los patrones. En lugar de resolver cada módulo por separado, definí un puñado de estructuras reutilizables —listado, detalle, formulario, confirmación, estado vacío y error— y después cada pantalla se armó eligiendo entre ellas. Eso hizo que módulos hechos con meses de diferencia se comporten igual, y que sumar uno nuevo no sea empezar de cero.

Cada flujo se dibujó completo, con sus estados de carga, vacío, error de validación y confirmación conectados entre sí, para que se pudiera recorrer de punta a punta y no quedaran caminos sin resolver. Todo sobre una grilla y una escala de espaciado comunes, las mismas que después se convirtieron en los tokens del design system.

Ese comentario que se escribe al confirmar es el que después se lee en el historial, junto al responsable y la fecha. Resuelve una necesidad concreta que apareció en el relevamiento: poder reconstruir por qué un registro terminó como terminó. En un entorno auditado esa trazabilidad no es un lujo de diseño, es parte del requerimiento.

Con esos cinco patrones quedaron cubiertos los problemas que aparecían una y otra vez en el relevamiento: encontrar un registro entre miles, operar sobre varios a la vez y confirmar antes de una acción irreversible. Faltaba el cuarto, que no es una tarea sino una pregunta: cómo está todo hoy.

Con tantas pantallas y varias personas construyendo, la consistencia no se sostiene con buena voluntad. Armé un design system en dos capas: los fundamentos —color, tipografía, espaciado e iconografía— y sobre ellos las familias de componentes, cada una con sus variantes, sus estados y la nota de cuándo corresponde usarla.

Está armado en Figma con auto-layout y variantes, y los nombres se acordaron con desarrollo: una pantalla nueva se arma combinando piezas ya resueltas, y el handoff no necesita traducción.

La última etapa fue llevar todo a un prototipo de alta fidelidad que se pudiera recorrer de punta a punta, con los estados de error y de éxito conectados. No una secuencia de pantallas lindas: un archivo que se puede usar, en el que alguien intenta hacer su tarea y se choca —o no— con los mismos obstáculos que tendría en el sistema real.

Eso permitió validar antes de construir. Cada ronda de revisión con los perfiles y con desarrollo dejaba una lista de ajustes que volvía al archivo, y el prototipo se versionó como V1 y V2 para poder comparar decisiones en vez de discutirlas de memoria. La segunda versión existe porque la primera se probó.

Una de las mejoras que salió del relevamiento fueron las acciones en lote: poder resolver varios registros a la vez en lugar de uno por uno. Parece un detalle de interfaz, pero para quien procesa decenas por día cambia la jornada. Y obligó a repensar el patrón de confirmación, porque confirmar una acción no es lo mismo que confirmar treinta.

El prototipo también fue la herramienta de handoff: desarrollo entra al mismo archivo, recorre el flujo, ve los estados y saca las medidas de los componentes ya documentados.

Un año en el mismo sistema enseña algo que un proyecto corto no: que el trabajo no termina en la entrega. Los patrones aguantan o no aguantan cuando aparece el caso que nadie previó, y el design system sirve o estorba según qué tan fácil sea sumarle una pieza nueva.

Lo que más me sirvió fue haber empezado por la investigación aunque no produjera pantallas. Cada decisión discutible después tuvo dónde apoyarse: no era mi preferencia contra la de otro, era lo que había dicho la gente que usa el sistema todos los días.