Una herramienta de autoservicio que nadie utilizaba.
Imperial CFS gestiona miles de contenedores que transitan por el Puerto de Los Ángeles cada mes. Sus clientes (importadores, transitarios y agentes de aduanas) deben realizar tres acciones constantemente: comprobar si su carga ha llegado y ha pasado la aduana, consultar los gastos de almacenamiento pendientes y pagarlos para liberar su envío.
El portal para realizar esta tarea ya existía. Sin embargo, la interfaz era un sistema heredado con muchas tablas que abrumaba a los usuarios con datos sin procesar y sin una jerarquía clara. En lugar de lidiar con él, los clientes optaban por llamar al servicio de atención al cliente. El costo operativo de esta solución alternativa —tiempo del personal, tiempos de espera, tasas de error— era el verdadero problema que nos contrataron para resolver.
El encargo era claro: rediseñar el portal para que los clientes pudieran rastrear la carga y procesar los pagos por sí mismos, sin necesidad de llamar a nadie. Cada decisión de diseño se evaluó en función de ese objetivo.
Tareas complejas completadas en 4 clics o menos.
El panel de disponibilidad rediseñado permite consultar la disponibilidad de la carga, revisar su estado (Pagado/Pendiente/Retenido) e iniciar el pago, todo ello sin salir de la página ni llamar al servicio de asistencia.
¿Cómo lo abordé?
El trabajo comenzó con la investigación, no con los wireframes. Saltarse ese paso es la razón por la que fracasan la mayoría de los rediseños de portales.
1. Investigación de usuarios y mapeo de puntos débiles
Mediante análisis asistidos por IA y la investigación directa, trazamos un mapa de los recorridos típicos de los usuarios, tanto transitarios como importadores, que interactúan con los sistemas de carga. Los patrones fueron consistentes: los usuarios llegaban con una tarea específica en mente (revisar un contenedor, pagar una factura), pero la interfaz les presentaba tablas de datos sin filtrar y los obligaba a revisar decenas de filas para encontrar lo que necesitaban.
Cree perfiles de usuario que representaban a los tres tipos principales de usuarios: el importador que revisa su propia carga a gran detalle, el agente de aduanas que gestiona múltiples envíos de clientes y el agente en tierra que revisa la logística del transporte hasta que llega a su destino en tierra.
Sus flujos de trabajo y prioridades diferían significativamente, y la interfaz original no se adaptaba bien a ninguno de los tres.
2. Flujos de UX y reducción de la carga cognitiva
Diseñamos recorridos de usuario revisados, centrados en minimizar los pasos y eliminar las decisiones que el sistema debería tomar por el usuario. El principio fundamental: un usuario que llega conociendo el número de su contenedor no debería tener que pensar en qué hacer a continuación; la interfaz debería mostrarle su carga específica de inmediato y explicarle exactamente qué acciones tiene disponibles.
Los estados fueron una decisión clave en el diseño. “Disponible”, “Pendiente”, “En espera”, “Pagado”: cada uno debía ser visualmente distinto y fácil de identificar, especialmente para los intermediarios que gestionan más de 20 contenedores simultáneamente. Utilizamos colores, iconos y una jerarquía de información para que el estado fuera legible de un vistazo, sin que el usuario tuviera que leer cada fila.
3. Prototipos de Figma: diseñados y defendidos en inglés.
Cada decisión de diseño se validó mediante prototipos de alta fidelidad creados con Figma y presentados directamente al equipo de Imperial CFS en California a través de videollamada.
Trabajando en inglés y a través de diferentes zonas horarias, juntos analizamos la lógica de la experiencia de usuario, negociamos prioridades cuando los requisitos comerciales entraban en conflicto con las mejores prácticas de UX y llegamos a acuerdos de implementación claros antes de escribir una sola línea de código HTML.
Esta es la parte que la mayoría de los proyectos offshore omiten: la conversación directa y sustancial con el cliente sobre por qué se tomaron ciertas decisiones de diseño y cuáles son las ventajas y desventajas.
4. Desarrollo de frontend y handoff
El handoff era casi diario, en un repositorio de Github donde los desarrolladores de Imperial CFS y yo teníamos comunicación constante. El resultado fue un código listo para producción desde el primer sprint: desarrollado en HTML, CSS y JavaScript puro, con Bootstrap como base de componentes. Se eligió esta pila tecnológica para que coincidiera con la infraestructura de backend existente y garantizara que el equipo de desarrollo pudiera integrar la nueva interfaz sin necesidad de migrar el framework.
El panel de disponibilidad (Availability Search) fue el entregable más complejo desde el punto de vista técnico: utiliza menús desplegables, paneles tipo acordeón y casillas de verificación contextuales para presentar datos logísticos densos sin abrumar al usuario.
El flujo de pago se rediseñó como una experiencia de varios pasos en una sola página, eliminando las recargas de página que interrumpían la experiencia del usuario durante el proceso de compra.
