Nuevas normas nacionales cambiaron cómo debía medirse, calcularse y reportarse la distribución de hidrocarburos. Para la empresa energética paraestatal más grande de México, eso significó software hecho a la medida: cuatro productos de escritorio especializados para toda la cadena de cálculo. Lideré al equipo de UX en los cuatro, y fui responsable end to end del producto de reportes ejecutivos.
México introdujo nuevas reglas nacionales sobre cómo se distribuyen los hidrocarburos y cómo se calcula esa distribución. Para la empresa energética paraestatal más grande del país, cumplir no era un ejercicio de reportería: cambiaba la matemática operativa de fondo, y las herramientas existentes no podían producirla.
Lo que el negocio necesitaba no era un dashboard. Necesitaba software capaz de sostener toda la cadena de cálculo (nominaciones, existencias físicas, rangos operativos, capacidades de transporte, validación, balances y reportes) con la precisión suficiente para que los números resistieran a un regulador, y con la claridad suficiente para que un ejecutivo de logística pudiera actuar sobre ellos.
Cada etapa alimenta a la siguiente. Una decisión de redondeo en la nominación aparece como discrepancia en el balance, que es exactamente por lo que los productos tenían que diseñarse como familia y no como herramientas sueltas.
Cada producto atendía un tramo de la cadena, pero compartían un modelo de navegación, un lenguaje de datos y un patrón de interacción para el trabajo tabular denso, así que un ingeniero que se movía entre ellos no tenía que reaprender nada.
El núcleo operativo: captura de nominaciones, seguimiento de existencias físicas en baterías y tanques, definición y validación de rangos operativos y capacidades de transporte, y reconciliación de balances, todo con la precisión que exigía la nueva norma.
Un visualizador de reportes para los ejecutivos de logística de hidrocarburos. Fui responsable de este producto de principio a fin, incluyendo el análisis de la información y el trabajo de bases de datos detrás de qué podía mostrar y con qué rapidez.
No eran productos web con espacio para respirar. Eran aplicaciones de escritorio dentro del entorno de una empresa paraestatal, y varias decisiones de diseño las dictaron las restricciones y no la preferencia.
Las restricciones de aplicación de escritorio definieron qué era posible en layout, interacción y renderizado; el diseño tenía que funcionar dentro de ellas, no rodearlas.
Operar dentro del entorno de una empresa paraestatal implicaba reglas de seguridad que limitaban cómo podían moverse, exportarse y mostrarse los datos.
Volúmenes, densidades, grados API, azufre, salinidad, presión y temperatura: cada campo cargaba peso operativo y normativo. Ningún campo era decorativo.
Los especialistas necesitaban ver muchas filas a la vez. Simplificar escondiendo datos habría hecho los productos más lentos de usar, no más fáciles.
Cuatro productos contra una fecha normativa no podían diseñarse en paralelo con un equipo pequeño. Los trabajamos por etapas: construir, validar y entregar uno antes de abrir el siguiente, para que cada producto heredara lo que el anterior ya había comprobado.
Pasé años trabajando directamente con los ingenieros especialistas del cliente. En un dominio así de técnico, los requerimientos no se entregan en un documento: el diseño tenía que construirse desde su conocimiento real de cómo se miden y se mueven los hidrocarburos.
Cada etapa corrió el ciclo de Lean UX con los especialistas como usuarios validadores: supuestos explícitos, diseños probados contra casos operativos reales, y correcciones incorporadas antes de arrancar el siguiente producto.
Cada problema resuelto (densidad de tablas, retroalimentación de validación, navegación entre módulos) se volvió un patrón desde el cual arrancaba el siguiente producto. Trabajar por etapas convirtió la secuencia en ventaja en vez de retraso.
Lideré al equipo de UX en los cuatro productos, manteniendo consistente el lenguaje compartido mientras cada diseñador profundizaba en su propio tramo de la cadena.
El lenguaje visual se mantuvo deliberadamente callado: un rail de módulos permanente, una barra de acciones fija, un selector de periodo, y tarjetas que agrupan tablas por ubicación o por etapa, para que la atención se quede en los números.

El rail de módulos a la izquierda, el selector de periodo arriba, y un centro de notificaciones que expone lo que requiere atención, con la acción de exportación al sistema logístico del operador en la parte superior derecha.

Registros de encabezado arriba, detalle línea por línea abajo: punto de recepción, cantidad recibida, contenido de agua, grados API, azufre, salinidad, presión y temperatura. Los valores fuera de rango se marcan en la celda misma, donde ocurre la corrección.

Inventario de tanques agrupado en tarjetas por ubicación, cada una con volúmenes bruto, neto y colchón: comparables de un vistazo, editables en su lugar, y escaneables sin recorrer una sola tabla monolítica.
Este proyecto me enseñó que en un dominio técnico la credibilidad del diseño se gana con colaboración, no se asume. No puedes simplificar un cálculo que no entiendes. Trabajar codo a codo con los expertos en la materia, no sólo entrevistarlos, es lo que hizo que los diseños se sostuvieran, y es la razón por la que sigo tratando esa colaboración como el primer paso.