Consultora de ingeniería energética · Plataforma de planificación eléctrica

Modelar un sistema eléctrico entero sin perder de vista dónde estás

Rediseño de PowerModel, la plataforma con la que un equipo de planificación construye, ejecuta y compara modelos de expansión de generación: diez secciones de parámetros, un solver que tarda horas y siete escenarios que hay que poder mirar juntos.

UX/UI Design
Arquitectura de información
Herramientas de datos
Sistema de diseño

Pantalla de resultados de PowerModel con la gráfica de capacidad instalada por tecnología

Visualize Results, pestaña Capacity: capacidad instalada por tecnología de 2024 a 2030, con la cuota renovable sobre el eje secundario y ocho series comparables entre escenarios.

Mi rol: Senior Product Designer y único diseñador del producto. Auditoría de la versión existente, arquitectura de información, flujos, sistema de componentes, pantallas con todos sus estados y guía de handoff.
Equipo: Un product owner, dos ingenieros de sistemas eléctricos como expertos de dominio, cinco desarrolladores (Python en el motor, front web) y un data engineer a cargo del solver.
Duración: 22 semanas (feb – jul 2022) en cuatro entregas: auditoría y árbol de navegación, patrón maestro y componentes, las diez secciones del modelo, y ejecución, resultados y handoff.
Plataforma: Aplicación web de escritorio para uso interno del equipo de planificación. Rejilla de 1280 px. Sin versión móvil ni tableta en el alcance.
Usuarios: Tres perfiles: el modelador, que parametriza y lanza ejecuciones; el analista, que lee y compara resultados; y el responsable de datos, que administra bases de datos y proyectos.
Alcance: 3 pestañas de primer nivel, 10 secciones de modelo en un menú de tres niveles, 63 tablas de parámetros, 5 estados de ejecución, 5 familias de gráficas y unos 60 componentes con sus estados.

01 — El desafío

El cuello de botella no era el cálculo, era llegar hasta él

El cliente planifica la expansión del sistema eléctrico de grandes regiones: cuánta capacidad de solar, eólica, almacenamiento o ciclo combinado hay que construir cada año hasta 2070, con qué interconexiones y bajo qué límite de emisiones. El motor de optimización ya existía y funcionaba bien. Lo que no existía era una forma razonable de alimentarlo.

Un modelo completo son diez bloques de parámetros, sesenta y tres tablas y series anuales por geografía. Se preparaba a mano, entre ficheros CSV y scripts de Python, y se lanzaba desde consola. Solo tres personas de la casa sabían hacerlo entero. Y como una ejecución tarda entre cuarenta minutos y seis horas, un valor fuera de rango no se descubría al escribirlo: se descubría a media tarde, cuando el proceso moría.

Encima, la plataforma vivía un cambio de motor. Las bases de datos del sistema antiguo y las del nuevo, MPM v2.0, tienen estructuras distintas, así que en algunas hay secciones que sencillamente no se pueden tocar. Ese producto a medio migrar era el punto de partida real, no un escenario ideal.

−78 % de runs abortados

por parámetros inválidos, al validar el rango en el propio campo en lugar de descubrirlo cuando el solver ya llevaba horas corriendo.

El objetivo de negocio

Que montar y lanzar un modelo deje de depender de tres personas concretas.
Que un error de dato se vea al escribirlo, no seis horas después.
Que los resultados se comparen entre escenarios sin exportar nada a Excel.
Que la migración de motor sea explícita en la interfaz y no una sorpresa.

02 — Restricciones y alcance

Un producto heredado, dos motores y un solver que manda

Este no era un producto nuevo. Era una plataforma en uso, con una base de código construida, un motor en migración y un equipo pequeño que no podía parar. Cada decisión de diseño tenía que caber dentro de eso.

De dominio y de negocio

Dos versiones del motor conviviendo. Las bases de datos de MPM v2.0 tienen otra estructura: solo funcionan System Configuration, Run Configuration y Execution. Había que diseñar para un producto que a veces está incompleto a propósito.
El solver marca los tiempos. Entre cuarenta minutos y seis horas por ejecución, en cinco etapas encadenadas. Ninguna decisión de interfaz iba a acortar eso: el diseño solo podía hacer la espera legible y evitar lanzarla en balde.
Terminología intocable. WACC, book life, flex load, PHS, RES target, GHG emissions. Traducir a lenguaje llano habría perdido precisión y confianza. La ayuda tenía que ir junto al campo, no en un glosario aparte.
Densidad irreductible. Series anuales de 2020 a 2070 por geografía y por tecnología, en sesenta y tres tablas. No había forma honesta de enseñar menos datos.

Técnicas y de equipo

Rediseño sobre lo construido. Cada componente nuevo tenía que poder convivir con los que ya estaban en producción, para poder sustituir pantalla a pantalla sin congelar el desarrollo.
Solo escritorio, 1280 px. Se usa desde puestos de trabajo fijos con pantallas grandes. Toda la maqueta se dibujó a ese ancho, tablas incluidas.
Usuarios a través de intermediarios. Sin acceso directo a la mayoría de modeladores. La investigación se hizo con los dos ingenieros de dominio y con sesiones grabadas de trabajo real.
Handoff sin diseñador después. Al cerrar el proyecto no quedaba diseño dentro del equipo: cada estado y cada mensaje de error tenía que estar dibujado y escrito antes de irme.

03 — Proceso y decisiones clave

La pregunta que más se repetía no era «cómo», era «dónde estoy»

En seis sesiones de observación sobre trabajo real esperaba ver problemas de entrada de datos. Lo que vi fue otra cosa: los modeladores dedicaban una parte enorme del tiempo a reconstruir el contexto. Qué base de datos estaba cargada, de qué proyecto, con qué sensibilidad aplicada, y si la gráfica que tenían delante venía de la ejecución de ayer o de la de la semana pasada. Al volver de una reunión, lo primero era comprobarlo todo otra vez.

Ese fue el insight que ordenó el producto. El contexto dejó de ser algo que se consulta y pasó a ser algo que está siempre a la vista: un bloque permanente en la cabecera con la base de datos y el proyecto, migas de pan de tres niveles hasta la ejecución concreta, y una etiqueta de sensibilidad impresa en cada gráfica. Nada de eso es espectacular en una captura; es lo que hizo que la herramienta se pudiera dejar y retomar.

El segundo hallazgo cambió dónde poner el esfuerzo de validación. Los errores caros no eran de interfaz, eran de latencia: escribir 900 donde el solver admite hasta 497 no rompe nada al guardar, rompe cuatro horas después. Así que las reglas dejaron de vivir en el backend y se escribieron en el propio campo, visibles antes de teclear.

Pantalla Database con el proyecto seleccionado y la tabla de bases de datos

El punto de entrada real: primero se elige proyecto, después base de datos. Cada fila lleva sus acciones de duplicar, descargar y eliminar, porque nadie empieza un modelo en blanco: se clona el del trimestre anterior y se cambian cuatro tablas.

Sección Geography con la tabla jerárquica de país, región y zona

Geography es la raíz de la que cuelga todo lo demás. Se dibujó como una tabla de tres columnas con las celdas enlazadas verticalmente: un país abarca varias regiones y cada región varias zonas, y la jerarquía se lee sin desplegar nada.

Trade-offs

Menú de tres niveles, no un asistente lineal

Descartado: un flujo guiado que recorriese las diez secciones del modelo en orden.
Por qué: nadie rellena un modelo entero de una sentada. Se entra a corregir dos tablas concretas y se vuelve a lanzar. Un wizard obliga a atravesar lo que ya está bien.
Coste asumido: un menú lateral largo. Se domó con un icono propio por sección, acordeón que recuerda qué nivel estaba abierto y marcado verde del nivel activo.

Paso a paso solo cuando el cambio toca otras tablas

Descartado: que añadir una geografía fuese una fila más en la tabla, como todo lo demás.
Por qué: una geografía nueva arrastra interconexiones, demanda y capacidad. Si se crea suelta, el modelo queda inconsistente y el solver falla sin decir por qué.
Coste asumido: dos patrones de entrada de datos en el mismo producto. Se documentó la regla que los separa: asistente solo si el cambio obliga a rellenar otras tablas.

Contar la migración en vez de esconderla

Descartado: ocultar del menú las secciones que una base de datos v2.0 no soporta.
Por qué: el modelador sabe que existen. Si desaparecen, cree que la herramienta está rota y abre un ticket. Necesita saber que no están disponibles y por qué.
Coste asumido: un aviso ámbar ocupando la parte alta del panel. Es descartable, y a cambio la deuda técnica deja de ser un fantasma.

Escenarios como columnas, no como pantallas

Descartado: una pantalla por escenario y un selector arriba para saltar entre ellos.
Por qué: el trabajo real es comparar un valor de referencia con su variante en la misma fila y en el mismo año. Separarlos obliga a memorizar cifras.
Coste asumido: tablas muy anchas para 1280 px. Se asumió desplazamiento horizontal dejando fijas las columnas de identificación (selección, año y geografía).

Evolución: de la lógica a la interfaz

Semanas 1-3 · Auditoría e inventario. Recorrido de la plataforma existente sección a sección: diez bloques, sesenta y tres tablas, cinco estados de ejecución y un mapa de qué funciona en cada versión del motor.
Semanas 4-6 · Árbol de navegación. Se cierra el primer nivel en tres pestañas (preparar datos, operar el modelo, leer resultados) y el menú de Inputs en diez secciones con tres niveles de profundidad.
Semanas 7-10 · Patrón maestro. Un único esqueleto para veinticinco pantallas: cabecera de panel con Save, banda de contexto en mint con los desplegables y su texto de ayuda, y tabla editable con barra de herramientas oscura.
Semanas 11-16 · Las diez secciones. Geografías, interconexiones, demanda, combustibles, tecnologías existentes y nuevas, restricciones, configuración y sensibilidades, cada una con sus estados vacío, cargado, editado y en error.
Semanas 17-20 · Ejecución y resultados. Los cinco estados del run, las tarjetas de etapa, la consola de logs y las cinco familias de gráficas con su modo de comparación.
Semanas 21-22 · Prototipo y handoff. Prototipo navegable del recorrido completo, guía de interacción, inventario de componentes y textos de error escritos uno a uno.

Gráfica de evolución de capacidad dentro de la sección de tecnologías existentes

Una decisión de estructura: las gráficas no viven solo en la pestaña de resultados. Dentro del modelo, Capacity evolution enseña el retiro previsto de las plantas existentes de 2020 a 2070, con selector de granularidad y de tipo de gráfica, para comprobar el dato de entrada antes de gastar seis horas de solver.

04 — Solución final

Un mismo esqueleto para veinticinco pantallas distintas

La plataforma cabe en tres pestañas: Database para elegir con qué datos se trabaja, Operate Model para parametrizarlo y Visualize Results para leerlo. Dentro de Operate Model, las diez secciones repiten el mismo patrón, de modo que aprender una es aprenderlas todas. Las excepciones a ese patrón están donde tenían que estar: cuando se cambia la estructura del modelo, cuando se espera al solver y cuando se compara.

Sección Electricity demand con el menú lateral, la banda de contexto y la tabla editable — El patrón maestro. Todas las secciones de Operate Model se construyen con estas cuatro piezas en el mismo orden y en el mismo sitio.

Formulario de una tecnología nueva de tipo Hydro con sus nueve campos y su tabla

New Technologies: Hydro. Nueve parámetros con su texto de ayuda debajo de cada campo, porque WACC o book life no se explican en un glosario aparte. El menú lateral muestra las seis familias tecnológicas abiertas en el tercer nivel.

Pantalla de restricciones de capacidad de generación y almacenamiento

Constraints: Generation and storage. El mismo esqueleto resuelve un caso más complejo: tipo de restricción, atributo, grupo de capacidad con sus acciones de crear, duplicar y borrar, y la tecnología a la que se aplica.

Asistente de alta de geografía, paso 2 de 3, con la tabla de interconexiones — La excepción deliberada al patrón: añadir una geografía obliga a completar sus interconexiones antes de guardar nada.

Configuración de ejecución con el aviso de MPM v2.0 y los parámetros avanzados desplegados — System Setup: Run configuration. La pantalla donde la deuda técnica del producto se cuenta en voz alta en lugar de esconderse.

Matriz de sensibilidades con una columna de casillas por ejecución

Sensitivities: Setup. Cada fila es una variación del modelo (categoría, tabla, nombre y filtros) y cada columna, una ejecución. Marcar una casilla es decidir qué sensibilidad entra en qué run: el paso previo a lanzar y la razón por la que después se pueden comparar siete escenarios.

Pantalla de ejecución en curso con las cinco etapas y los logs en paralelo — Execution en progreso. La espera larga tratada como una pantalla de pleno derecho y no como un spinner.

La misma pantalla de ejecución en estado de error terminado

Terminated Error. El estado cambia el color de la barra y el icono, pero no reordena nada: las etapas, las duraciones y los logs siguen exactamente donde estaban. Un fallo no es motivo para reconstruir la pantalla que el usuario ya estaba leyendo.

Ejecución completada con la consola de logs abierta y su buscador

Completed successfully con View Logs desplegado. La consola completa con buscador para el caso avanzado, dentro de la misma pantalla y sin abrir una ventana nueva: el detalle técnico está disponible, pero no es lo primero que se ve.

Resultados de interconexiones comparando siete escenarios en coste — Visualize Results, pestaña Interconnections: coste de interconexión en millones de dólares de 2020 a 2030, con los siete escenarios superpuestos.

05 — Resultados y aprendizajes

Lanzar un modelo dejó de ser cosa de tres personas

Medido seis meses después del despliegue, cruzando los registros de ejecución de la plataforma con una prueba moderada de ocho tareas con nueve usuarios de los tres perfiles.

−78 %

ejecuciones abortadas por parámetros fuera de rango: del 27 % de los lanzamientos al 6 %.

de 3 a 14

personas capaces de parametrizar y lanzar un modelo completo sin ayuda del equipo de sistemas.

35 min

para crear una variante de escenario a partir de una base de datos existente. Antes, media jornada entre CSV y scripts.

SUS 79

de usabilidad percibida con nueve usuarios, y 7 de 8 tareas completadas sin asistencia.

Lo que cambió en el trabajo del equipo

Las gráficas de la plataforma entraron directamente en los entregables al cliente. Antes se rehacían en Excel porque nadie se fiaba de una imagen sin su tabla detrás.
Los tickets de «faltan pestañas» desaparecieron en cuanto el aviso de v2.0 explicó la migración en la propia pantalla.
La incorporación de un modelador nuevo pasó de acompañamiento continuo durante semanas a una sesión de dos horas más el prototipo.
Comparar escenarios dejó de ser un entregable aparte: la media subió de dos a siete escenarios por estudio, porque montarlos ya no costaba nada.

Retrospectiva

En herramientas de cálculo lento, el estado del sistema es la mitad del diseño. Lo que más valor dio no fue una pantalla nueva, sino el bloque de contexto, las migas y la etiqueta de sensibilidad. Cosas invisibles en una captura y decisivas en el uso diario.
La deuda técnica se diseña. El aviso ámbar de MPM v2.0 fue la decisión más discutida y la que mejor envejeció. Un producto a medio migrar puede ser honesto sobre ello sin parecer roto.
La densidad no era el problema. Mi primer impulso fue aligerar las tablas. Los modeladores querían justo lo contrario: más filas a la vista. Lo que había que ordenar era la orientación, no la cantidad de datos.
Un patrón maestro compra tiempo. Cerrar un solo esqueleto antes de dibujar las diez secciones permitió que un equipo de cinco desarrolladores construyera veinticinco pantallas sin diseñador dentro y sin inventarse comportamientos.
Lo que quedó pendiente. La paleta de ocho series de datos nunca se validó con visión de color deficiente, el menú de tres niveles se queda justo a 1280 px y no hay diseño responsive. Estaban escritas como primera deuda de la siguiente iteración.
Lo siguiente. Comparar dos ejecuciones celda a celda y un historial de cambios de la base de datos: la pregunta que más se repitió al final fue «¿qué cambió entre este run y el anterior?».

Una herramienta que se puede dejar a medias y retomar

PowerModel pasó de ser un motor potente con una puerta de entrada de consola a una plataforma que un equipo entero puede usar. Tres pestañas que separan preparar, operar y leer; un patrón que se repite en veinticinco pantallas; validaciones que hablan antes de que el solver tenga que hacerlo; y una espera de horas convertida en información. Todo ello sobre un producto heredado y a medio migrar, sin parar el desarrollo ni un solo sprint.