He hecho un ejercicio y tengo la sensación de que lo tenía que haber hecho hace tiempo. No como experimento académico, sino como práctica de honestidad profesional. Hay mucho titular sobre el uso de IA en el trabajo, mucho porcentaje citado sin contexto y mucha opinión sin datos propios. Así que he decidido medirlo.
Durante 7 días he registrado mis tareas, he identificado en cuáles he usado inteligencia artificial y he estimado, de la forma más honesta que he podido, qué porcentaje de cada tarea ha ocurrido con ayuda de IA. No es una medición exacta. Es una estimación razonada, que creo que vale más que no medir nada.
Estos son los resultados.
Uso de IA en mis tareas de los últimos 7 días
El método, porque importa
Cada día he anotado las tareas que he hecho: reuniones, trabajo de gestión, producción de contenido, desarrollo de negocio o formación. Para cada una he identificado si he usado IA (Claude, principalmente, aunque también Gemini en algún momento) y he estimado el porcentaje de esa tarea que ha ocurrido con asistencia de la herramienta.
Hay una distinción que me parece importante y que no suele hacerse cuando se habla de esto. Una cosa es cuántas tareas llevan IA, y otra distinta es cuánto tiempo de cada tarea transcurre usando IA. Las dos métricas cuentan historias diferentes.
Lo que ha salido
De 27 tareas registradas en 7 días, 23 han llevado algún grado de uso de IA. Eso es el 85%. Un número que, sacado de contexto, puede sonar exagerado. Pero el matiz está en la segunda métrica: el porcentaje de tiempo trabajando con IA ha sido de media el 27%.
Es decir: en casi todo lo que hago ha entrado la IA en algún momento, pero en la mayoría de los casos ha ocupado una parte pequeña del tiempo total de la tarea. Ha acelerado una fase, ha ayudado a estructurar, ha sintetizado, ha redactado un primer borrador. No ha conducido. No ha decidido.
La distribución por tipo de tarea es también reveladora. En gestión y dirección, que es donde más tiempo paso y donde la IA ha entrado con más frecuencia, el porcentaje de tiempo con IA ronda el 28%. En producción de contenido, que incluye artículos, informes y materiales de cliente, sube al 55%. En desarrollo de negocio se ha quedado en torno al 30%. Y en formación y mentoría, donde la presencia humana y el criterio propio son más difíciles de delegar, ha bajado al 15%.
Lo que me ha llamado la atención de estos datos
Primero: el uso de IA ha estado distribuido por todas las tipologías de tarea, no concentrado sólo en las creativas o de escritura. Reuniones, seguimiento de proyectos, comunicaciones internas o actualización del CRM. La IA ha entrado en el tejido operativo del trabajo, no sólo en la producción de contenido visible.
Segundo: el porcentaje de tiempo ha sido relativamente bajo a pesar de la alta frecuencia de uso. Eso dice algo muy interesante sobre cómo se integra en la práctica real. No como sustituto de la jornada, sino como acelerador de partes concretas de cada tarea.
Tercero: donde la IA ha ocupado más tiempo porcentual ha sido en producción de contenido. Tiene sentido. La generación de texto es donde la herramienta tiene más tracción. Pero incluso ahí, el 55% significa que el 45% restante ha sido trabajo humano: criterio editorial, decisión sobre qué decir y qué no, revisión, ajuste de tono, contexto que la herramienta no tiene.
Una advertencia metodológica que conviene leer
Estos datos son los míos. En una semana concreta, con las tareas concretas que he tenido. No son extrapolables a otras profesiones, ni tan siquiera a otras semanas de mi trabajo. La variación es alta: un día con mucha gestión de equipo y el porcentaje cae; una jornada de producción de informes y sube.
Lo que sí creo que es generalizable es el enfoque. Medir el uso de IA en el trabajo propio, con datos propios, produce información mucho más útil que consumir estadísticas de terceros sobre cómo la IA está transformando el trabajo. Esas estadísticas tienen su lugar. Los datos propios tienen otro. Y lógicamente me quedo con ese. 
La conclusión provisional
He usado la IA en casi todo lo que he hecho. Pero la he usado poco tiempo en cada cosa. Eso, leído con cautela, sugiere que la integración es real pero complementaria. La IA no ha reemplazado ninguna tarea. Ha entrado en partes de muchas tareas, acelerando la ejecución de lo que ya sabía que quería hacer.
Lo que la IA no ha cambiado: qué reuniones tener, qué proyectos priorizar, qué decirle al equipo en un momento difícil, cómo leer una situación comercial, qué criterio aplicar al revisar un entregable. Eso sigue siendo territorio exclusivamente humano, al menos en mi caso y por ahora.
Y es probable que esto, más que cualquier porcentaje, sea lo que vale la pena seguir mirando.
Hoy quería hablar de la constancia en redes sociales. Lo haré a través de Yolanda. Vamos a poner que se llama Yolanda. Me escribió un sábado por la mañana. Dos mensajes, sin más. Me decía que disfrutaba leyendo lo que publico, y que en medio del ruido habitual de LinkedIn, encontrar algo así le daba paz mental.
«Se convierte en un recordatorio de que hay gente normal haciendo cosas normales, con dilemas, incoherencias y aprendizajes.»
La verdad es que hay mensajes que llegan en el momento justo. No necesariamente porque uno esté a punto de dejarlo, sino porque la constancia tiene una parte invisible que casi nadie ve: el esfuerzo y el riesgo de ser honesto en público, semana tras semana, sin saber si eso le llega a alguien o se pierde en el algoritmo.
Publicar con regularidad tiene poco de glamuroso. Lo sé muy bien porque lo llevo haciendo desde 2003. Hay días en los que la idea no termina de cuajar, días en los que uno se pregunta si merece la pena invertir ese tiempo, momentos en los que uno constata que el post que más he trabajado recibe tres reacciones y el que escribí en veinte minutos genera conversación. Ni que decir tiene ese post que es una chorrada y es el que más le gusta a todo el mundo. La arbitrariedad forma parte del juego, y conviene aceptarla.
Lo que Yolanda describía no era sólo que le gustase un artículo concreto. Era que el conjunto, la acumulación de contenido a lo largo del tiempo, le generaba algo. Eso es lo que no se puede generar con prisas: la coherencia que da el tiempo y la repetición.
El feedback de una persona así vale más que cien métricas de engagement. No tanto porque las métricas no importen (que importan, no seamos hipócritas), sino porque me recuerdan por qué hago lo que hago cuando las métricas no son lo que espero.
Así que esto va por todas las personas que alguna vez han escrito o enviado ese tipo de mensajes. Quienes se toman un momento para decirle a alguien que lo que hace les sirve. Es un gesto pequeño que, para quien lo recibe, no lo es tanto.
Os aseguro que hoy está siendo en lo personal un día complicado. Pero no queda más remedio que entonar eso de que la vida sigue. Aquí vengo yo a contar algo en lo que he estado trabajando en los últimos meses. Muchos meses, que si son 12, ya los podemos contar como un año. La cosa es que en el blog de mi empresa, de Torresburriel Estudio, hemos publicado un post de esos largos y sesudos, hablando de un marco de trabajo de diseño UX con y para IA.
Y quería venir por aquí a contarlo, porque me he dejado las pestañas, los nervios, a veces un poco de salud también y, sobre todo, he generado grandes cantidades de ilusión mientras trabajaba en ello.
Básicamente, porque a veces cuando ves una cosa clara y te das cuenta que vas siendo capaz de hacer la tangible, entendible, comprensible, y en cierto modo, debes visos de realidad, la sensaciones acojonante e imparable.
Pues eso es esta movida. Ya lo he empezado a presentar por ahí y la verdad es que me faltan días en el calendario para seguir haciéndolo.
A quienes os interesen los detalles, id al post, que es largo y está muy bien explicado. Está feo que lo diga así porque lo he escrito yo, pero es lo que hay.
El diseño UX con y para IA genera mucho interés, y es un interés real. Yo no lo subestimaría.
Hoy hace exactamente ocho años estaba en Milán. No estaba de turismo. Estaba defendiendo la candidatura de Torresburriel Estudio para entrar en UXalliance, la red global de consultoras independientes de UX más relevante del mundo. Habían sido tres años de conversaciones, de alineación de expectativas, de aprender cómo funcionaba la red por dentro, de ajustar metodologías, formas de hacer y modelos de delivery. Tres años en los que, sin que yo lo supiera del todo, ya estaba aprendiendo de forma acelerada antes incluso de ser miembro. Cuando he hecho la vista de atrás acerca de ese proceso, todavía flipo.
Foto de grupo del equipo de UXalliance en Dubái en 2025
El 18 de marzo de 2018 fue el día. La presentación ante el International Board fue intensa. Y recuerdo con nitidez el momento en que alguien me preguntó: ¿por qué debería la UXalliance tener un partner con sede en la quinta ciudad del país?
Mi respuesta fue sencilla y directa. También es cierto que había hecho los deberes y mi presentación fue incontestable. A los aragoneses nos cuesta mucho entrar en algún sitio, pero cuando entramos, no nos vamos. Cuando terminé, sentí orgullo. Del de verdad.
Lo que ha pasado desde entonces
Ocho años dan para mucho. Y aunque es verdad que no todo ha sido fácil, ni todo ha salido como queríamos, el balance es mucho más que rotundo.
Hemos asistido a todas las convenciones anuales desde 2018, con la excepción de 2020 y 2021, que fueron en formato online. Hemos estado en Milán, en Johannesburgo, en París, en Dubái y en Bangalore. Y por supuesto, organizamos nosotros el evento central de 2023 en Zaragoza, algo de lo que seguimos muy orgullosos.
En cada convención presencial hemos ido dos o tres personas del Estudio, hemos estado una media de siete días, y hemos sido ponentes como speakers en Johannesburgo, en Zaragoza, en Bangalore y en Milán. Está claro que no hemos ido a mirar. Hemos ido a aportar.
Los números, porque los números también cuentan
Desde marzo de 2018 hasta hoy han pasado 96 meses. Hemos asistido a una reunión de trabajo mensual de la red durante todo ese tiempo. Eso son 96 sesiones de trabajo colaborativo, de puesta en común, de construcción de red.
Hemos estado en 6 convenciones presenciales, una media de 7 días cada una, con 2 o 3 personas del Estudio. En total: más de 100 días invertidos sólo en el encuentro anual de la alianza.
Hemos participado en 63 proyectos para clientes de la red, todos ellos de alcance internacional. En cada uno de esos proyectos hemos dedicado una media de 32 horas de trabajo de campo con una media de 3 personas involucradas. Eso supone más de 6.000 horas de investigación y trabajo directo con usuarios, que no es poco.
Y la facturación generada a través de la alianza, sólo en los proyectos que tengo identificados con exactitud, supera 1,5 millones de euros en estos ocho años.
No está mal para una consultora de Zaragoza que un día se plantó en Milán a explicar por qué merecía estar en la misma mesa que las mejores del mundo.
El perfil de trabajo que hemos construido
Una parte de lo que más valoro de estos ocho años es la diversidad de lo que hemos aprendido a hacer. Los proyectos que hemos ejecutado para la red cubren un espectro amplísimo: salud y dispositivos médicos, automoción, tecnología de consumo, servicios financieros, banca, seguros, logística, retail, plataformas digitales. Clientes que están en el top tres mundial de su categoría. Equipos extraordinariamente profesionales, con una muy alta exigencia, con estándares siempre muy altos. Cada proyecto ha sido una aceleración.
Hemos aprendido a trabajar a otra velocidad, con otra exigencia, con otra perspectiva de lo que significa calidad en investigación. Para que os hagáis una idea, a mi equipo siempre le he dicho que en esos proyectos hay que sacar un 10/10.
Lo más importante no son los números
Todo lo anterior está muy bien y la verdad es que me alegra poder contarlo con datos. Pero lo más importante de estos ocho años no se mide en euros ni en horas. Lo más importante es la red de personas que hemos construido alrededor. Y os aseguro que antes de entrar en la alianza, no me podía imaginar, bajo ningún concepto, que esto iba a ser así.
Iba a escribir familia, pero es un término tan manoseado en contextos profesionales que me cuesta. Lo que sí puedo decir es que la UXalliance funciona como las grandes familias: con aprendizajes compartidos, con lealtades que se forjan con el tiempo, con decepciones ocasionales, con fricciones que se resuelven porque hay algo más grande que un malentendido puntual. Con cuidados. Con preocupación real (no de boquilla) cuando a alguno de nosotros las cosas no le van bien. Con alegrías inmensas cuando a alguno le salen las cosas redondas.
Hay personas en esta red con las que tengo una complicidad que va mucho más allá del partnership formal. Eso no se construye solamente firmando un contrato. Eso se construye estando, aportando, siendo honestos, diciendo lo que pensamos aunque no siempre guste.
Somos aragoneses. Tercos, honestos, a veces sin filtro, pero leales como pocos. Creo que eso se nota. Y creo que eso es parte de lo que hemos aportado a la red.
Torresburriel Estudio no sería el mismo estudio sin la UXalliance. Estoy convencido de eso. Y también estoy convencido de que la alianza no sería exactamente la misma sin nosotros. No por arrogancia, sino porque la verdad es que dejamos huella allá donde estamos. Es lo que hacemos. Es lo que somos.
Ocho años. Muchos más por delante es como se da forma al futuro.
La semana pasada propuse hablar sobre inteligencia artificial y experiencia de usuario en el SOS Zaragoza 2026. Nadie votó por la temática. Cero. Un fracaso rotundo en el formato de selección de temas que tiene el evento. Y sin embargo, creo que eso confirma exactamente lo que quería plantear.
Ilustración de Hugo Tobio
La conversación que no estamos teniendo
En el sector del diseño de producto y la experiencia de usuario llevamos un montón de tiempo ya hablando de IA. Pero la conversación se ha quedado atascada en un solo registro: la IA como herramienta. Prompts para generar wireframes, plugins de Figma que autocompletan layouts, asistentes que resumen entrevistas de investigación. Todo eso está muy bien, pero es sólo una de las tres dimensiones de la cuestión.
En la UX Masterclass de Bangalore de 2025, Niketa Jhaveri (Amazon) presentó un marco que articula algo que muchos intuimos pero que pocos han sabido nombrar. Jhaveri distingue tres formas de relacionarse profesionalmente con la inteligencia artificial, y cada una tiene implicaciones radicalmente distintas para quienes diseñamos productos digitales.
Primera dimensión: trabajar con IA
Esta es la que todo el mundo conoce. La IA como compañera de equipo. Herramientas que asisten en la investigación, que generan variantes de diseño y que sintetizan datos cualitativos o que aceleran el prototipado.
No hay mucho que descubrir aquí porque es el terreno que ya pisamos habitualmente. Cualquier equipo de diseño mínimamente actualizado ha incorporado alguna forma de asistencia con IA en su flujo de trabajo. La clave, que no es menor, está en entender qué se puede delegar y qué no. El criterio profesional sigue siendo humano. La IA acelera la ejecución, pero no sustituye el juicio. Hasta aquí estamos de acuerdo y hay una opinión más o menos consensuada.
Lo interesante de esta dimensión es que tiende a generar una falsa sensación de que ya estamos con la IA. De que hemos incorporado la herramienta, le hemos sacado partido, la productividad ha mejorado. Fin del asunto. Pero no es el fin. Es el principio.
Segunda dimensión: trabajar para la IA
Aquí es donde la conversación se pone interesante. Y probablemente por eso casi nadie la votó ayer (quiero creer).
Trabajar para la IA significa diseñar productos y experiencias cuyo usuario no es una persona, sino un sistema de inteligencia artificial:
Interfaces de entrenamiento de modelos
Flujos de configuración de agentes autónomos
Dashboards de monitorización de rendimiento de IA
Experiencias que permiten a un equipo de negocio, sin conocimientos técnicos, supervisar, ajustar y gobernar un modelo
Aquí hay poca conversación previa porque este es un territorio de diseño completamente nuevo. No hay patrones consolidados ni convenciones de interacción maduras. No hay heurísticas de usabilidad pensadas para este contexto. Y sin embargo, cada semana aparecen más productos que necesitan exactamente este tipo de diseño.
La pregunta que nos debería quitar el sueño como profesionales del diseño es: si no diseñamos nosotros estas interfaces, ¿quién lo va a hacer? Porque alguien las va a diseñar. Y si las diseña alguien sin formación en experiencia de usuario, el resultado va a ser exactamente el que todos podemos imaginar.
Esta segunda dimensión es, en mi opinión, la más transformadora. Y es la que prácticamente nadie está abordando en el mercado español, hasta donde conozco. Ni en conferencias, ni en formaciones, ni en las conversaciones de pasillo de los eventos del sector.
Tercera dimensión: trabajar usando IA
La tercera forma es la integración estructural. No se trata de usar una herramienta de manera puntual, sino de que la IA sea un componente nativo del proceso de diseño de principio a fin. Desde la fase de descubrimiento hasta la entrega a desarrollo.
Aquí estoy hablando de:
Automatización de tareas repetitivas
Generación de código desde el propio diseño
Testing automatizado de accesibilidad
Análisis predictivo de usabilidad antes de lanzar a producción
No es uso la IA cuando me acuerdo, sino que la IA está integrada en cada fase del ciclo de producto.
Esta dimensión exige un cambio de mentalidad operativa que va más allá de aprender a usar una herramienta. Requiere replantear procesos, flujos de trabajo y, en muchos casos, la estructura misma del equipo.
Por qué importa distinguir las tres
Cuando hablamos de IA y UX sin distinguir estas tres dimensiones, corremos el riesgo de quedarnos en la superficie. Una organización que sólo trabaja con IA ha dado un primer paso, pero no ha cambiado su modelo. Una que trabaja para la IA está creando valor en un mercado nuevo. Una que trabaja usando IA de forma estructural está transformando su forma de operar.
Las tres se necesitan. Las tres son complementarias. Pero la conversación pública se ha quedado atrapada en la primera.
Lo que me dijo el SOSZ sin decírmelo
Que casi nadie votase por esta temática no significa que no sea relevante. Significa que todavía no se percibe como urgente. Y eso, para quienes trabajamos en esto, debería ser una señal clara: hay una ventana de oportunidad enorme para quienes entiendan estas tres dimensiones y sepan aplicarlas antes de que se conviertan en el estándar.
Las conferencias del sector seguirán llenando salas con charlas sobre cómo usar ChatGPT o Claude para hacer research más rápido. Y está bien que lo hagan. Pero la conversación que de verdad va a marcar la diferencia en los próximos años es otra. Es la que tiene que ver con diseñar para sistemas inteligentes, no sólo con ellos.
Esa conversación, la que ayer no tuvo ni un voto, es la que voy a seguir planteando.
La semana pasada fue uno de esos momentos en los que el sector del diseño digital se puso de acuerdo en hablar de lo mismo. Google publicó una actualización importante de Stitch, su herramienta de diseño de interfaces enriquecida por IA, y la conversación ocupó timelines, muros de LinkedIn, chats de Slack y grupos de WhatsApp con una intensidad que pocas veces se ve fuera de los ciclos de grandes conferencias.
Quien ha seguido el ciclo de vida de Galileo AI desde sus inicios sabe que esto no ha salido de la nada. Lo que Google compró no era solo tecnología. Compró distribución, posicionamiento y una hipótesis: que el mercado de tooling de diseño iba a colapsar con el de desarrollo de frontend, y que quien controlase ese punto de unión tendría una ventaja enorme para llevar usuarios hacia Firebase, Flutter, Material Design y el resto del ecosistema de Google.
La adquisición fue, estratégicamente, pionera. Lo que vimos la semana pasada confirma que el movimiento era muy acertado.
Qué ha cambiado hoy: un repaso técnico
El anuncio, publicado en el blog oficial de Google el 19 de marzo de 2026, presenta lo que la compañía llama “vibe design”. No es solo un cambio de interfaz. Es un cambio de modelo mental sobre cómo se inicia y ejecuta un proceso de diseño.
Hasta ahora, Stitch funcionaba como un generador de pantallas por prompts. Útil para el primer 80% del trabajo de ideación, como bien apunta algún análisis, pero es claramente insuficiente para el resto. La actualización convierte Stitch en algo conceptualmente distinto: un **canvas infinito nativo de IA** donde el punto de partida no es ya una pantalla en blanco ni un sistema de componentes, sino el objetivo de negocio, la emoción que quieres provocar en el usuario o, directamente, los referentes visuales que te inspiran. Que es como piensan las personas, por cierto, no como piensan las herramientas.
Las cinco novedades principales que salieron la semana pasada son, y os las cuento en orden de impacto potencial en el flujo de trabajo real:
Canvas AI-nativo e infinito. El espacio de trabajo no es lineal. Imágenes, texto, código y diseños anteriores, si los hay, conviven en el mismo lienzo y actúan como contexto acumulado para el agente de IA. Esto es relevante porque rompe el modelo de «una prompt, una respuesta» y permite trabajar en divergencia y convergencia de ideas sin perder el hilo del proyecto.
Agente de diseño rediseñado con razonamiento sobre el historial del proyecto. El nuevo agente no sólo entiende el prompt actual, sino también la evolución completa del proyecto. Esto conecta directamente con cómo trabajan los diseñadores de verdad: con memoria del proceso, no sólo del estado actual.
Agent Manager. Permite lanzar múltiples direcciones de diseño en paralelo y mantenerlas organizadas. Para quien haya gestionado proyectos de diseño con múltiples stakeholders, la idea de explorar variantes simultáneas sin perder el control vale su peso en oro. Y no es metáfora.
Interacción por voz mediante Gemini Live. El canvas acepta comandos de voz para iterar sobre el diseño en tiempo real. No es un detalle menor: reduce la fricción entre el pensamiento y la ejecución, especialmente en fases de exploración donde escribir prompts interrumpe el flujo. Aunque bueno, personalmente es una de las features que menos me llama la atención.
DESIGN.md y prototipos interactivos. Aquí está, en mi opinión, lo más interesante desde el punto de vista de los sistemas de diseño. Stitch introduce DESIGN.md: un archivo en formato markdown que documenta las reglas del sistema de diseño (tipografía, color, espaciado, patrones de componentes) en un formato legible por agentes de IA. Puedes extraer ese sistema de diseño desde cualquier URL, exportarlo e importarlo en otros proyectos de Stitch o en herramientas de desarrollo como Cursor, Gemini CLI o Antigravity a través del servidor MCP (Model Context Protocol) que Google ha publicado junto a su SDK. Hay que reconocer que sonar, suena muy bien. Me falta algún tipo de estructura estandarizada o modelo de datos que permita hacer de este artefacto una palanca inoperable, pero esperaremos a ver cómo se desarrolla.
Combinado con la generación de prototipos interactivos (disponible desde diciembre del año pasado) y la exportación a React, esto completa una cadena que va desde el concepto hasta el código de producción sin salir de un mismo entorno integrado. Lo pongo en cursiva para mostrar mi escepticismo, aunque sea inicial.
Lo que esto significa para los profesionales de UX/producto
Seré directo: Stitch no reemplaza a un diseñador de experiencia de usuario. No tiene los datos de comportamiento, no tiene el contexto organizacional, no tiene la capacidad de síntesis cualitativa que viene de haber hecho investigación real con usuarios. Eso de momento sigue siendo nuestro territorio, y punto. Pero sí cambia algunas cosas de forma concreta.
El coste de exploración cae en picado. Prácticamente hasta ahora, construir tres propuestas de diseño alternativas como método de trabajo tenía un coste en tiempo que podía forzar decisiones prematuras. Con un canvas que genera y organiza variantes en paralelo, la exploración interna deja de ser cara.
El handoff diseño-desarrollo se comprime. Aunque aquí antes de explicarlo, hay que dejar claro que estamos ante una herramienta que en el estado actual de maduración no debería ser el artefacto que lleva código a producción. Dicho eso, la salida a HTML/CSS limpio, la exportación a React y la integración vía MCP con entornos de desarrollo hacen que la distancia entre el prototipo y el código producible sea, en muchos casos, cuestión de minutos. Quien lleva años trabajando en Design Systems sabe que el mayor coste no está en diseñar los componentes, sino en mantener la coherencia entre lo que vive en Figma y lo que vive en el repositorio. DESIGN.md puede ser un intento de resolver ese problema con una capa de abstracción legible por máquinas. Pero insisto, todo esto es de momento en condicional.
La accesibilidad como output, no como revisión.
La documentación de Stitch menciona que los modelos Gemini más recientes (desde la actualización de diciembre de 2025, que incorporó Gemini 3) mejoran la accesibilidad en las interfaces generadas. No he podido verificar en qué medida eso cumple con WCAG 2.2 o EN 301 549 en la práctica, así que lo tomo con cautela. Pero la dirección es la correcta, y eso no es poca cosa.
Lo que esto significa para quien no es diseñador pero quiere construir interfaces
Aquí es donde la conversación se pone más interesante, porque Stitch no está diseñado sólo para diseñadores.
El perfil del vibe designer que Google describe en su comunicación es alguien que quiere cerrar la distancia entre idea y realidad en minutos, no en días. Eso incluye founders en fases tempranas, product managers que necesitan visualizar una propuesta antes de escribir un brief, ingenieros que quieren mockups para stakeholders sin tocar Figma, y equipos de negocio que necesitan explorar flujos de usuario sin depender de un equipo de diseño con la agenda a tope.
Para ese perfil, Stitch es hoy la herramienta más accesible del mercado. Es gratuita y funciona directamente en el navegador. Todo el mundo puede entrar y empezar a usarla hoy mismo.
Pero hay algo más que me parece relevante destacar: la introducción de DESIGN.md como formato de sistemas de diseño portátiles abre una puerta conceptual importante para quienes están empezando a entender qué es un sistema de diseño y por qué importa en el escalado de aplicaciones.
Un sistema de diseño no es una librería de componentes bonitos. Es la codificación de las decisiones de diseño que garantizan coherencia, eficiencia y mantenibilidad a medida que un producto crece. Cuando tienes diez pantallas, puedes gestionarlo a mano. Cuando tienes doscientas, necesitas reglas. Claro, cuando esas reglas son legibles por agentes de IA y portables entre proyectos y herramientas, estamos hablando de algo ya más robusto.
DESIGN.md es un paso en esa dirección. Imperfecto, incipiente, pero conceptualmente correcto.
A modo de cierre
Lo que Google presentó la semana pasada con Stitch es una señal clara de hacia dónde van las herramientas de diseño de interfaces: canvas contextual, generación multimodal, sistemas de diseño como datos portables, y una cadena continua desde el concepto hasta el código deployable. Si además de todo eso el resultado fuese editable, estaríamos hablando de un cambio real.
Para los profesionales de UX, el reto no es si usar o no estas herramientas. El reto es decidir en qué parte del proceso aportamos el valor añadido que la herramienta no puede sustituir: la investigación, la síntesis, el criterio o la capacidad de hacer las preguntas correctas antes de generar cualquier pantalla.
Para quienes vienen de otros ámbitos y quieren acercarse al diseño de interfaces, Stitch baja la barrera de entrada de forma significativa. Pero la barrera que sigue siendo alta, y que siempre lo será, es la de entender al usuario.
Y eso no se genera sólo con un prompt, al menos de momento.
Ayer sábado estuve en el #SOSZ26, el Startup Open Space Zaragoza 2026. Un año más. Y ya van los suficientes como para que pueda hablar con criterio de lo que supone este evento, no sólo del que fue ayer, sino de lo que ha ido siendo y de hacia dónde apunta.
Arranque de las dinámicas en SOSZ26
Vamos por partes.
La sede: Hiberus confirma que no fue una casualidad
El año pasado fue la primera edición en la sede de Hiberus, fuera de Etopía, donde el evento se había celebrado con anterioridad. Un cambio de sede en un evento como un Open Space no es un trámite menor. Puede afectar a la logística, a la atmósfera y a la propia percepción del evento. En este formato, donde la experiencia lo es todo, el espacio importa más de lo que parece.
El año pasado salió bien. Muy bien. Y eso planteaba la pregunta lógica: ¿fue una buena edición a pesar del cambio, o fue porque Hiberus funciona de verdad? La respuesta ha llegado este año: Hiberus funciona de verdad.
Los cuatro espacios (Zaragoza, Huesca, Teruel, Salou) respondieron. La terraza con vistas a la ciudad (en este caso también a las obras de la futura Nueva Romaneda) hizo su trabajo durante la comida, con el tiempo colaborando como siempre. Hiberus está siendo una pieza clave para que este evento siga adelante, y desde mi punto de vista hay que decirlo con todas las letras.
La organización: trabajo invisible que no debería ser invisible
Detrás del #SOSZ26 hay un grupo de personas de la comunidad tecnológica de Zaragoza que pone su tiempo, su esfuerzo y sus recursos personales para que esto sea posible. No cobran por ello. Lo hacen porque creen en la comunidad.
A eso hay que llamarlo por su nombre: generosidad. Y hay que reconocerlo en público, porque es fácil dar por supuesto un evento que funciona bien, y difícil entender la cantidad de trabajo invisible que hay detrás.
El evento cuida los detalles. Tiene un código de conducta claro, que no es decorativo, sino funcional. Es un espacio en el que todo el mundo debería sentirse acogido.
Dicho esto, si me permiten una sola observación de mejora: las opciones para personas celíacas merecen más atención. La celiaquía no es una preferencia voluntaria, es una enfermedad. Y puestos a cuidar los detalles al máximo, ese es un recorrido de mejora que vale la pena recorrer.
En todo lo demás: 9,9 sobre 10 sin dudar.
El contenido: cuando el 35% del público propone conversación
Se presentaron más de 40 propuestas de conversación. Considerando que había en torno a ciento y pico personas, eso significa que aproximadamente un tercio de los asistentes propuso un tema. Un tercio.
Recuerdo ediciones en las que había que animar activamente a la gente para que se animase a presentar propuestas. Ayer eso no ocurrió. La gente llegó con los temas preparados, con ganas de participar, con criterio.
Eso es un indicador claro de la calidad de la audiencia. Y de la madurez del evento. No es casualidad.
Las conversaciones en las que estuve
Aquí viene la parte más personal, porque en un Open Space cada asistente vive su propia versión del evento. Esta fue la mía.
La primera sesión en la que me metí giraba en torno al liderazgo en entornos tecnológicos. Mi aportación principal fue que el liderazgo no se ostenta, se ejerce. Que de poco sirve tener la posición si luego no haces nada con ella. Es algo que en su momento fue un aprendizaje muy importante para mí, y que sigo creyendo que vale la pena repetir, porque lo obvio también necesita ser dicho.
Esta fue de las sesiones más concurridas. El título convocaba: algo así como si Figma estaba viviendo sus últimos días. La lideraron dos personas muy jóvenes y me gustó mucho su planteamiento. Fresco, sin complejos, bien estructurado.
Mis aportaciones fueron en dos direcciones. La primera: en la conversación apareció la tesis de que la mejor forma de probar un producto es lanzarlo rápido a producción y escuchar a los usuarios después. Eso hace veinte años ya fue tendencia. Lo pusimos en práctica. Y en muchos casos salió mal, porque el feedback cuantitativo nos dice el qué con rapidez y precisión, pero no el porqué. Si ignoramos el porqué, nos equivocamos en las soluciones. Lo hicimos como disciplina hace veinte años. La verdad es que no parecería razonable repetirlo.
La segunda: Figma muestra síntomas de fin de ciclo. No le veo una estrategia clara de integración de inteligencia artificial en el flujo de trabajo. Lo que le llevó a ser una herramienta hegemónica parece que lo está dejando atrás para ensanchar su base de usuarios hacia territorios que tienen necesidades distintas. Si me preguntáis cuándo empezó esto, os diría que con la fallida compra por parte de Adobe. Desde entonces, los movimientos de Figma me suenan a compañía que busca su siguiente capítulo sin tenerlo del todo claro.
Félix no es de la parte tech. Es emprendedor en hostelería, cortador profesional de jamón. Y llegó con dos mensajes que, dicho sin rodeos, deberían haber escuchado todos los que estaban en el evento.
El primero: que desde fuera, como alguien que no pertenece al mundo de los de la tecla (así nos llama), observa una capacidad para compartir conocimiento incluso entre competidores directos que no ve en otros sectores. Nos dijo que deberíamos valorarlo más.
Yo creo que hay algo de raíz en esto. Aragón ha sido históricamente tierra de pactos. En las Cortes de Aragón nunca ha habido mayoría absoluta, algo bastante singular en el contexto político que nos rodea. Esa cultura del acuerdo, de la convivencia entre diferentes, tiene algo de subconsciente colectivo. No creo que sea casualidad que aquí exista este nivel de espíritu colaborativo, y Félix lo señaló con precisión.
El segundo mensaje fue sobre cobrar. Llegó con su ropa de calle, luego se puso el delantal y nos dijo: ahora soy Félix Martínez, cortador profesional de jamón. El delantal era su señal de que está trabajando. Y cuando uno trabaja, cobra. Nos invitó a pensar en las señales profesionales que emitimos, o que no emitimos, y en la necesidad de poner el taxímetro en marcha.
Fue un mensaje sencillo y diría que también necesario. Fue la conversación más importante del día para mucha gente, aunque no todos estuviesen presentes para escucharla.
El título prometía una sesión más o menos convencional sobre ventas. No fue eso. Desde el principio tomó un cariz inesperado porque quien monopolizó el inicio fue alguien que compra, no que vende. Y no cualquier perfil de compra: una persona con un conocimiento técnico profundo, que quiere hablar con el desarrollador más friki, con quien le propone algo inesperado.
Lo que parecía un desvío fue en realidad una sacudida: nos obligó a reformular nuestros argumentos desde un terreno de juego exigente.
Yo expliqué mi forma de vender, que es orgánica, lenta y basada en compartir. Que yo empecé un blog en 2003 y a partir de ahí monté la empresa. Que dar genuinamente antes de pedir no es sólo un valor, sino que es también una apuesta estratégica inteligente, aunque sus frutos lleguen con el paso del tiempo. Lo que no dije en el momento, y lo pienso ahora: dar es estrategia.
El momento más bonito de esa sesión fue cuando un chico muy joven, alumno mío en la universidad, planteó tímidamente dónde podría dar visibilidad a su proyecto. La respuesta que recibió fue generosa, cercana y directa: lo que estás haciendo ahora mismo, preguntar esto aquí, ya es visibilidad. El resto de la sala le respondió como lo hace esta comunidad.
Esta fue la sesión más intensa. La tesis de partida de Saul era que el empleo tech se está deteriorando: vuelta a la presencialidad, reducción de salarios en nuevas posiciones, presión sobre quienes no están en Madrid o Barcelona, desequilibrio creciente entre coste de vida y remuneración derivada en las grandes ciudades.
Hubo de todo: perfiles junior, senior, procedencias distintas, posiciones distintas. El debate que Saul propuso se encontró con un debate que le desbordó un poco, lo cual es comprensible porque el tema no deja a nadie indiferente.
Mi tesis fue sencilla: quizá estamos evitando pronunciar la palabra crisis. Hablamos de que todo va más despacio, de que cuesta más cerrar operaciones o de que el contexto es incierto. Pero a lo mejor el problema no es la descripción, sino que le falta el nombre. Y el nombre es crisis. Una crisis potenciada por la incertidumbre geopolítica, por la inteligencia artificial reordenando el mercado laboral, por preguntas que no tienen respuesta todavía.
La última sesión en la que estuve fue sobre investigación con usuarios en el contexto de la inteligencia artificial. Concurrida, en el Espacio Zaragoza, con muchas voces.
Mis aportaciones fueron escépticas, o al menos matizadas. Hay una narrativa que dice que la IA ha transformado radicalmente el research: más rápido, más barato, más accesible. Puede ser. Pero las grandes corporaciones, en su mayoría, no han modificado sustancialmente su forma de hacer investigación. Y eso debería hacernos pensar.
Hay dos vectores que conviene no olvidar. Primero, los mandatos corporativos: muchas organizaciones no permiten usar las herramientas de IA que están disponibles en el mercado, por una cuestión simple de política interna. Eso condiciona lo que se puede hacer. Segundo, el marco legal: protección de datos, tratamiento de información de usuarios, lo que se puede y lo que no. Nuestra experiencia profesional nos lleva constantemente a pruebas de concepto que se ven truncadas por estos factores. No digo que la IA no cambie el research. Digo que el laboratorio de ensayos y la producción real son lugares distintos. Y conviene no confundirlos.
Tres aproximaciones distintas, con implicaciones distintas, que me parecen importantes precisamente porque no son intercambiables ni equivalentes. Obtuvo uno o dos votos. No hubo conversación.
No lo digo como queja. El formato Open Space funciona así, y funciona bien: la comunidad vota y el resultado es el programa. Pero el hecho de que esa distinción no despertase interés suficiente me ha generado una reflexión que publicaré estos días en el blog. A veces lo que no ocurre en un evento dice tanto como lo que sí que ocurre. Me pregunto si esa diferenciación es aún demasiado conceptual para una audiencia que está en modo práctico, o si simplemente el título no convocó lo suficiente. Cualquiera de las dos respuestas me interesa.
Por qué sigo viniendo y seguiremos patrocinando
El #SOSZ26, como todas las ediciones anteriores, es para mí un evento indispensable. Junto con la TRG en Madrid, son los dos eventos de comunidad que considero fundamentales.
Los eventos de comunidad son difíciles de construir y fáciles de perder. Las empresas deberíamos contribuir a sostenerlos, porque el retorno no siempre es medible, pero siempre es real. Estoy contento de que Torresburriel Estudio haya vuelto a patrocinar este año. Y nada nos impedirá seguir haciéndolo.
La comida en la terraza de Hiberus, el networking sin forzar, la cena en La Garnacha como colofón. Todo eso también forma parte del evento. No es ni de lejos accesorio. Es parte de lo que hace que la gente venga un sábado, de cerca y de lejos, pagándose el viaje y el alojamiento, y salga pensando que ha sido un sábado bien empleado.
Pongamos en la situación verosímil. Llevas décadas trabajando en tu campo. Tienes proyectos, clientes y reconocimiento. Gente que te cita, que sigue tu trabajo y que va a escucharte. Aun así, antes de entrar a una reunión importante, antes de subir a un escenario, hay ese momento: la boca seca, el corazón acelerado y la maldita voz interior que te susurra ¿y si no estoy a la altura?
Ilustración del magnífico Hugo Tobio
Eso tiene nombre: síndrome del impostor. Y lo que nadie te dice es que los años de experiencia no lo eliminan. Lo que cambia, si trabajas en ello, es tu relación con él.
La trampa de creer que los expertos no tienen miedo
Hay una imagen bastante extendida del profesional senior que entra a cualquier sala con total seguridad, sin dudas y sin nervios. Dominando y controlando la situación. Bien, permitidme estropear la foto. Es una ficción. Lo que distingue a alguien con trayectoria no es la ausencia de inseguridad, sino la capacidad de actuar a pesar de ella. Y ese escenario es totalmente distinto.
El síndrome del impostor no es señal de incompetencia. Además podemos constatar, la investigación sugiere lo contrario: quienes lo experimentan con más intensidad suelen ser personas con altos estándares, muy conscientes de lo mucho que aún no saben. Es el precio de seguir aprendiendo.
Lo que sí puedes cambiar
La primera palanca es cognitiva: distinguir entre el miedo al fracaso y la evidencia real de tu trayectoria. Cuando la voz interna te dice no eres suficiente, vale la pena preguntarle: ¿en qué se basa eso? ¿Qué datos tienes? Normalmente, los datos apuntan en la dirección contraria. Esa es una primera señal.
La segunda palanca es conductual: actuar antes de sentirte preparado del todo. La confianza no llega esperando a tenerla sino que más bien llega actuando. Cada presentación, cada propuesta que defiendes, cada conversación difícil que afrontas, es una pequeña prueba que actualiza la imagen que tienes de ti mismo.
La tercera palanca, y quizás la más subestimada, es la del contexto. El síndrome del impostor se alimenta del aislamiento: creer que eres el único que siente esto. Parece claro que hablar con colegas de confianza sobre estas inseguridades suele ponernos sobre el espejo de que son universales.
Una paradoja que vale la pena sostener
Cuanto más sabes de algo, más ves lo que no sabes. Eso puede leerse como debilidad, o puede leerse como precisamente lo que te hace valioso: tienes la madurez suficiente para comprender la complejidad real de tu campo.
La humildad que nos hace conscientes de esa conciencia de los propios límites, no es lo contrario de la competencia. Es una forma sofisticada de ella.
Lo que me ha funcionado a mí
Antes de una situación de alta exposición, me ayuda recordar el recorrido, no el destino. No ¿soy suficientemente bueno para esto?, sino ¿qué he hecho que me ha traído hasta aquí? La respuesta, cuando eres honesto contigo mismo, casi siempre es más sólida de lo que el síndrome del impostor quiere que creas.
Y luego, sencillamente, también hay una cuestión de tomar la decisión de empezar. Porque una vez que empiezas, el miedo se transforma en algo más manejable: presencia, atención, energía. Los primeros segundos son los más duros. Lo que viene después suele ser lo que sabes hacer.
Esto que parece por momentos un manual de autoayuda, está basado en la experiencia personal de este que escribe. Quizá hablar en tercera persona es un escudo protector de la inseguridad que aún queda, incluso por reconocerlo.
Llevo meses usando una aplicación que me he hecho yo mismo. Se llama Alba Tracker y sirve para registrar mis sesiones de ejercicio matinal. Nada sofisticado: caminar, correr, andar en bici pública. Duración, distancia, alguna nota si me apetece. Eso es todo.
La he construido con Mocha, una herramienta de lo que ahora llamamos Vibe Coding. Escribes lo que quieres, la herramienta genera código, tú lo revisas, ajustas, vuelves a pedirle cosas. Un diálogo iterativo entre tu intención y la capacidad técnica de la máquina.
Lo interesante no es la aplicación. Es lo que pasa cuando la construyes.
El descubrimiento de los pliegues
Cuando diseñamos interfaces, pensamos en flujos, en jerarquías, en estados, en feedback visual. Es un trabajo que dominamos. Pero cuando construyes el producto entero, aparecen cosas que desde el diseño no se ven.
Por ejemplo: la autenticación con Google dejó de funcionar y la pantalla se quedaba en blanco. El problema estaba en un worker de Cloudflare que no exportaba correctamente un endpoint. Palabras que hace cinco años me habrían sonado a chino y que ahora, gracias a estas herramientas, puedo entender, empezar a diagnosticar y resolver con ayuda.
O el cálculo de calorías. Implementarlo significa definir fórmulas específicas según el tipo de actividad, almacenar el peso del usuario, recalcular datos históricos cuando cambia ese peso o mostrar todo eso en la interfaz sin que haga ruido. Son capas que desde Figma no podemos ver porque no existen.
Cada funcionalidad tiene sus recovecos. La paginación de resultados. El modo oscuro automático según la configuración del sistema. El favicon, la imagen para compartir en redes sociales, el orden cronológico de las sesiones. Decisiones que parecen menores pero que, sumadas, definen si un producto suena bien o parece descuidado.
Lo que cambia cuando ves la cocina
Construir producto con estas herramientas no te convierte en desarrollador, ni mucho menos. Pero te da algo muy valioso: la capacidad de entender qué pasa debajo del capó. Y eso tiene consecuencias directas para tu trabajo de diseño. Lo dijo Freddy Vega el otro día.
Más adelante, cuando entiendes que una funcionalidad implica tocar la base de datos, crear migraciones, gestionar estados de error, la forma de proponerla cambia. No la simplificas por miedo técnico, pero tampoco la complicas de manera innecesaria; ni de lejos. En realidad lo que pasa es que adquieres criterio sobre lo que cuesta y lo que implica hacer las cosas.
También empiezas a ver el producto como un sistema vivo. Alba Tracker tiene un changelog que documenta su evolución: primero la estructura básica, luego el modo demo para probar sin registro, después las estadísticas en tiempo real, más tarde las calorías, la bici pública o las mejoras de layout móvil. Cada iteración resuelve algo que la anterior dejó pendiente.
Eso es pensar en producto. No es sólo diseñar pantallas, es diseñar un sistema que evoluciona.
El conocimiento como piedra angular
Hay en todo esto una trampa fácil: pensar que estas herramientas van a sustituir a los profesionales o que cualquiera podrá hacer lo que hacemos nosotros.
Mi experiencia dice exactamente lo contrario.
Mocha genera código. Pero cada decisión que tomé durante la construcción de Alba Tracker venía de mi conocimiento de diseño:
Por qué los botones de acción tienen el tamaño que tienen en móvil
Por qué la información se agrupa de esa manera
Por qué el pie de página existe
Por qué hay un modo demo que permite probar antes de registrarse
La herramienta acelera la ejecución. La intención sigue siendo humana. Y la posibilidad de que todo estalle si el código no se audita, también.
Y eso es lo importante: el qué construir, para quién, y por qué. Esas preguntas no las responde ninguna IA. Las respondemos los profesionales que llevamos años observando usuarios, entendiendo contextos, diseñando sistemas de información.
Las herramientas pasan. Los criterios permanecen.
Mayor valor, mayor control del outcome
Lo que me ha dado construir Alba Tracker con Mocha es algo muy concreto: control sobre el resultado.
Antes, mis ideas de producto dependían de que alguien las desarrollara. Ahora puedo iterar directamente sobre el producto. Ver que algo no funciona bien en móvil y arreglarlo en el momento. Probar una funcionalidad, descartarla si no aporta o incorporar otra que no había previsto.
Ese ciclo corto de feedback me resulta tremendamente valioso. Y genera un tipo de eficiencia que no tiene que ver con ir más rápido, sino con ir más directo al objetivo.
No es magia, es herramienta
Conviene de todos modos bajar las expectativas. Construir Alba Tracker me llevó iteraciones, errores, correcciones y replanteamientos (además de bastantes cabreos y sensación de que por momentos esto se me iba de las manos). La herramienta no adivina lo que quieres. Tienes que saber pedirlo. Tienes que revisar lo que genera. Tienes que tener criterio para decidir si lo que ves está bien o necesita ajustes. Es decir: tienes que saber de lo tuyo.
Estas herramientas amplían lo que ya sabes hacer. Pero si no sabes nada, amplifican ese vacío y se te ven las costuras. Un diseñador con criterio puede construir productos coherentes. Alguien sin criterio generará código que aparenta funcionar pero que no tiene sentido.
La diferencia no está en la herramienta. Está en quién la usa y cómo.
Una invitación
Si eres diseñador y no has probado a construir algo completo con estas herramientas, te lo recomiendo. No para convertirte en otra cosa, sino para entender mejor lo que ya eres. Pensar en producto tiene muchos pliegues y muchos matices. Algunos sólo se ven cuando te manchas las manos. Y mancharse las manos, ahora, es más accesible que nunca.
Alba Tracker es una aplicación pequeña para un problema pequeño. Pero construirla me ha enseñado más sobre producto que muchos proyectos profesionales de mayor envergadura en los que tenía una capacidad de intervención distinta.
A veces, lo valioso no está en la escala sino que está en la profundidad del ejercicio.
Llevo al menos un par de años largos buscando la aplicación de notas perfecta. Y no la he encontrado. Pero sí que he llegado a una conclusión que, aunque no es brillante, es honesta: la mejor app de notas es la que ya tienes y la que usas de verdad. Pasa mucho en la vida que la solución para lo que andamos buscando con mucho ahínco la tenemos delante de los morros y no lo vemos.
Notion se convierte en un proyecto en sí mismo. Acabas diseñando el sistema en lugar de tomar notas.
Craft me gustaba mucho, es bonita y versátil, pero va incorporando funcionalidades que ni quiero ni necesito. Y eso me tira para atrás.
Obsidian es potente, pero requiere una dedicación que no tengo.
Ulysses y Vim cumplen, pero no resuelven todo.
Al final me había quedado con Craft porque funciona razonablemente bien en el ecosistema Apple y tiene acceso web que también funcionaba bastante bien. Pero el rendimiento no me convencía del todo. Y no era solamente el tema de rendimiento, sino que era un tema de exceso de funcionalidades añadidas. Y que tiene de todo, que se puede hacer de todo y eso a veces me despista del objetivo inicial. Un día escribiré con más calma sobre Craft, porque merece mucho la pena.
La app que siempre estaba ahí
Y entonces, como siempre, lo que pasa es que vuelvo a las Notas de Apple. En otras razones, hay una muy poderosa y es que ahí está mi archivo histórico. Además de eso, porque funciona sin fricción en todos mis dispositivos. Y sobre todo, porque no me obliga a pensar en la herramienta, sino que me deja pensar en lo que estoy escribiendo.
¿Es perfecta? No. Me encantaría poder compartir una URL directa a una nota, por ejemplo. Pero si eso no puede ser, pues no puede ser.
La herramienta es lo de menos
La conclusión a la que casi siempre llego, es que a veces confundimos buscar la herramienta perfecta con evitar el trabajo real. Y al final, lo que necesitamos es tomar notas, no gestionar una app de notas. Con lo que Apple me da, es suficiente. Y cuando algo es suficiente, lo inteligente es quedarse.
Hasta que llegue otra súper novedad, que llame mi atención y quizá, esta vez sí, la deje pasar de largo para centrarme en lo que quiero escribir.
