Un ERP de veintidós años que nadie quería tocar.
De un sistema de escritorio heredado a una interfaz web moderna, documentada y replicable: 14 tipos de pantalla rediseñados, un sistema de diseño de 12 capítulos y un prototipo interactivo de 103 vistas entregado en código Angular.
- Cliente
- INASSA — Dirección UX
- Producto
- Amerika, de Amerika Tecnología y Servicios S.A.S.
- Rol
- Consultor UX/UI · investigación, interacción, dirección de arte y sistema de diseño
- Periodo
- Febrero 2019 – Enero 2020
- Alcance
- 14 tipos de pantalla: específicas y plantillas replicables
- Herramientas
- Adobe XD, Illustrator, Angular, Git, Firebase
- Entregables
- Prototipo, maquetas en repositorio, Guía de Diseño, iconset, inventario de componentes, 7 actas
- Alcance geográfico
- Siete países de Latinoamérica
El contexto
Amerika es una solución integral de software para empresas del sector público: módulos contable, comercial y de gestión de indicadores. Creada en Colombia en 1997 e implantada en siete países, es el sistema con el que operan a diario las empresas de acueducto y alcantarillado: facturación, recaudo, órdenes de trabajo, convenios de pago, suspensiones y reconexiones, PQRs.
Después de dos décadas de crecimiento por acumulación, la interfaz era la de una aplicación de escritorio de los años noventa: ventanas modales apiladas, formularios de decenas de campos sin jerarquía, iconografía críptica y procesos que obligaban a saltar entre cuatro o cinco pantallas para completar una sola tarea.
INASSA decidió migrar la plataforma a Java y Angular. Esa migración abrió la ventana para rehacer la capa de interfaz — no como maquillaje, sino como rediseño de la interacción.
El reto
La densidad de datos era el requisito, no el problema. El trabajo no era simplificar quitando información: era organizarla.
- No se podía romper la operación. Usuarios con años de memoria muscular sobre el sistema viejo. Cualquier reorganización tenía que ganarse su lugar.
- No se podía rediseñar pantalla por pantalla. El catálogo de vistas es extenso y el presupuesto no daba para recorrerlo.
- Dos perfiles opuestos compartían las mismas pantallas.
Clara De la Fuente — analista senior con gente a cargo. Usa el sistema de forma frecuente pero breve. Necesita una vista panóptica.
Alesio De los Ríos — analista junior. Carga datos varias veces al día. Necesita filtros configurables y mínima fricción por interacción.
Clara quiere ver menos y entender más. Alesio quiere manipular más y navegar menos. Esa tensión fue el motor de casi todas las decisiones.
Decisiones de diseño
Acceso y marco de trabajo
El login y el frameset eran la decisión más apalancada: se replican en todas las pantallas. Se eliminaron los pasos intermedios del ingreso, y el menú lateral se resolvió fluido y no superpuesto — al desplegarse empuja el contenido en lugar de taparlo, para maximizar el tiempo de manipulación de datos.
Se sumaron un mecanismo de pin para fijar las opciones más usadas, búsqueda en tres niveles y skeleton loading en lugar de spinner, pensando en conexiones lentas.
Planificación y asignación de trabajos
El problema: asignar una orden de trabajo obligaba a recorrer cuatro vistas auxiliares.
La decisión: sintetizar el proceso en una sola interfaz, con lista de contratistas integrada y pre-filtrada, super-filtros por estado en tarjetas, consolidado gráfico y filtros inteligentes en dos momentos — los que se cruzan sobre la base de datos y los que operan sobre el conjunto ya cargado. Esa distinción es exactamente la que separaba a Clara de Alesio.
Gestión de inmuebles con deuda
El problema: veinte grupos de filtros —todos necesarios— repartidos entre cinco vistas.
La decisión: centralizar la interacción. Barra de acciones pegada al área de filtros para minimizar el desplazamiento del puntero, menú desplegable en lugar de ventana emergente, vista general de filtros en gran formato pensada también para pantallas táctiles, y perfilado por rol: cinco a siete filtros en pantalla, el resto disponible pero no impuesto.
Ingreso de resultados
La usan digitadores que transcriben reportes de cuadrillas en campo. Aquí el usuario es Alesio en estado puro y la métrica es una sola: interacciones por registro.
La interfaz se diseñó alrededor del teclado numérico, con control total del desplazamiento entre campos y en la secuencia exacta en que llegan los datos del formulario de campo.
Mantenimiento de convenios
El problema: al negociar un convenio de pago en ventanilla —con el cliente presente— el asesor tenía que invocar otra pantalla para ver el comportamiento de pago histórico.
La decisión: integrar facturas pendientes y conceptos en la vista principal, ordenando la lectura según la secuencia lógica de consumo de datos durante la conversación con el cliente.
Plantillas, no pantallas
Nueve de los catorce entregables no eran pantallas: eran plantillas.
Planificación y asignación, búsqueda por filtros e ingreso de información, multirregistro, parametrización, generación de reportes simple y compleja, ejecución de procesos, manejo de archivos y variables de cartas. Solo cuatro fueron pantallas específicas: login, panel de control, inmuebles con deuda y PQRs.
Diseñarlas como plantilla —y no como pantalla— fue lo que permitió que el rediseño escalara más allá del presupuesto.
El sistema de diseño
La Guía de Diseño no se escribió al principio: se destiló a medida que se resolvían las pantallas. La lógica quedó explícita desde el acta 05 — a mayor porcentaje de pantallas procesadas, más definidos los elementos; solo con más del 80 % del alcance resuelto tenía sentido cerrar la caracterización del estilo.
Doce capítulos: tipografía, color, iconografía y componentes, más un iconset propio y el inventario de componentes.
Resultados
Catorce tipos de pantalla rediseñados —específicas y plantillas— cubriendo login, panel de control, planificación y asignación, gestión de cartera, búsqueda y captura, parametrización, reportes, procesos, archivos, cartas y PQRs. Los convenios de pago pasaron de dos vistas a una.
Aprendizajes
El acta es una herramienta de diseño. Siete documentos con decisiones y compromisos fechados hicieron más por la continuidad del proyecto que cualquier herramienta de gestión.
En un cliente corporativo con varias direcciones involucradas, escribir lo acordado es la única forma de que lo acordado sobreviva. Convirtió opiniones en decisiones trazables y evitó rediseñar dos veces lo mismo.
Y el sistema de diseño se destila, no se decreta. Cerrarlo antes de tiempo habría producido un documento bonito que nadie podía aplicar.
¿Tienes un sistema heredado que nadie quiere tocar? Hablemos