Categoría: Diseño

Es curioso, porque hoy me ha pasado algo que he leído primero en Twitter y después he experimentado, y se me ha quedado cara de: Daniel, te empeñas en pensar que las cosas solo les pasan los demás, y luego eres el siguiente en experimentarlo. Me estoy refiriendo al desorbitado consumo de tokens del último modelo de Claude del que todo el mundo está hablando: Flabe 5.

Los resultados son impresionantes

Es cierto que el modelo es espectacular, funciona muy bien, los resultados que se obtienen son sorprendentes y espectaculares, y todo eso es directamente proporcional al consumo de tokens. Eso me ha llevado corriendo a Twitter para escribir el típico tuit:

Y claro, como me solía pasar hace muchos años, y hoy he de reconocer que me ha reconciliado un poco con la plataforma (pero solo un poco) la posibilidad de ver enriquecida mi iniciativa con algunas de las respuestas. Y es cierto que de alguna forma la dopamina de las redes sociales se está quedando en Barrio Sésamo si lo comparamos con la sensación parecida a la adicción que se experimenta cuando te quedas sin tokens y hay que esperar unas horas, de manera en comprensible porque para eso te estás dejando una pasta gansa en la mensualidad de Claude.

Vamos a abrir (más) la cartera

Esto me lleva a pensar que estamos más cerca de ese momento, que a más de una persona y más de dos les he compartido, que llegará puede que pronto: vendrá el LLM de confianza, nos pedirá 500 € al mes por el uso de una herramienta avanzada y potente, y se los entregaremos sin pensarlo demasiado.

Lo más curioso de todo es que esto ya no me escandaliza. Lo estoy viendo en términos de valor entregado. Y me deja pensando, las cosas como son.

Hoy he tenido uno de esos días tremendamente ocupados, pero a última hora me he encontrado con una noticia que, a primera vista, parece de gestión sanitaria pura y dura: el Gobierno de España ha aprobado eliminar el cupón precinto de los medicamentos y sustituirlo por un identificador digital. Confieso que me he quedado un rato pensando en ella mientras miraba anonadado el titular, porque esto no es una noticia de farmacia. Esto es diseño de servicios. De libro. Vamos a por ello.

Qué es el cupón precinto y por qué desaparece

Para quien no lo sepa (si es que hay alguien que de verdad aún no lo sepa): hasta hoy, cada vez que una farmacia dispensaba un medicamento financiado por el Sistema Nacional de Salud, la persona que en la farmacia nos atendía tenía que recortar físicamente un cupón del envase, pegarlo en una hoja (normalmente con celo) y enviar esa hoja al Colegio de Farmacéuticos como justificante. Recortar, pegar, enviar. Miles de veces al día, en miles de farmacias, durante décadas. La ministra de Sanidad lo ha resumido en rueda de prensa con una frase que me parece un titular estupendo: adiós al cúter y a las pegatinas.

Y aquí es donde quiero detenerme, porque llevo años diciendo (y diciéndolo en el Estudio, y en clase, y donde me dejan) que la experiencia de usuario no empieza ni termina en una pantalla. El cúter era una interfaz. Las pegatinas eran una interfaz. Todo ese trabajo invisible que ocurre detrás del mostrador, lo que en diseño de servicios llamamos backstage, condiciona directamente el servicio que la persona sí ve. Cada minuto dedicado al cúter es un minuto que no se dedica a atender a quien está al otro lado del mostrador.

Una lección de diseño de servicios más allá de lo digital

Hay un par de detalles de la reforma que me parecen especialmente interesantes desde la perspectiva del diseño:

1. No han añadido nada. Han quitado. El identificador único ya existía en los envases por la normativa europea de verificación de medicamentos (PDF). Lo que se ha hecho es aprovechar una infraestructura que ya estaba ahí para eliminar un proceso manual redundante. Quitar es, casi siempre, la decisión de diseño más difícil de tomar. Añadir queda muy bien en las presentaciones; quitar nos obliga entender el sistema entero.
2. La transición también está diseñada. Ambos mecanismos van a coexistir hasta que las comunidades autónomas estén preparadas desde un punto de vista operativo, que esa es otra. Esto, que parece un tecnicismo, es diseño de servicios de manual. Quien haya trabajado en transformación de servicios sabe que los proyectos no fracasan en el diseño del destino, sino en el diseño del camino.

Lo mejor de todo es que la persona que mañana vaya a recoger su medicación no va a notar absolutamente nada. Bueno s´í, que el servicio será más rápido. Y precisamente por eso el cambio es bueno. Tenemos en este sector una tentación enorme de hacer visible el diseño, de que se note. El buen diseño de servicios suele ser invisible. Y las personas que trabajan en las farmacias, con total seguridad, lo agradecerán.

Así que tomemos nota: el diseño de servicios no es una disciplina digital, es una disciplina de sistemas. A veces el mejor entregable no es una pantalla nueva. Es un cúter que se deja de usar.

Este fin de semana ha sido un fin de semana bastante intenso. No porque haya tenido aventuras extraordinarias, sino más bien porque lo que he tenido han sido unas sesiones de estudio largas, intensas y bastante valiosas. Menos mal que con la tele y con las redes sociales he podido estar bastante al tanto de todo lo que ha ido sucediendo, que no es poco.

Pero por aquí venía a contar que he sacado un poco de tiempo para ventilar un poco mis neuronas y migrar de plataforma la aplicación Linkwise, que en su momento estuve construyendo para paliar de alguna forma la tristeza que desde hace tiempo dejó la desaparición de del.icio.us en mi vida digital.

La inminente desaparición de Mocha me ha llevado a migrar a Lovable la aplicación y la verdad es que el proceso, lejos de ser tortuoso, ha sido bastante sencillo. Eso sí, he aplicado lo que podríamos denominar ingeniería social por encima de técnica a la hora de la estrategia de migración. Pero oye, dicho y hecho.

Cómo migrar una aplicación de Mocha a Lovable

Estos son los pasos que he dado para llevar a cabo la migración entre plataformas. Spoiler: ha salido bien.

1. Bajarme todo el código de la aplicación comprimido para dárselo a Lovable como contexto.
2. Darle a Lovable también como contexto el histórico de los prompts que me llevaron a construir la aplicación. Eso es algo que siempre guardo.
3. Hacer una copia de la base de datos en producción, que nunca se sabe.
4. Dejar que la magia suceda.
5. Redireccionar el dominio a la nueva plataforma.

También he aprovechado a hacer algún ajuste, especialmente en el diseño de los tags en la vista mobile, que empezaba a desmadrarse.

El resultado ha sido mucho más que digno. Se puede ver en linkwise.torresburriel.com.

Me gusta mucho empezar a escribir un post por el principio. Esto puede parecer una obviedad pero es que lo que me gusta es escribir el título del post al final. Básicamente porque yo sé cómo empiezo a escribir pero hay veces que el propio texto me lleva a otros territorios y entonces tengo que cambiar el título original, si es que he empezado por ahí.

En realidad hoy creo que no hace falta, porque tengo muy claro de lo que voy a escribir: quiero contar lo que ya estamos haciendo en mi empresa con inteligencia artificial. Parece sencillo, pero no lo es tanto, porque aquí se trata no de teorizar, sino de recopilar, sintetizar y compartir lo que ya estamos trabajando. Es decir, voy a hablar en pasado y en presente.

No vendemos IA, vendemos criterio sobre dónde y cómo aplicarla.

Podría terminar aquí el post porque la cita anterior resume perfectamente lo que quiero contar. Pero quiero entrar en detalles.

La IA no sustituye, redistribuye el trabajo

O lo que es lo mismo, mucha gente ha entrado directamente en la conversación del miedo a la inteligencia artificial, pero deberíamos hablar más bien de redistribución del trabajo. Las cosas las vamos a hacer de otra manera y quizá también haya cambio de roles y de personas.

Tenemos internamente un evento en marcha llamado “Los días de IA”, que es una iniciativa semanal donde cada miembro del equipo presenta ante toda la organización un caso real de aplicación de IA en su trabajo. Tenemos ya cuatro sesiones completadas: Mindful Journal, herramientas de research, Notebook LM aplicado a formación, y un agente de Codex. La quinta sesión la tenemos confirmada sobre optimización de tokens.

Hemos sistematizado la documentación de cada sesión en doce bloques canónicos, en markdown y Word con la plantilla corporativa, para que el conocimiento no se quede en la persona que lo presenta y se pueda reutilizar.

En el caso del agente de Codex, el sistema está desplegado y disponible para todo el equipo del repositorio, es decir, no es una herramienta individual. Lo hemos hecho así a propósito para evitar que distintas personas construyan agentes paralelos y dispersen recursos.

Cada rol del Estudio está redefiniendo cómo aplica la IA en su área: research, producto, formación, ingeniería y dirección. Las decisiones sobre qué herramienta usar y cómo integrarla en el flujo se toman desde cada disciplina, no desde una directriz vertical.

El criterio es el activo y se entrena con los años

Trabajamos los prompts iniciales fuera de la herramienta de construcción elegida, con el apoyo de un LLM aparte (Claude o Gemini) que ayude a dar exactitud al enunciado antes de empezar a ejecutar. Después lo refinamos dentro del constructor.

Aplicamos criterio de dirección de diseño desde el primer prompt, es decir: paleta, tipografía, modelo de interacción, gestión del error y tono. En el caso de Mindful Journal, instrucciones como “tono europeo, azules, sin remates” sustituyeron a la estética genérica que devuelve la herramienta por defecto.

Aproximadamente el 80% de las conversaciones de dirección con clientes, futuros clientes y partners pasan por un LLM antes de salir hacia afuera: para clarificar puntos, alinear estrategias y priorizar objetivos, tanto a nivel de contenido como de forma.

Distinguimos de manera explícita y transparente entre dos tipos de agente:

• Los que tienen reglas cerradas y resultado seguro (pueden lanzarse con un trigger automático).
• Los que operan sobre contexto sensible de cliente (necesitan supervisión humana en cada ejecución).

Esa distinción se documenta en el gobierno de decisiones del propio agente.

El coste de explorar se ha desplomado, y eso lo cambia todo

No nos quedamos cruzados de brazos ni nos lamentamos:

Tenemos un stack de construcción rápida activo y en producción: Replit, Lovable, Google AI Studio, v0, Mocha (hasta hoy, que han anunciado que lo cierran). Cada herramienta sirve a un objetivo determinado y concreto, y elegimos la adecuada según el tipo de salida que va a tener (web vs. app móvil, prototipo vs. producto desplegable).

Las herramientas de assessment (madurez ResearchOps, índice de madurez UX) están planteadas como fabulosos activos comerciales: entregan valor al usuario antes de la primera conversación y por detrás alimentan el CRM con leads cualificados por nivel de madurez.

El planteamiento de cada propuesta a cliente parte del marco “pieza pequeña y acotada como entrada”: un AI Readiness Assessment antes de proponer la suite completa. Lo hemos probado ya en 5 presentaciones a clientes corporativos.

La verificación es rápida pero obligatoria

Quien piense que esto es copiar y pegar o que las automatizaciones funcionan solas sin intervención humana, tiene un problema de comprensión.

Notebook LM opera siempre sobre fuentes cerradas que seleccionamos previamente: guías metodológicas, informes de años anteriores, materiales propios y webs específicas. Nunca con acceso libre a internet. Cada respuesta del sistema en Notebook LM tiene asociada una cita verificable al documento y párrafo de origen, accesible con un clic. La revisión la hacemos contra la fuente, no contra la intuición.

El agente de Codex está construido sobre un sistema de 7 archivos que estructura toda la operación: rol del agente, estándar de implementación, contrato de entradas y salidas válidas, checklist de acciones obligatorias, lógica de testing, ejemplos de referencia y gobierno de decisiones. El agente ajusta los tests en el mismo momento en que modifica el código, de manera que la verificación es inherente al proceso, no un paso posterior que pueda olvidarse. Si un test falla, falla antes de que la migración se considere completada.

Tenemos Atlas, el repositorio interno de insights de research, como fuente de verdad consultable para las herramientas de IA que trabajan sobre conocimiento del Estudio.

La accesibilidad la trabajamos desde el prompt

Las herramientas de assessment las hemos construido sobre WCAG 2.2 desde el primer prompt, con instrucciones explícitas sobre tabulación, area-labels para lectores de pantalla, contrastes y orden de foco. No lo hemos añadido después.

Trabajamos el responsive con atención específica a dispositivos móviles : ya que los constructores no resuelven los tres breakpoints a la vez, tenemos que indicar expresamente qué versión corregir y verificar el comportamiento en cada una.

Cuando hemos generado interfaces con vibe coding hemos aplicado contraste verificado WCAG AA desde el principio.

Ofrecemos el Módulo 2 del AI Experience Suite (AI Experience Audit) como servicio comercial específico para auditar la usabilidad de funcionalidades de IA ya integradas en producto de cliente. Varios de los clientes corporativos a los que hemos presentado el módulo han reconocido tener funcionalidades de IA en producción que sus usuarios ignoran.

Los prompts iniciales los trabajamos en inglés para incurrir en un menor consumo de tokens y en línea con estudios sobre la influencia del idioma en la precisión del modelo. Lo hace el equipo de research y también el equipo de ingeniería para el afinado del agente.

En resumen, os he dicho que este post habla en pasado y en presente. Habla de lo que hacemos y es algo que, mea culpa, no teníamos documentado y aquí está.

Llevo un mes trabajando, a ratos sueltos, en un proyecto personal que no tiene ambición comercial. Se llama Mindful Journal y vive en mindful-journal.app. Es una aplicación para escribir, para pensar, para reflexionar, para darse tiempo y para cuidarse. A veces también para darse unos cuantos latigazos cuando toca, que tampoco se trata de un ejercicio constante de complacencia con uno mismo.

La he construido probando el framework de Replit y he aprendido bastante por el camino.

Por qué un diario

Tampoco es una idea original. Llevar un diario es una práctica con siglos de recorrido y la literatura sobre sus efectos en el bienestar emocional es abundante. Lo que me interesaba era otra cosa: si el acto de escribir, de detenerse a pensar y de revisar lo escrito en perspectiva tiene valor, ¿por qué la mayoría de aplicaciones que existen para esto se plantean o como redes sociales encubiertas, o como herramientas de productividad disfrazadas de bienestar?

Quería algo distinto. Una herramienta que parte de una convicción sencilla y muy personal: escribir sobre uno mismo hace bien. Sin terapia, sin programa estructurado, sin método infalible. Solo un espacio privado, seguro y propio, donde volcar pensamientos, registrar emociones y, con el tiempo, empezar a ver patrones que quizá nunca habías notado.

Vivimos en una cultura que mide, optimiza y acelera. Que pide resultados rápidos y visibles. Qué lío todo. El bienestar emocional no funciona así. No hay una guía de pasos ni hay un resultado que alcanzar en una fecha concreta. Uno lo va descubriendo con el uso, con el lápiz, con el silencio cuando toca silencio.

Los principios que he intentado mantener

He trabajado con cuatro principios de fondo, no como mantras sino como criterios para decidir.

El primero, bienestar, no rendimiento. No hay puntuaciones que mejorar, ni hay metas que cumplir, y por supuesto no hay rachas que defender. Escribir ya es el acto en sí. Si una decisión de diseño no contribuye a que la persona se siente, escriba y luego pueda revisar lo escrito, sobra.

El segundo, privacidad radical. Las entradas son del usuario. Solo del usuario. Sin anuncios, sin análisis externos, sin entrenamiento de modelos a costa de lo que la persona ha decidido confiar a la aplicación. Y sin la posibilidad de compartir. Esto se traduce en cumplimiento estricto de GDPR, declaración de accesibilidad, política de privacidad, aviso legal y un DPO real, que soy yo mismo a través de Torresburriel Estudio. Si una aplicación pretende ser un espacio seguro para volcar lo emocional, lo mínimo es que el marco legal acompañe.

El tercero, sin fricción. Abre, escribe y cierra. La herramienta tiene que desaparecer para que lo que quede sea la persona y lo que ha escrito. He pensado  en esto al diseñar las prompts de escritura, que aparecen en el idioma elegido por el usuario, son rotativas y están redactadas para invitar, no para imponer. Y también al decidir que la página de resultados deje de ser scroll infinito a partir de los diez registros, porque en una aplicación que pretende reducir la ansiedad, el scroll infinito es enemigo declarado.

El cuarto, autenticación seria. He decidido que la entrada se hace mediante Google OAuth. Soy consciente de que esto deja fuera a quien no tiene o no quiere usar una cuenta de Google. Lo he sopesado. La alternativa habría sido construir un sistema de autenticación propio, con su recuperación de contraseñas, sus correos transaccionales y las incidencias de soporte. Un rollo que ahora mismo no he querido afrontar. Para un proyecto personal y para una aplicación cuyo valor reside en la confianza, he preferido apoyarme en un mecanismo robusto antes que improvisar uno inferior.

El agradecimiento como ancla

Hay una pieza que me parece central y que merece párrafo aparte: la nota de gratitud.

No la he metido como obligación, sino como invitación. La investigación en psicología positiva lleva décadas documentando el efecto del agradecimiento en el estado de ánimo, la resiliencia y la capacidad de atención plena. Y en una aplicación de escritura reflexiva, dejar fuera ese ángulo habría sido empobrecer mucho el producto.

Anotar aquello por lo que uno agradece, algo pequeño, algo cotidiano, no cambia la realidad. Pero hace algo mejor: entrena la mirada. Y una mirada entrenada en lo que sí hay, en lugar de en lo que falta, transforma poco a poco la experiencia de estar. La sección de análisis recoge los agradecimientos en perspectiva, porque revisarlos en bloque, semanas después de haberlos escrito, tiene un efecto distinto y complementario al de escribirlos en el momento.

Lo que ha pasado por el camino

He iterado sobre el producto en sesiones cortas, prácticamente todas a través de prompting con la herramienta. He pedido cosas concretas y he ido revisando lo que la herramienta entregaba. Hasta ahí todo normal. Hasta me he quedado sin tokens. El mundo moderno.

Algunas iteraciones han sido de fondo. Por ejemplo, el momento en el que decidí que la aplicación tuviera registro de usuarios y persistencia de datos por persona, en lugar del estado público inicial. O cuando trasladé el dominio personalizado y descubrí, tras hacer login, que los datos previos no estaban accesibles desde el nuevo dominio, lo que me obligó a entender bien cómo se gestiona la migración de bases de datos en este tipo de despliegues.

Otras iteraciones han sido de detalle pero para mi igual de relevantes:

• Que los prompts de escritura aparezcan en el idioma del usuario y no solo en inglés.
• Que el footer recoja con claridad el aviso legal, la declaración de accesibilidad, la política de privacidad y la información sobre el autor y el proyecto.
• Que el diseño visual tenga un sesgo más europeo, con predominio de azules y sans serif para lo que dirige la acción, en lugar de la convención cómoda de pasteles y tipografías redondeadas que tanto abunda en aplicaciones de bienestar.

Qué he aprendido construyéndola

He aprendido que el framework de Replit es razonablemente potente para llevar una idea a producto sin tener que ensamblar veinte herramientas distintas. También que sigue y seguirá habiendo decisiones que requieren criterio profesional y que ninguna herramienta toma por ti: qué arquitectura de información tiene sentido, qué piezas legales son obligatorias y cuáles convenientes, cuándo un módulo es funcionalidad y cuándo es ruido.

He vuelto a comprobar, una vez más, que vibe coding sin criterio es vibe coding sin destino. La herramienta acelera pero, de momento, no decide. La diferencia entre un producto digno y uno mediocre sigue estando en quién decide qué se construye, para quién y por qué.

Y he confirmado lo que ya intuía: que construir cosas pequeñas, con intención y para uno mismo, sigue siendo una de las formas más honestas de aprender. No hay informe de cliente, ni tablero de KPIs, ni revisión de stakeholders. Solo la pregunta, repetida cada vez que tomas una decisión, de si esto que estás haciendo merece la pena.

Mindful Journal no pretende estar terminado, no creo que lo esté. Es como el propio proceso de conocerse a uno mismo, está en construcción permanente. Se nutre de la experiencia de quienes lo usan, de lo que se echa en falta, de lo que sobra. Es una aplicación para parar. Construirla ha sido, paradójicamente, una forma de no parar de pensar.

Es viernes y me iba a poner a preparar un artículo para este mi blog personal, comentando una experiencia de generación de un sistema de diseño y codificación con inteligencia artificial de sus componentes a través del fichero DESIGN.md.

Pero es viernes por la tarde y en mi ha calado muy profundo aquella cosa de cuidarse uno mismo, de respetar el tiempo de descanso y de dejar descansar al cerebro. Es por eso que lo que voy a dejar aquí son un par de enlaces. Muy modesto todo, que nadie haga análisis sesudos porque mi objetivo aquí es simplemente divulgativo.

Pero es que hace semanas he venido trabajando en la creación de un sistema de diseño que me sirva como playground para actividades y pruebas posteriores. Lo he llamado Aragonia Design System, porque me apetece y porque me pone mucho dar visibilidad a todo lo que tiene que ver con Aragón. Quien me conocéis sabéis que soy aragonés, muy aragonés y mucho aragonés. Y hago gala de ello, siempre que tengo oportunidad.

Pero a lo que voy, que no me quiero desviar. Quien todavía tenga alguna duda acerca de el tremendo impacto de las herramientas de inteligencia artificial generativa en todo el ciclo de diseño centrado en el usuario, debería considerar su posición de manera urgente.

Todo esto que os cuento lo comparto después de haberlo compartido ya con mi equipo y después de haberlo implementado en la metodología de trabajo que seguimos para trabajar con clientes, siempre y cuando las circunstancias de contexto lo permitan. De esto último hablaré más adelante, porque tiene mucha chicha y seguramente hablaré en el blog de Estudio.

Por supuesto, todo el feedback será más que bien recibido.

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.

No me he podido aguantar las ganas de escribir sobre esto.

De Galileo AI a Stitch: una adquisición que ya daba pistas

Para entender Stitch hay que retroceder un poco. Galileo AI era una startup fundada en 2022 cuyo producto central era, en esencia, texto a interfaz de usuario: escribías una descripción, obtenías pantallas de aplicación listas para editar. Sencillo, útil, y con una propuesta de valor muy clara en un mercado donde Figma dominaba sin competencia real en el segmento de diseño colaborativo.

Google adquirió Galileo AI en 2024. La operación fue notificada a la Comisión Europea el 21 de noviembre de ese año bajo las obligaciones del Digital Markets Act. El producto resultante, rebautizado como Stitch, se presentó en el Google I/O de mayo de 2025 bajo el paraguas de Google Labs.

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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.

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é el estilo visual se inspira en 37signals
• 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.

Hoy le he contado a alguien en una conversación cuál es la experiencia que tenemos en el Estudio para trabajar con herramientas de inteligencia artificial en el ámbito del diseño de producto y la investigación con usuarios. Normalmente cuando salgo de las reuniones de trabajo me tomo unas notas de voz para después ordenar mis ideas. Y este es el resultado de la evolución de una de esas ideas. Algo así como un decálogo para abordar un proyecto de Vibe Coding para diseño de producto.

Lo comparto porque seguro que alguien le puede servir o de inspiración o de guía.

Define el problema antes de abrir la herramienta

Parece obvio pero no lo es. La tentación de lanzarte a escribir prompts es muy grande. Pero si no tienes claro qué problema resuelves, para quién y en qué contexto, vas a construir una solución en busca de problema. Eso no es producto, eso es entretenimiento. Que no está mal, pero es otra cosa.

Empieza en pequeño

Tu primera aplicación no tiene que ser un SaaS con autenticación, base de datos, pagos y notificaciones. Tiene que ser algo simple, que funcione, que puedas usar tú mismo mañana. Una sola funcionalidad, bien resuelta. Todo lo demás vendrá después, si es que tiene que venir.

Escribe un brief de producto, no una lista de funcionalidades

Antes de hablar con la IA, escribe en un documento quién va a usar esto, en qué situación, qué necesita resolver y cuáles son los criterios de éxito. Ese documento es tu ancla. Es la fuente de la verdad. Cada vez que la herramienta te proponga algo brillante pero innecesario, que sucederá, vuelves a él.

Elige una sola herramienta y aprende a dominarla. Lovable, Mocha, Cursor… da igual

Lo peor que puedes hacer es saltar de una a otra buscando la perfecta. Cada herramienta tiene su lógica, su forma de conversar, sus limitaciones. Necesitas tiempo para entenderla. Elige una y quédate con ella hasta que la conozcas de verdad. Lleva tiempo. Yo la que más a menudo utilizo es Mocha.

Trata la conversación con la IA como un proceso de diseño

Esto no va de dar una orden y esperar un resultado mágico. Esto es iterar. Pides, revisas, ajustas, vuelves a pedir. Y vuelves a empezar. Exactamente igual que cuando haces un prototipo con un equipo de desarrollo. La diferencia aquí es la velocidad, no tanto la naturaleza del proceso.

No aceptes el primer resultado visual

Las herramientas de las que estamos hablando generan interfaces que se parecen todas entre sí. Si te quedas con lo que sale por defecto, tu aplicación será una más del montón. Invierte tiempo en la dirección visual: referencias, paletas, tipografías, densidad de información. El criterio estético es tuyo, no de la máquina. Por mucho que parezca que lo va a hacer bien, el resultado será infinitamente mejor si guías a la herramienta.

Prepárate para lo que no se ve

Autenticación, gestión de errores, estados vacíos, persistencia de datos, permisos, rendimiento, edge cases. La parte invisible del producto es la que marca la diferencia entre algo que funciona en una demo y algo que puedes usar de verdad todos los días. Esto es lo que más vas a aprender, y lo que más te va a cambiar la perspectiva. Y si no te lo crees, pruébalo y verás. Eso sí, quizá que tengas que googlear para aprender a manejar algunos conceptos, pero de eso se trata. Esto es un proceso de aprendizaje.

Documenta lo que haces y lo que aprendes

No para publicarlo (aunque puedes hacerlo si quieres), sino para ti. Qué prompts funcionan, qué errores aparecen de manera recurrente, qué decisiones tomas y por qué. Esa documentación es tu verdadero aprendizaje, no tanto la aplicación en sí.

Usa tu propia aplicación

Parece una tontería, pero muchos proyectos personales se abandonan el día que se terminan. Úsala. Todos los días si puedes, mejor. Ahí es donde descubres los problemas reales, donde el diseño confronta con el uso y donde aprendes que construir producto no es sólo lanzar, es mantener.

Recuerda que la herramienta ejecuta, pero el criterio es tuyo. Esto es lo más importante

La IA no tienen ni la más remota idea acerca de si tu producto tiene sentido, si resuelve una necesidad real, si la arquitectura de información es coherente o si la experiencia es buena. Eso lo sabes tú. Y solamente tú. El conocimiento profesional (de diseño, de investigación con usuarios, de producto) es lo que convierte el vibe coding en algo útil de verdad, y no en un juguete con el que pasar el rato.

Esto es lo que he aprendido, después de muchos, muchos meses de trabajo intenso, de pruebas, de aprendizajes, de equivocarme, de sorprenderme, de disfrutar y ahora mismo de compartir.

Quienes me leéis sabéis que desde hace unos meses estoy alternando el uso de dos tipos aplicaciones. Por una parte las que todo el mundo usa, las que se actualizan cada dos semanas, las que tienen una feature para cada cosa que se te ocurra y para tres que no se te habían ocurrido, y por otro, esas herramientas que casi nadie conoce, que respetan escrupulosamente tu privacidad, que no venden tus datos ni los almacenan en servidores de terceros, pero que a veces tiene uno la sensación como si estuviera usando software de 2014. Spoiler: estamos hablando de privacidad y diseño.

La conclusión a la que llego, después de un par de meses conviviendo con ambos ecosistemas, no es la que esperaba ni tampoco me está suponiendo una gran sorpresa.

El problema no es la privacidad, es la experiencia

Las herramientas mainstream como Google, Microsoft, Notion o Slack, tienen equipos muy grandes iterando sobre la experiencia de uso prácticamente cada semana. Eso se nota mucho en detalles como los flujos, que están bastante pulidos (hay excepciones, pero generalmente es así), las integraciones funcionan o el onboarding, que es casi invisible. Pero claro, el precio que pagamos no es económico: es nuestra información, nuestros patrones de uso, nuestra atención convertida en producto.

Las alternativas respetuosas con la privacidad como Proton, Ulysses o Signal parten de una premisa técnica y ética impecable. Pero, y este es el tena en cuestión, muchas de ellas arrastran una deuda de diseño considerable. Y no hablo sólo de interfaces menos bonitas. Hablo de fricciones innecesarias, de flujos que no se han pensado desde el usuario, de funcionalidades que llegan tarde o que nunca llegan.

Una propuesta desde el diseño

El sector de la privacidad digital necesita incorporar estrategia de diseño con la misma urgencia con la que incorporó el cifrado de extremo a extremo, por poner un ejemplo. Esto implica cosas concretas: investigación con usuarios reales, no solamente con early adopters técnicos; pero también ciclos de iteración más cortos aunque los equipos sean pequeños; y sobre todo, dejar de asumir que el usuario que elige privacidad está dispuesto a sacrificar experiencia de uso para siempre.

Para las herramientas mainstream, la propuesta es distinta pero igual de necesaria: transparencia real sobre qué datos se recogen y para qué, controles de privacidad que no estén enterrados en submenús, y dejar de usar patrones oscuros para mantener al usuario dentro del ecosistema.

La privacidad no debería ser un sacrificio en la experiencia de uso. Y la buena experiencia de uso no debería costar tu privacidad. Que en 2026 sigamos tratando esto como un dilema dice bastante de lo poco que hemos avanzado.