Diseño UX basado en evidencias para software de simulación profesional
El software comenzó como una herramienta de investigación en el Chr Michelsen Institute en la década de 1990. Su base científica le otorgó capacidades de simulación que aún hoy lo sitúan entre los sistemas de CFD más potentes utilizados en la industria. Actualmente funciona como software CFD especializado para flujos de trabajo complejos en los que la precisión científica es más importante que la comodidad.
Este proyecto forma parte de nuestro trabajo continuo en software científico y de ingeniería complejos, donde la UX basada en evidencias, el option mapping y la arquitectura de sistemas dan forma a la interfaz final.
Aplicamos Dynamic Systems Design, un método que hace crecer las soluciones mediante experimentación integrada, resuelve las tensiones entre la optimización local y la coherencia del sistema, y acompaña la implementación hasta que las organizaciones alcanzan la independencia.
El panorama de usuarios cambió. Los usuarios expertos originales se jubilaron y los nuevos ingenieros se orientaron hacia herramientas más simples, con menos capacidades pero más fáciles de usar. Sin intervención, el producto corría el riesgo de perder relevancia a medida que disminuía el conocimiento institucional.
El objetivo de este proyecto era prolongar la vida útil del software otros veinticinco años. El rediseño debía respetar la lógica científica, conservar la complejidad esencial y, al mismo tiempo, ofrecer una vía de entrada más clara para los nuevos ingenieros que necesitaban integrarse más rápido en el sistema. También debía hacer que las capacidades fueran accesibles para nuevos roles no técnicos, como los gestores de riesgos. Esto requirió un enfoque de software UX técnico basado en el comportamiento observado en la práctica real de la ingeniería.
NUESTRAS CONTRIBUCIONES
Evidence-Based Research
Domain Learning
Option Space Mapping
Interaction Architecture
Prototipos de alta fidelidad
Diseño de UI – claro y oscuro
Design System
Implementation Partnership
UNA TRANSFORMACIÓN ESTRUCTURADA EN MÚLTIPLES FASES
El rediseño siguió un proceso estructurado que trató la interfaz como parte del propio software de simulación. A través de Sandbox Experiments, comenzamos con cuatro semanas de investigación basada en evidencias sobre flujos de trabajo complejos. Esto incluyó el benchmarking de doce productos competidores, veinticuatro entrevistas con usuarios, veintitrés observaciones en entornos de trabajo, nueve entrevistas con stakeholders y un análisis de la evolución del mercado. Estas actividades aclararon cómo trabajaban realmente los ingenieros con el sistema y cómo estaban cambiando las expectativas.
A continuación siguió una fase de seis semanas en la que utilizamos option space mapping para todo el producto. Se definieron diez retos clave y se exploraron entre tres y seis soluciones para cada uno. Esto dio lugar a cuarenta y cinco variantes, que se probaron en treinta y siete sesiones con usuarios e ingenieros. Cada opción se evaluó en función del esfuerzo de aprendizaje, el rendimiento de expertos, la extensibilidad futura y el coste de desarrollo. Cuatro talleres de decisión con la dirección de producto e ingeniería generaron una alineación compartida entre los grupos de stakeholders y establecieron una dirección clara, que se tradujo en una estructura de requisitos detallada para el diseño de interacción y los componentes de la UI.
Durante Concept Convergence, siete meses de trabajo de ejecución produjeron la arquitectura de interacción end-to-end, prototipos de alta fidelidad, UX y UI detallados y un Design System. El proceso concluyó con Implementation Partnership: dos años de soporte a desarrolladores para guiar la implementación y evitar regresiones.
EL PESO DE LAS RESTRICCIONES HISTÓRICAS
La interfaz anterior había estado en uso activo durante quince años. Su estructura reflejaba la herencia científica, los hábitos de los ingenieros y la inercia de un código de larga duración. Cualquier trabajo significativo en la UX técnica requería una comprensión clara de esta historia.
Para lograrlo, el equipo trabajó con domain learning: nos convertimos en usuarios productivos del software. Manuales, tutoriales de YouTube, vídeos de formación internos y pruebas controladas dentro de la aplicación formaron la base de nuestro aprendizaje. Durante el proceso recopilamos muchas preguntas sobre workflows y edge conditions. Los stakeholders pasaron un total de cuatro horas con nosotros en dos sesiones intensivas, lo que permitió aclarar la lógica subyacente y reconstruir la secuencia de los workflows mediante reverse engineering.
Este análisis reveló qué partes de la interfaz expresaban una complejidad esencial que respaldaba resultados científicos correctos y qué partes habían acumulado complejidad accidental con el tiempo. Esta distinción guió el rediseño posterior y evitó cambios innecesarios en métodos consolidados: un ejemplo de constraint respecting que preservó lo que funcionaba mientras reestructuraba lo que no.
LAS REALIDADES DE LOS USUARIOS MODERNOS
La investigación involucró a usuarios con niveles muy distintos de experiencia y responsabilidad. Los ingenieros CFD senior trabajaban a diario con la herramienta y confiaban en ella para decisiones con implicaciones de seguridad y financieras. Los analistas de seguridad y los ingenieros de procesos la utilizaban en periodos de investigación específicos. Los ingenieros más recientes la usaban con menos frecuencia y a menudo sentían que la curva de aprendizaje competía con otras prioridades.
Su trabajo implicaba una alta carga cognitiva y flujos de trabajo no lineales. Los ingenieros se movían entre configuración, verificación e interpretación sin seguir una ruta fija. Este comportamiento difiere de los patrones que se observan en la enterprise software UX típica.
Las entrevistas y las observaciones mostraron que los responsables de producto y los desarrolladores entendían partes del panorama, pero no toda la gama de comportamientos. Esto confirmó que el diseño debía basarse en investigación basada en evidencias y no en suposiciones sobre el uso típico.
PATRONES DE TAREAS EN EL TRABAJO CIENTÍFICO
Para hacer explícitos estos flujos de trabajo complejos, documentamos ciento dos tareas individuales en todo el sistema. Los usuarios describieron sus objetivos en cada tarea, con qué frecuencia se realizaba, el nivel de dificultad percibido y las acciones necesarias para completarla. Esto reveló una amplia gama de comportamientos, desde ajustes rápidos realizados por expertos hasta secuencias más lentas utilizadas por personas con menos experiencia.
Luego analizamos los patrones de interacción y los modelos mentales que guiaban cada decisión. Para las tareas de varios pasos identificamos la jerarquía de necesidades dentro de la secuencia. Algunos pasos eran esenciales para la corrección, otros prevenían errores y otros mejoraban la eficiencia.
Este mapeo de tareas mostró dónde la interfaz existente estaba bien alineada con el diseño de software científico y dónde se acumulaba fricción. Surgió aquí una observación comparativa moderada: la amplitud de estas tareas era considerablemente mayor que la que solemos ver en herramientas orientadas al negocio, que tienden a distribuir los flujos de trabajo en muchas pantallas más pequeñas. Este software CFD concentraba esa diversidad en un único entorno.
CÓMO LAS OBSERVACIONES SE CONVIRTIERON EN ESPECIFICACIONES
El siguiente paso fue convertir el análisis de tareas en requisitos precisos para el diseño de interacción y los componentes de la UI. Cada interacción significativa recibió una definición explícita de su propósito, restricciones, dependencias y comportamiento esperado. Esto garantizó que las decisiones de diseño siguieran siendo compatibles con el modelo científico y con las necesidades operativas de los ingenieros experimentados.
Por ejemplo, los componentes implicados en la configuración de escenarios necesitaban reglas claras de visibilidad, ya que los usuarios cambiaban con frecuencia entre parámetros, comprobaciones e interpretación. Los requisitos establecían qué valores debían permanecer visibles, dónde eran necesarias advertencias y cómo debía responder el sistema ante entradas incompletas.
Estos requisitos formaron una base estable que guió las fases de diseño posteriores y permitió a los ingenieros trabajar a partir de especificaciones claras en lugar de descripciones generales. Los requisitos se revisaron con los stakeholders de producto, ingeniería y dominio para garantizar que cada definición estuviera alineada con las restricciones científicas y con las realidades operativas de los usuarios experimentados.
ITERACIONES QUE REVELARON LAS VERDADERAS RESTRICCIONES
Mediante lateral exploration exploramos cada uno de los diez desafíos clave de la UI a través de múltiples iteraciones. La galería de seis variantes para una sola interacción ilustra este enfoque. Las variantes incluían diseños asimétricos con pestañas, paneles plegables, configuraciones con un solo panel lateral y combinaciones de paneles de configuración.
A lo largo de seis semanas creamos cuarenta y cinco soluciones y las evaluamos según los criterios definidos previamente. En estas evaluaciones participaron diseñadores, ingenieros y expertos de dominio. El proceso reveló compromisos, dependencias y edge cases que habrían permanecido ocultos en una exploración lineal.
Durante estas sesiones surgió una observación importante. Los principiantes y los usuarios avanzados solían seguir la misma secuencia de acciones, pero a diferentes velocidades y con distintas expectativas sobre la visibilidad. Esta tensión guio nuestras decisiones de diseño mediante tension-driven reasoning, demostrando que un único patrón cuidadosamente estructurado puede servir a ambos grupos sin fragmentar la experiencia.
Al final de esta fase sabíamos qué patrones podían apoyar al sistema en su conjunto y cuáles debían descartarse. Esto creó una base predecible para el diseño end-to-end.
COMPORTAMIENTO DE LA INTERFAZ EN ENTORNOS REALES
La interfaz respalda a los ingenieros que trabajan con instalaciones físicas y plantas industriales. Está diseñada para funcionar en paralelo con una vista tridimensional de la instalación, lo que exige tanto precisión científica como claridad operativa.
Los prototipos de alta fidelidad nos permitieron observar el comportamiento y refinar cómo los usuarios navegaban entre el contexto visual, los parámetros de simulación y los controles del sistema. El modelo de interacción debía mantenerse estable incluso cuando la atención cambiaba entre estos elementos. Estas pruebas revelaron qué disposiciones favorecían una toma de decisiones segura y cuáles aumentaban la carga cognitiva.
El prototipo demostró cómo la estructura revisada integraba los controles de escenario, las vistas del modelo y el contexto de ingeniería en un único entorno. Esta prueba aportó evidencia de que la arquitectura elegida se comportaba correctamente en condiciones reales de dominio.
UNA HERRAMIENTA DE TRABAJO PARA DATOS DE VIENTO
El gráfico de viento es un ejemplo de visualización específica del dominio dentro de un entorno UX técnico. Debía seguir siendo legible incluso cuando los usuarios cambiaban rápidamente la dirección, la intensidad y los parámetros del escenario.
El diseño visual utilizó una gramática controlada. La dirección requería una resolución angular coherente. La magnitud se mostraba en bandas discretas que los usuarios podían escanear rápidamente. Los valores de los parámetros se mantenían visibles entre vistas para que los ingenieros pudieran relacionar los cambios visuales con las decisiones de configuración. Estas decisiones garantizaron que el gráfico de viento siguiera siendo una herramienta de razonamiento y no un elemento decorativo.
Este enfoque refleja las necesidades de la UX en software de ingeniería, donde las visualizaciones deben expresar el significado con precisión.
REPRESENTACIÓN CLARA DE LA DINÁMICA DE LOS GASES
La propagación del gas requería un nivel comparable de rigor visual, aunque el modelo científico subyacente fuera diferente. El comportamiento de los conos y los campos de concentración asociados debía mostrarse de forma que respaldara una evaluación de seguridad fiable.
La interfaz debía expresar la propagación espacial, la concentración y el tiempo de una forma que los ingenieros pudieran interpretar bajo presión. El diseño expuso estas variables mediante una estructura que podía inspeccionarse sin ocultar detalles importantes. Las vistas de conos plegables y los controles asociados presentaban la información científica sin sobrecargar la vista principal.
El objetivo era expresar la física subyacente mediante un diseño claro del software de simulación, en lugar de simplificar los propios fenómenos.
GESTIÓN DE ESTADOS DENSOS EN UNA SOLA VISTA
Estas visualizaciones se sitúan dentro de un único entorno principal. Los usuarios experimentados mantienen todo el escenario en mente y se mueven entre sus partes a medida que evolucionan las condiciones. Esto difiere de muchas herramientas enterprise, que distribuyen la información en varias pantallas más simples.
Dentro de este único entorno, ciertos componentes gestionan estados internos complejos. La herramienta para definir la composición de las mezclas de gas es un ejemplo. Contiene diecinueve estados que representan componentes puros, mezclas estándar y formulaciones personalizadas. La UI debía admitir estos estados sin interrumpir el proceso de razonamiento del ingeniero.
La relación basada en reglas entre los modos claro y oscuro mantuvo señales semánticas coherentes en distintos entornos. Esto permitió un trabajo fiable independientemente de las condiciones de iluminación o de la configuración del hardware.
EJE DE ORIENTACIÓN Y CONVENCIONES MNEMOTÉCNICAS
La interacción con la geometría requería señales de orientación estables. La convención mnemotécnica RGB asigna el rojo, el verde y el azul a los ejes X, Y y Z, lo que reduce la confusión cuando los usuarios pasan de vistas detalladas a vistas generales.
El eje de orientación debía seguir siendo legible a distintas escalas y en diferentes contextos. La cuadrícula y la lógica de rotación se definieron con incrementos claros y comportamiento de ajuste, evitando estados de orientación ambiguos. Estas reglas garantizaron que el sistema nunca mostrara una vista espacial que los ingenieros pudieran interpretar de forma incorrecta.
Este nivel de precisión es característico del diseño de software científico, donde la claridad de la interpretación influye en la calidad de las decisiones.
UNA LÓGICA DE DISEÑO PARA LOS MODOS CLARO Y OSCURO
Las variantes clara y oscura estaban gobernadas por un conjunto de reglas en lugar de decisiones estéticas separadas. Cada color del modo claro se asignaba mediante una fórmula a un valor correspondiente en el modo oscuro. Esto preservó las relaciones de contraste y el significado semántico en ambas variantes.
Los ingenieros que cambiaban entre entornos podían confiar en la misma estructura perceptiva. Los desarrolladores podían implementar ambas variantes a partir de una única fuente sin mantener diseños paralelos.
El elemento interactivo de la página que permite a los lectores cambiar entre modos refleja cómo los usuarios experimentan estas variantes en su trabajo diario.
UNA BASE MÁS SÓLIDA PARA EL TRABAJO CIENTÍFICO
El proyecto requirió una comprensión profunda de las restricciones históricas, los flujos de trabajo científicos y el comportamiento observado bajo presión. Dynamic Systems Design combinó domain learning, evidence-based research, option space mapping y multi-perspective synthesis para crear una estructura coherente capaz de sostener el producto durante otra generación.
Resultados reales confirmaron el valor de este enfoque. El tiempo hasta la primera simulación exitosa para nuevos usuarios se redujo de cuatro días a seis horas. Los errores de configuración en la preparación de escenarios pasaron de un promedio de cinco a ocho por simulación a uno o dos. La carga de corrección, que antes requería entre cuatro y seis horas, se redujo a unos veinte minutos. Los equipos que antes tenían un usuario activo de media ahora tienen entre tres y cuatro. Los formadores, que antes impartían cursos de tres días, ahora utilizan breves seminarios web y materiales en vídeo.
La organización obtuvo recursos intangibles: criterio sobre lo que importa en el trabajo de simulación complejo, una intuición de producto compartida sobre cómo debe comportarse el sistema y una capacidad de razonamiento que permite a los equipos ampliar la interfaz sin fragmentarla. El sistema mantiene su posición competitiva al preservar el rigor científico y la claridad operativa, mientras que los competidores que priorizan una simplicidad aparente sobre la precisión del dominio tienen dificultades para servir a ingenieros que trabajan en condiciones reales con requisitos de seguridad complejos.
La arquitectura rediseñada, el design system y los prototipos de alta fidelidad proporcionan a los equipos de desarrollo una base duradera y evolutiva para el trabajo científico y de ingeniería del futuro.