Plataforma de gestión de servicios
- Rol
- Product designer · UX/UI
- Cliente
- Empresa de señalización comercial en Los Ángeles, EE. UU.
- Usuarios
- Siete roles internos: administradores, managers, técnicos, diseñadores y más
- Plataformas
- Responsive: desktop, tablet y mobile
- Herramientas
- Figma, FigJam, Claude AI
- Estado
- Finalizado en 2026, diseño parcial
JG Signs es una empresa de señalización comercial en Los Ángeles. Atiende a empresas, instituciones educativas y marcas, y gestiona el ciclo completo de cada encargo: cotización, diagnóstico técnico, trámite de permisos, fabricación e instalación. El Capitan es su aplicativo interno: centraliza la operación de estimados, servicios y proyectos.
El sistema anterior cubría la operación básica, pero no respondía a los procesos reales de la empresa. No contemplaba todos los roles, no tenía estados ni fases, y buena parte de la coordinación ocurría fuera de la plataforma, en mensajes de texto y herramientas externas. El objetivo era reestructurar el producto para que la información fuera trazable, comprensible y útil para cada rol.
Trabajé directamente con el CEO, que aprobaba las decisiones de producto y actuaba como usuario de referencia: operaba el sistema a diario y conocía las tareas de todos los roles. Organizamos el trabajo en ciclos semanales de revisión, en los que presentaba cada pantalla, explicaba su comportamiento e iterábamos sobre los puntos que generaban dudas.
Las sesiones quedaban grabadas y transcritas. Las analizaba para identificar puntos de dolor, priorizar requerimientos y anticipar cambios de alcance.
- Registros sin trazabilidad. Los proyectos detenidos por trámites legales quedaban relegados en el listado y se duplicaban al retomarse.
- Sin estados ni fases. La documentación de cada encargo se acumulaba sin estructura y su clasificación dependía del criterio del manager.
- Asignación informal de recursos. Equipos, vehículos y herramientas se coordinaban por mensaje de texto, y las tareas no registraban responsable, fecha ni fase.
- Permisos sin definir. Había roles con accesos que no les correspondían y no existían perfiles de empleado, cliente ni empresa.
- Operación fragmentada. Finanzas, inventario, nómina y control de tiempos dependían de plataformas externas.
Prioricé el rol administrador porque concentra todos los permisos y funciones del sistema: gestiona usuarios, cuentas y permisos, aprueba solicitudes, crea registros y asigna equipos.
Sus necesidades principales eran dos. Primero, conocer de forma inmediata el estado de cada registro: cliente, responsable, personal asignado y etapa. Segundo, tener visibilidad financiera de la operación sin depender del área contable.
La auditoría de los flujos existentes evidenció tres problemas con impacto directo en la operación, el personal y el flujo de caja:
- Arquitectura de informaciónUn mismo flujo agrupaba procesos distintos: estimados, proyectos, servicios, inventario y finanzas.
- Estados del sistemaLos registros no tenían estados. No era posible saber si un encargo estaba activo, detenido, olvidado o pendiente de documentación.
- Comunicación con el usuarioLos mensajes del sistema eran genéricos y no indicaban la causa de un error ni el siguiente paso.
- Arquitectura de 13 módulosEvalué conservar los 11 módulos existentes, pero varios combinaban información de procesos distintos, que era el origen del desorden. Reestructuré la arquitectura en 13 módulos con flujos y subflujos definidos, para separar funcionalidades sin aumentar la carga cognitiva ni la longitud de los flujos.
- Un modelo de estados desde ceroDiseñé un sistema de estados para el ciclo completo de cada registro, incluidos los casos críticos: registros inactivos que requieren atención, reaperturas por control de calidad o documentación y reanudaciones con requisitos pendientes.
- Flujo global a partir del administradorDiseñar cada rol por separado aumentaba tiempos y costos. Propuse construir primero el flujo del administrador, que reúne todas las funciones actuales y previstas, y derivar de él las vistas, permisos y subflujos de managers y técnicos. Así se redujo el alcance inicial y quedó una base escalable.
- UX writing orientado a la acciónConservé la estructura de mensajes que el equipo ya conocía para no romper sus hábitos de uso, y reescribí el contenido para que cada mensaje indique qué ocurrió y cómo resolverlo. Incorporé alertas específicas por tipo de error y confirmaciones antes de acciones destructivas.
- Responsive en tres tamañosEl Capitan se diseñó como un producto responsive desde el inicio, con tres tamaños de referencia: desktop, tablet y mobile. Cada flujo define cómo se reorganiza la información en cada tamaño según el contexto de uso: la gestión completa en desktop y la consulta y actualización en campo desde tablet y mobile.
- Design system como base del productoEl inventario de componentes mostró un volumen alto que requería rediseño completo. Propuse construir un design system desde el inicio, estructurado con Atomic Design, tokens, variables y una nomenclatura compartida con desarrollo. Hoy reúne más de 100 componentes.
- Rediseño visual integralEl alcance incluyó también la capa visual. Partí de la pantalla base que comparten estimados, servicios y proyectos, presenté tres propuestas de interfaz y la dirección elegida se consolidó a lo largo de las revisiones semanales.
Cada flujo se validaba con el cliente mediante prototipos en Figma con las interacciones principales: acciones, navegación entre secciones y modales. Los hallazgos de cada revisión se incorporaban antes del traspaso a desarrollo, incluidos ajustes a procesos legales y documentales.
La iteración más significativa fue simplificar las fases de un proyecto de siete a cuatro. Fusioné etapas con un mismo objetivo operativo, como el abastecimiento de materiales y la producción, e integré la gestión de suministros dentro de la fase, con la opción de comprar o asignar desde inventario. El resultado fue un proceso con menos pasos y un objetivo claro por fase.
Con el mismo criterio reduje las vistas iniciales de estimados, proyectos y servicios, y amplié los subflujos donde la operación lo requería: solicitudes, equipos, comunicación y planos dentro de cada fase.
Cuando una solicitud del cliente entraba en conflicto con la usabilidad o el rendimiento, evaluaba el costo de cada opción y proponía una alternativa que respondiera a ambas necesidades.
- Ubicación del proyecto. El cliente requería un mapa integrado en el flujo. Mi recomendación era un acceso a un servicio de mapas externo, para evitar carga adicional y desplazamiento innecesario. La solución fue adaptativa: un bloque tipo bento en desktop, el mapa bajo el contenido en tablet y un acceso directo en mobile.
- Información financiera por registro. La propuesta inicial duplicaba datos ya disponibles en el módulo de finanzas. Definimos que cada registro mostrara solo sus propios movimientos, para ir de lo particular a lo general sin redundancia.
- Gestión de tareasUn tablero por proyecto reemplaza la asignación por mensaje de texto. Cada tarea tiene responsable, fecha y estado, y el manager tiene visibilidad de cada cambio.
- Comunicación por proyectoUn chat reúne a las personas involucradas en cada proyecto y deja registro de las decisiones, en lugar de escalar cada incidencia por llamadas.
- Fases y documentaciónCada documento, plano y solicitud se asocia a su fase, y los documentos obligatorios son requisito para avanzar o cerrar un proceso.
Rediseñé seis flujos completos: estimados, servicios, proyectos, inventario, vehículos y finanzas. El flujo del administrador quedó definido en un 70% y sirve de base para derivar los demás roles. Desarrollo implementó estimados, proyectos, servicios e inventario a partir de este diseño. Los flujos seguían en evolución al cierre del proyecto, por lo que no se consideran cerrados.
La retroalimentación del cliente destacó una plataforma más clara y simple a pesar de las nuevas funcionalidades, una interfaz limpia y comprensible, y propuestas que equilibraban las necesidades del usuario y del negocio.
A mitad del proyecto, el cliente y desarrollo decidieron migrar el design system a Claude. La herramienta no interpretaba correctamente varios componentes ni su estructura de capas, lo que exigió renombrar y auditar la librería completa para alinear Figma con el nuevo entorno. El proceso retrasó la entrega, pero me llevó a integrar la IA en mi flujo de trabajo: en la etapa final usé Claude AI para documentar, analizar y auditar el design system.
El proyecto también reforzó una práctica: evaluar cada decisión desde el negocio y desde cada rol que opera la herramienta, no solo desde el diseño.
- Documentar el design system desde el inicio del proyecto.
- Incorporar IA desde las primeras etapas para generar pantallas, auditar flujos y detectar inconsistencias antes.
- Apoyarme en ella para estructurar soluciones a problemas complejos en menos tiempo.
Proyecto bajo contrato de confidencialidad.