Parq.ai

Las operaciones de flota empresariales rara vez siguen un único conjunto universal de reglas. Cada cliente opera con distintas ubicaciones, proveedores, acuerdos de servicio y condiciones operativas. Conforme Parq.ai crecía, el producto debía soportar esa variabilidad sin fragmentarse ni volverse imposible de operar.

El reto no era diseñar más pantallas. Era hacer comprensible una lógica de negocio compleja.

Trabajé de cerca con el Product Owner, Operaciones e Ingeniería para traducir los requerimientos de negocio y de cliente en experiencias de producto utilizables.

Los requerimientos llegaban normalmente mediante sesiones de trabajo, documentos, videos y contexto operativo recopilado por el Product Owner con stakeholders de negocio, clientes y equipos internos de Operaciones. Mi responsabilidad era entender el problema, estructurar la información, explorar modelos de interacción, diseñar la experiencia en Figma e iterar con Producto hasta dejarla lista para desarrollo.

El equipo operaba en ciclos semanales rápidos. Las primeras soluciones se desarrollaban a menudo en dos o tres días, dejando el resto del ciclo para retroalimentación y refinamiento.

Algunos problemas de diseño no podían resolverse entendiendo solo la interfaz. Las operaciones de flota estaban ligadas a espacios físicos, al movimiento de vehículos y a la capacidad de los lotes.

Para la iniciativa de Site Plans estructuré mapas infográficos de lotes con medidas aproximadas para representar áreas de estacionamiento, carriles y zonas operativas. Eso conectó el producto digital con el entorno físico donde las personas realmente trabajaban.

El producto reunía Fleet Management, Workflows, órdenes de trabajo, tickets, cargas y transporte, lotes, proveedores, SLAs, precios, Readiness, automatizaciones y administración alrededor del activo y su historial operativo.

El objetivo no era exponer la arquitectura al usuario, sino preservar el contexto suficiente para operar con confianza a través de ella.

La información operativa de un mismo activo podía existir en distintos objetos y procesos. Las personas necesitaban entender no solo cada registro, sino cómo se relacionaban tickets, órdenes de trabajo y activos a lo largo de un proceso operativo.

Exploré formas de hacer explícitas esas relaciones y de mantener el contexto al moverse entre registros operativos.

Operaciones no podía depender de revisar manualmente grandes colas de órdenes de trabajo para detectar cada problema que requería atención.

El Exception Engine evaluaba condiciones de las órdenes de trabajo, identificaba umbrales y generaba tickets accionables con una ruta ordenada de responsabilidad.

Los estados dentro del umbral, cercanos al umbral e incumplidos comunicaban urgencia mediante verde, amarillo y rojo. Los disparadores configurables cubrían situaciones como órdenes sin asignar, detenidas, envejecidas o incompletas, y la secuencia de responsabilidad dejaba claro quién debía actuar ante una excepción.

Asset Readiness dependía de lógica específica por cliente que Operaciones no podía ver ni modificar sin Ingeniería. La dirección de diseño expresó esa lógica como una regla en lenguaje natural.

La experiencia contemplaba múltiples condiciones, estados de advertencia opcionales, conflictos, anulaciones manuales, reglas migradas y validación sin pedirle a quien administra que piense como programador.

Antes, responder esa pregunta exigía recorrer la base de precios, identificar la actividad y el proveedor, abrir el SLA, encontrar el margen y calcular el precio final a mano.

El producto soportaba tres perspectivas —cliente, lote y actividad— y dos modelos mentales de precio: calcular el precio al cliente desde el costo del proveedor y el margen, o partir del precio al cliente hacia el costo interno.

Las personas usuarias no necesitaban más datos, sino el contexto suficiente para identificar dónde hacía falta atención y qué acción debía seguir.

La salud del proveedor, el tiempo de respuesta, la tasa de retrabajo, el cumplimiento de SLA, el tiempo fuera de servicio, las tendencias de costo y las comparaciones entre proveedores ayudaban a convertir los datos de desempeño en decisiones operativas.

Conforme el producto evolucionó, el sistema debía contemplar multi-tenancy, propiedad distribuida, alianzas, acceso entre clientes, activos compartidos, permisos, posesión, SLAs y trazas de auditoría.

Eso amplió el problema de diseño desde flujos individuales hacia los cimientos de una plataforma SaaS empresarial configurable.

Conforme la plataforma se expandió entre módulos y casos de uso, la consistencia se volvió un problema de producto en sí mismo.

Desarrollé y mantuve patrones de interfaz reutilizables —tablas, filtros, tarjetas, insignias, estados, navegación, formularios, campos, modales, estados vacíos, alertas y pestañas— para reducir la reinvención, mejorar la previsibilidad y acelerar la entrega. El sistema de diseño cubrió 7+ áreas centrales del producto.

El diseño no se trataba como entregable final. Las soluciones pasaban por retroalimentación de Producto, refinamiento e implementación, con ajustes adicionales conforme cambiaban las necesidades operativas.

Parq.ai me enseñó que diseñar productos empresariales suele tratarse menos de simplificar el negocio y más de crear interfaces que permitan operar esa complejidad con confianza.

Las interfaces simples no provienen necesariamente de sistemas simples.

Parte del trabajo de diseño más importante en Parq.ai consistió en entender relaciones, reglas, excepciones, permisos y restricciones operativas que las personas nunca deberían interpretar como complejidad técnica. Mi rol fue preservar esa capacidad y a la vez hacer el sistema comprensible para operarlo.