Categoría: Diseño

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.

Llevo muchos meses escribiendo sobre Vibe Coding de una manera o de otra. Lo hago en este blog, en redes sociales y en el blog de Torresburriel Estudio. He leído montones de publicaciones de profesionales que andan compartiendo sus avances (vídeo) y sus descubrimientos. Reconozco que sigo fascinado con esta capacidad que tenemos ahora, quienes no somos técnicos, para construir producto digital sin la barrera tradicional de la programación. Pero necesito plantear algo que me inquieta. Tenemos por delante un fabuloso reto en lo que tiene que ver con la parte visual dentro del ámbito de la IA generativa.

El problema que no estamos mirando

Tenemos a nuestra disposición montones de herramientas que, basándose en inteligencia artificial generativa, nos ayudan a construir producto digital. De hecho, tenemos novedades todas las semanas, diría que todos los días. Una nueva herramienta, una nueva funcionalidad. Estamos tan centrados en la herramienta que hemos dejado de atender cuestiones que, desde mi punto de vista, son fundamentales en el proceso de diseño de producto. Por ejemplo: la alineación con el mercado, la investigación con usuarios, el ajuste al modelo de negocio… todo eso queda en un segundo plano cuando nos deslumbramos (O nos dejamos deslumbrar) con la capacidad de construir una aplicación funcional en minutos. Fijaos que ya no digo en horas, que digo en minutos.

Y hay algo que es todavía más evidente: desde la perspectiva estética y visual, no estamos haciendo nada. O casi nada. Y aquí es donde yo quería llegar.

La mayoría de las aplicaciones generadas con IA son parecidas. Por no decir que son prácticamente la misma. Puede parecer un poco exagerado, pero es que se reconocen a distancia. Esa uniformidad visual delata a las primeras de cambio que han sido construidas con prompts genéricos y bibliotecas de componentes por defecto. Y yo de este burro no me bajo.

Una crítica que nos compete como diseñadores

Las cosas claras: esto es responsabilidad nuestra. Nos hemos quedado presos del proceso de construcción de producto, estamos encandilados con la magia de ver código que se genera ante nuestros ojos. Yo soy testigo de ello. Puedo dar cuenta de las expresiones, las caras, los comentarios y las miradas de mis estudiantes cuando les hago una demo con aplicaciones de este tipo. Pero de verdad, también tengo que decir que no he visto ni tan siquiera brotes verdes de un desarrollo significativo en cómo avanzar en los sistemas visuales generados con este tipo de herramientas.

Me preocupa. Pero también me ocupa.

Y digo que me ocupa porque todos los experimentos que vengo haciendo en segundo plano con este tipo de herramientas, por supuesto, también cuentan con la derivada de toda la parte visual. Estos experimentos trabajando esta dimensión son cuando menos prometedores. Diría incluso que estoy entusiasmado con algunos de los resultados que estoy obteniendo. Aunque si voy un poco más allá, mi preocupación se incrementa. Quizás soy yo que no sé mirar bien, o no estoy en los sitios correctos, pero es que no veo una correspondencia en la comunidad. No percibo que esta conversación esté ocurriendo con la intensidad que, desde mi punto de vista, debería.

Lo que necesitamos construir

Creo que tendríamos que preocuparnos y trabajar en establecer técnicas concretas, o una suerte de decálogo, o quizá una lista de principios o consejos específicos para que, desde la perspectiva visual y de interacción, las herramientas de IA nos devuelvan resultados diversos, diferenciales, con alma, que huyan de esa uniformidad que caracteriza hoy en día a la mayoría de las aplicaciones construidas de esta forma.

No se trata sólo de que funcionen, porque eso es algo que ya está ocurriendo. De lo que se trata es de que tengan personalidad, de que respondan a una estrategia visual consciente y de que reflejen una identidad de marca o un posicionamiento que sea diferencial.

Prompts para romper la uniformidad visual

He estado experimentando con diferentes aproximaciones para conseguir resultados estéticamente diferenciados. Aquí os comparto algunos patrones de prompting que están funcionando (pero cuidado, porque esto es sólo una aproximación para mostrar que está en nuestras manos generar un output diferencial):

Opción 1: referencia a estudios de diseño específicos

Diseña esta aplicación siguiendo los principios visuales de 37signals:
- Interfaces limpias con abundante espacio en blanco
- Tipografía clara y directa, sin ornamentación
- Paleta de colores limitada y funcional
- Jerarquía visual mediante tamaño y peso, no mediante color
- Componentes que priorizan la legibilidad sobre la novedad

Opción 2: inspiración en movimientos artísticos

Aplica los principios del Bauhaus a esta interfaz:
- Formas geométricas puras (círculos, cuadrados, triángulos)
- Paleta limitada a colores primarios más negro y blanco
- Tipografía sans-serif de alto contraste
- Composición basada en grillas asimétricas pero equilibradas
- Eliminación de todo elemento decorativo no funcional

Opción 3: estética de producto reconocible

Desarrolla esta aplicación con la estética visual de Linear:
- Paleta de grises con un único color de acento
- Microinteracciones sutiles y fluidas
- Iconografía minimalista y consistente
- Estados de hover y focus cuidadosamente diseñados
- Densidad de información alta pero organizada

Opción 4: movimiento de diseño contemporáneo

Sigue los principios del Brutalismo Digital para esta interfaz:
- Tipografía de sistema sin personalización
- Ausencia de sombras y degradados
- Contraste extremo entre elementos
- Bordes sólidos y definidos
- Layouts utilitarios sin preocupación por la elegancia convencional

Opción 5: referencia editorial

Diseña con la aproximación visual de Medium circa 2014:
- Tipografía serif para contenido largo
- Espaciado generoso entre líneas (1.5-1.8)
- Imágenes de sangrado completo
- Máximo 680px de ancho para el contenido principal
- Escala tipográfica clara y pronunciada

Opción 6: producto de consumo específico

Aplica la estética de Stripe a esta aplicación:
- Gradientes sutiles en fondos
- Animaciones suaves de transición
- Ilustraciones isométricas simplificadas
- Paleta de azules con toques de violeta
- Bordes redondeados consistentes (8px)

Combinar referencias

Lo que he descubierto (aunque tampoco me ha sorprendido, la verdad) es que las mejores soluciones no vienen de aplicar un único estilo, sino más bien de combinar elementos:

Crea una interfaz que combine:
- La limpieza de 37signals
- El uso del color del Bauhaus
- Las microinteracciones de Linear
Mantén la densidad de información alta pero la navegación simple.

El reto real del Vibe Coding

El verdadero reto del Vibe Coding no es técnico. Ya hemos demostrado que podemos construir funcionalidad, eso es un hecho. El reto es de criterio: cómo articular sistemas de diseño que sean coherentes, cómo establecer jerarquías visuales con intención y cómo generar interfaces que no parezcan hermanas clonadas de la misma plantilla de Tailwind.

Necesitamos evolucionar del mira lo que he construido en una hora al «mira cómo he conseguido que esta herramienta respete mi sistema visual y produzca algo diferenciado.

Porque al final, como siempre digo: las herramientas pasan y los criterios permanecen. Si los hay, claro. Ahora mismo tenemos herramientas super potentes pero parece que echamos en falta criterios suficientemente desarrollados para sacarles todo el partido desde la perspectiva del diseño visual.

Para seguir explorando

Estos prompts que he compartido son puntos de partida, no fórmulas mágicas. Requieren iteración, refinamiento y, sobre todo, criterio para evaluar los resultados. Pero al menos nos permiten romper en primera instancia con esa uniformidad visual que caracteriza la primera generación de aplicaciones creadas con IA.

Sigo experimentando en esta dirección y documentando los aprendizajes. Si estás trabajando en esto o tienes referencias de gente que lo esté haciendo bien, me encantaría conocerlas.

Este post forma parte de una serie de artículos en los que voy a documentar mis experiencias en la construcción de producto digital, con herramientas de inteligencia artificial generativa, conocida como Vibe Coding.

Hoy vamos con un tema denso así que siéntate porque este post no es sencillo. Quiero poner encima de la mesa la gestión de ecosistemas de aplicaciones con legacy.

Precisamente la gestión de ecosistemas de aplicaciones con un legacy importante supone uno de los retos más complejos de abordar en diseño UX.

Os pongo en contexto. Hace un par de semanas, en una reunión con un cliente, pudimos comprobar lo que ya sabíamos, pero esta vez de manera muy clara, con muchos matices, y con nombres y apellidos: nos encontramos un panorama en el que había múltiples focos de desarrollo de software, muchas plataformas, y un buen montón de aplicaciones construidas a lo largo de años con criterios de diseño dispares. La tormenta perfecta.

El problema de la fragmentación

Lo que en algunas ocasiones hemos podido identificar es un patrón recurrente en organizaciones, ojo, con un cierto nivel razonable de madurez: aplicaciones desarrolladas sobre diferentes plataformas y lenguajes de programación y sistemas legacy que pueden haber cumplido 20 años tranquilamente. Cada una con su propio look and feel, y cada una respondiendo a las decisiones de diseño de diferentes equipos, modas y momentos temporales. El resultado es un ecosistema inconsistente en el que la coherencia visual y de experiencia de usuario brillan por su ausencia.

Este no es un problema menor, o como diría el otro, esto es un problema grande. Estamos hablando de aplicaciones que en la mayoría de las ocasiones son muy relevantes para el negocio, que son utilizadas todos los días por usuarios que trabajan con ellas, y de las que esperan una experiencia consistente, independientemente de la plataforma sobre la que estén desarrolladas, ya que en muchas ocasiones ni saben lo que hay debajo, ni tampoco les interesa saberlo.

Sistemas de diseño como infraestructura

Yo suelo decir que aquí es donde está el mundo de los mayores. Ese contexto en donde los artefactos, las metodologías y el buen hacer se juegan el prestigio. Aquí es, por tanto, donde los sistemas de diseño demuestran su valor real, más allá del branding, las modas, el hype o la estética. Un sistema de diseño tiene que comportarse como una infraestructura agnóstica a la plataforma de implementación, y así sucesivamente. Los componentes, patrones y principios deben poder desplegarse en cualquier tecnología del stack de la urbanización.

La clave desde mi punto de vista, y desde mi experiencia, está en entender que un sistema de diseño tiene dos niveles de abstracción:

El primero es a nivel conceptual: estamos hablando de los principios de usabilidad, los criterios de accesibilidad (WCAG 2.1 nivel AA), los patrones de interacción y la arquitectura de información. Este nivel es completamente agnóstico a la tecnología. Y de no ser así, la sostenibilidad estará ya entre la de juicio.

El segundo tiene que ver con el nivel de implementación: estamos hablando de las especificaciones técnicas, los design tokens, las bibliotecas de componentes, las hojas de estilo CSS y las plantillas. Este nivel tiene necesariamente que adaptarse a cada plataforma.

El valor del Playbook UX

Esto es café para los muy cafeteros, y soy consciente de que no todas las organizaciones tienen la capacidad para trabajar con una herramienta o un artefacto de este tipo. En todo caso, la experiencia me hace recomendarlo como estrategia, ya sea para escalar, ya sea para profesionalizarse o ya sea para atacar problemas de comunicación entre departamentos.

La propuesta de un Playbook de experiencia de usuario y accesibilidad responde, en líneas generales, a una cierta necesidad de estandarización. No es un tema que se circunscriba a la documentación estética, sino más bien se trata de un marco de referencia técnico que los equipos de desarrollo puedan consultar y aplicar.

Un Playbook UX que sirva para su objetivo debería incluir como mínimo:

• Checklist exhaustivos de accesibilidad basados en WCAG
• Principios de usabilidad fundamentados en heurísticas reconocidas (Nielsen)
• Especificaciones de componentes con variantes según plataforma
• Arquitectura de design tokens escalable
• Guías de implementación específicas para cada tecnología del stack
• Criterios de calidad y procesos de validación
  

Plataformas low-code como base del ecosistema

Las plataformas low-code presentan por su parte problemáticas particulares. Pero también nos las encontramos en muchas organizaciones. Conceptualmente están muy bien y son muy cómodas porque permiten que los equipos desarrollen rápidamente aunque con limitaciones en cuanto a personalización visual. Aquí es donde alguien ha tenido que tomar una decisión estratégica vinculada con la arquitectura: trabajar dentro de las capacidades nativas de la plataforma o implementar capas de personalización mediante CSS global. Ya os digo yo, que mi opción es siempre intervenir desde el ámbito de diseño en esta decisión con criterio.

El primer enfoque es más conservador y el más sostenible a largo plazo. Trabajamos con los design tokens que la plataforma permite modificar de manera nativa y adaptamos el sistema de diseño a estas restricciones. Es mucho menos personalizable pero pon otra parte es cierto que requiere un mantenimiento mínimo.

El segundo enfoque permite una coherencia visual total con el resto del ecosistema a través de la utilización de hojas de estilo personalizadas. Aquí gozamos de máxima flexibilidad pero introduce ciertas dependencias con la evolución de la plataforma. Cada actualización de la plataforma o la herramienta sobre la que estamos construyendo, podría potencialmente romper estas personalizaciones, organizando un follón importante y obligándonos a tirar de recursos extraordinarios para asegurar el mantenimiento.

¿Cómo resolver esta cuestión? Pues no existe una respuesta correcta ni universal. La decisión lógicamente va a depender de los objetivos estratégicos de la organización, su capacidad de mantenimiento técnico, y el valor que le dé a la coherencia visual absoluta frente a la estabilidad operativa.

El perfil de desarrollador como usuario

Uno de los aspectos más importantes en este tipo de proyectos es reconocer que los desarrolladores son usuarios primarios del sistema de diseño. Su experiencia trabajando con la documentación, implementando componentes y consultando especificaciones técnicas es fundamental para el éxito del sistema. Obviamente no hay que dejar de lado que también tienen su peso específico en la organización, más allá de cuestiones técnicas. La convivencia organizacional también es un factor que tenemos que considerar, especialmente cuando tenemos el rol de liderazgo en diseño.

Dicho todo lo cual, es el momento de decir que un sistema de diseño con alta fiabilidad desde la perspectiva de ingeniería tiene definitivamente que facilitar el trabajo de los equipos de desarrollo. Esto implica:

• Especificaciones técnicas precisas y completas
• Ejemplos de código funcionales y testeados
• Documentación de casos extremos y estados de error
• APIs de componentes definidas
• Procesos de actualización y versionado

Cuando los desarrolladores encuentran valor en el sistema de diseño, y especialmente cuando les simplifica el trabajo en lugar de complicarlo, encontramos ese momento mágico en el que la adopción ocurre de manera orgánica. El sistema de diseño deja de ser una imposición, deja de ser una cosa de diseñadores y de estética, y se convierte en una herramienta que facilita el trabajo del día a día.

Migración progresiva y deuda técnica

Habrá quien piense que todo esto está muy bien y tiene razón: el papel o, en este caso, un post de un blog personal lo aguantan todo. Es muy sencillo decirlo y otra cosa es llevarlo a la práctica. La realidad es que no se puede reconstruir todo un ecosistema de aplicaciones de la noche a la mañana. Expresaría una estrategia que tiene que venir definida por un amplio consenso. Y además de eso, la estrategia tiene que contemplar dos frentes a la vez:

Aplicaciones nuevas

Se arranca la construcción desde el inicio siguiendo el Playbook UX. Aquí no hay excusas, todo (o casi todo) es posible, y por eso todo desarrollo nuevo tiene que cumplir los estándares establecidos.

Aplicaciones existentes

Aquí estamos ante un escenario, donde hay que diseñar y desplegar una estrategia de refactorización progresiva. Estamos hablando de establecer una priorización que esté basada en el impacto al usuario, la criticidad del negocio, y por supuesto La viabilidad técnica. Algunas aplicaciones legacy simplemente no justifican la inversión que implica la actualización y, en algunas ocasiones, no les quedará más remedio que coexistir de la mejor manera posible con el ecosistema hasta su desaparición.

Esta gestión de la deuda técnica de UX necesita inexorablemente de dos cosas: criterio y pragmatismo. No todo necesita estar perfecto, pero sí necesita haber un plan y una dirección clara. Una vez más, principio de realidad.

Conclusión

El diseño de experiencia de usuario en ecosistemas tecnológicos que tienen un alto componente de heterogeneidad y que además cuentan con componentes legacy no es tanto un problema estético sino sobre todo un problema de arquitectura. Requiere sistemas de diseño solventes, además de documentación técnica que sea precisa, y por comprensión de las plataformas de implementación.

El objetivo no es necesariamente uniformidad visual, sino que exista una innegable coherencia a nivel de experiencia de usuario, que respete las capacidades y limitaciones de cada tecnología mientras mantiene los principios de usabilidad y accesibilidad. Es un trabajo exigente e importante de ingeniería tanto como de diseño, donde el rigor técnico y la visión de usuario tienen necesariamente que converger en soluciones que sean pragmáticas y sostenibles.​​​​​​​​​​​​​​​​

No es fácil.

He leído este artículo de Enrique Dans sobre Confer y me ha confirmado que casi nunca hablamos sobre humanismo digital. El humanismo digital no es sólo un concepto bonito, sino que es una forma de diseñar producto digital que respeta cómo funcionamos las personas.

Confer es un chatbot de IA creado por Moxie Marlinspike, el tipo que hizo Signal. Lo interesante aquí no es tanto la tecnología que usa (cifrado de aquí para allá, entornos de ejecución aislados y demás) sino la decisión de diseño que hay detrás: construir algo desde la premisa de que no tienes por qué confiar en nadie, ni siquiera en quien te da el servicio. Nada muy distinto de nuestro comportamiento habitual cuando salimos a la calle.

Lo que pasa es que hemos normalizado un montón cosas sin darnos cuenta. Llevamos años usando ChatGPT, Claude o Gemini, y nos hemos acostumbrado a que nuestras conversaciones con estas herramientas acaben en algún sitio, para entrenar el modelo, para mejorar el servicio… en fin, ya sabéis. El tema es que cuando hablamos con una IA no le estamos dando datos sueltos, sino que le estamos diciendo cómo pensamos, nuestras dudas sin filtrar (¿o es que nadie ha pensado nunca que sería de nosotros si se filtrasen nuestras conversaciones con un modelo de estos? je!). En fin, todos esos razonamientos en borrador que no le diríamos a nadie.

Enrique Dans lo explica muy bien en su artículo: el formato conversacional de estos cacharros nos hace confesar, y eso no debería estar en un data lake de nadie.

Diseñar para que no tengas que confiar

Lo novedoso de Confer es que no pide que confiemos en una promesa de privacidad escrita en letra pequeña, sino que nos ofrece algo mejor: que sea técnicamente imposible espiarnos. Ni siquiera ellos pueden leer lo que escribes. No es “no lo haremos”, es “no podemos aunque quisiéramos”.

Eso cambia bastante el diseño y lo hace desde la raíz. No se trata de educar al usuario para que no comparta información sensible, ni por supuesto se trata de engañar al usuario para que no sepa nada. Se trata de que pueda pensar libremente, sin consecuencias. Y lo que más me ha gustado es que parece que toda esa infraestructura de protección es invisible para quien lo usa. ¿Os acordáis de aquella frase de que la mejor tecnología es la que no se ve? Pues eso mismo.

Dans dice que ha tenido una experiencia estupenda.

La mejor experiencia de diálogo personal con un chatbot desde que empezó a probarlos. Sin subir documentos, sin compartir enlaces, solo conversación. Y la hace bien.

El humanismo digital es entender lo incómodo

A mí esto me parece humanismo digital en estado puro. No es diseñar productos buenos que nos dicen cómo deberíamos comportarnos, sino que se trata de respetar cómo funcionamos: necesitamos pensar en voz alta, necesitamos dudar sin filtro, necesitamos probar ideas antes de que estén listas y, por supuesto, necesitamos equivocarnos a lo grande.

Confer reconoce que los seres humanos, cuando estamos en un momento de intimidad y en un espacio que creemos seguro, siempre hacemos algo así como confesarnos. Perdemos el filtro. Y Confer en lugar de aprovecharse de ello, lo protege. Eso es lo que yo entiendo como diseño honesto.

El precio de no venderte

Pero como siempre sucede, la fiesta hay que pagarla. Es el principio de realidad, una vez más. Si no venden nuestros datos, tienen que cobrar de otra manera. ¿Cómo? Pues con un modelo freemium: versión gratuita limitada y versión de pago a $34.99/mes. A algunos les parecerá caro, a mí me parece coherente. Si queremos un servicio que no nos convierta en producto, tendremos que hacernos cargo. De nuevo, el principio de realidad.

Para terminar

Confer no es perfecto, al menos todavía, pero plantea la pregunta correcta: ¿qué entendemos por servicio de IA? ¿Algo que nos ayuda a cambio de nuestros pensamientos, o algo que nos ayuda y punto?

En este sector la privacidad es opcional y está enterrada en ajustes y letra pequeña. Confer hace una apuesta importante y la convierte en fundamento. No es un feature que podamos activar sino que es la arquitectura sobre la que está construido todo. Eso es, para mi, diseñar para humanos. Eso es humanismo digital aplicado.