Systellar no tenía producto, ni usuarios, ni datos. Tenía una idea técnicamente sólida y una solución inicial que no era la correcta. Mi trabajo fue entender un dominio altamente especializado lo suficientemente rápido como para cuestionarla — y construir desde cero hasta prototipo en producción.
Freelance · único diseñador
3 meses
2 cofundadores
Ingenieros expertos (feedback)
Plataforma de ingeniería de sistemas complejos. B2B enterprise. Sin producto previo.
Impacto
Desde
Sin producto, sin prototipo, sin sistema de diseño.
Hasta
Módulos completos en alta fidelidad, DS incluido.
Resplado
Techstars · ESA BIC · NVIDIA · Microsoft
No tengo acceso a métricas de producción — el proyecto terminó en el entregable. Lo que sí existe es el producto que fue a inversores y clientes enterprise, construido desde cero en 12 semanas.
Systellar llegó con un problema claro y una solución ya formulada. El problema: los ingenieros que diseñan sistemas complejos — satélites, aeronaves, dispositivos médicos — trabajan con información dispersa en modelos, hojas de cálculo, documentos, correos y scripts. Cuando algo cambia en un punto, la propagación es manual, lenta y casi siempre incompleta. Los errores no aparecen al inicio. Aparecen al final, cuando el sistema ya está a medias construido.
La solución que traían: un agente de IA. Una interfaz de chat. El usuario pregunta, la IA responde, el problema se resuelve.
Ese giro no ocurrió en un momento concreto. Ocurrió al ir aterrizando todo: conversaciones con ingenieros expertos del sector, sesiones semanales con los cofundadores, y el proceso de intentar trazar cómo se usaría el chat en un flujo de trabajo real. La respuesta era siempre la misma: en algún punto, el chat no era suficiente. El contexto era demasiado, la trazabilidad demasiado crítica, las dependencias demasiado intricadas para que una interfaz conversacional las gestionara.
Reformulamos el problema antes de diseñar una sola pantalla: el objetivo no era dar respuestas. Era hacer que el sistema de ingeniería fuera coherente por defecto.
El primer mes no fue de diseño. Fue de comprensión. Los ingenieros de sistemas trabajan con un lenguaje muy específico: SysML, requisitos, interfaces, atributos, verificación, documentación de entrega. Diseñar sin entender ese lenguaje habría producido una interfaz genérica que los usuarios habrían rechazado en el primer uso.
Trabajé directamente con los cofundadores — semana a semana — y con ingenieros expertos externos que aportaban feedback sobre flujos de trabajo reales. El objetivo era doble: entender qué hacen estos usuarios en su día a día, y entender por qué las herramientas existentes (CATIA, Cameo, hojas de Excel) no resolvían el problema de coordinación.
Un cambio en un requisito afecta al modelo de sistema. El modelo afecta a la documentación. La documentación afecta a la verificación. Y ninguna herramienta existente trackeaba esas cadenas de forma automática. La coordinación era manual, cara y fuente constante de errores descubiertos demasiado tarde.
Con ese entendimiento, la arquitectura de la plataforma se volvió evidente: no un chat, sino un workspace unificado donde modelo, requisitos, documentación y workflows comparten un backbone común. Cualquier cambio en un nodo se propaga — de forma auditable — al resto del sistema.
Tres decisiones. La más importante no fue de diseño de producto.
Decisión 01
La presión en una startup es llegar a pantallas lo antes posible. En este caso, ir directo a UI habría sido el error más caro. El producto tenía cinco módulos interdependientes — model-based engineering, requisitos, documentación, workflows, version control — y la forma en que se conectaban entre sí era más importante que cómo se veía cada uno por separado. Invertí el primer tramo en mapear la arquitectura de información completa antes de hacer un solo wireframe. Eso definió la lógica de navegación, la jerarquía de objetos y las relaciones entre módulos.
La coherencia estructural del producto en producción refleja ese trabajo previo. No es estética — es arquitectura.
Decisión 02
Con un solo diseñador y un equipo de desarrollo pequeño, el sistema de diseño no era un lujo — era la única forma de mantener consistencia sin un proceso de revisión constante. Partimos de una base existente pero fue adaptado completamente para la casuística de Systellar: componentes que reflejan objetos de ingeniería (nodos del modelo, bloques de requisitos, estados de verificación), no componentes de SaaS genérico. La diferencia importa: un ingeniero que ve un componente que habla su lenguaje confía antes en el producto.
El DS fue la base del handoff. El equipo de desarrollo implementó con menos ambigüedad y menos decisiones abiertas en código.
Decisión 03
La IA acabó en el producto — pero no como protagonista. El workspace unificado era la interfaz principal. El agente operaba dentro de ese contexto: con acceso al estado real del sistema, a los requisitos, al modelo, a los documentos. No era un chat genérico que respondía en frío. Era asistencia contextualizada que sabía exactamente dónde estaba el usuario y qué estaba mirando. Eso cambia fundamentalmente la utilidad: la IA no sustituye el control del ingeniero, lo amplifica.
El pivote de chat a workspace no fue un rechazo a la IA. Fue encontrarle el lugar correcto.
Antes
Después
Este proyecto terminó en el entregable — prototipo de alta fidelidad, sistema de diseño completo, handoff al equipo de desarrollo. El producto está en producción, pero no tengo acceso a métricas de uso. Lo señalo de forma explícita porque el impacto aquí no se mide en conversión o tiempo de tarea.
Systellar opera hoy respaldado por Techstars, ESA BIC y NVIDIA. Eso no es la consecuencia directa de mi trabajo de diseño — es el resultado de un equipo y una propuesta de valor sólida. Pero el producto que fue a inversores, el que se presentó a clientes enterprise en defensa y aeronáutica, el que aparece en su web y en sus demos: eso sí salió de doce semanas de trabajo conjunto con cero producto previo.
Techstars · ESA BIC · NVIDIA · Inception · Microsoft for Startups
El proceso fue iterativo y muy colaborativo con los cofundadores. No hubo un handoff al final — hubo validación continua en cada fase, especialmente en arquitectura, donde los cambios conceptuales eran más costosos de revertir.
Investigación del dominio + sesiones con ingenieros expertos del sector
Reformulación del problema: de chat a workspace unificado
Arquitectura de información — módulos, jerarquía de objetos y modelo de relaciones
Wireframes en baja — validación de flujos con los cofundadores
Sistema de diseño adaptado al dominio de ingeniería de sistemas
Prototipo de alta fidelidad — cinco módulos completos con interacciones
Handoff documentado al equipo de desarrollo
Resultado
En este proyecto la solución llegó antes que la comprensión del problema. El trabajo fue reordenar eso — rápido, sin red, con un dominio que aprender desde cero.