En las últimas semanas, sólo desde Torresburriel Estudio, hemos puesto en marcha tres movimientos que ilustran bien de qué va esto.
El primero: estamos trabajando ya en una oportunidad con un partner de DANOK que, seamos honestos, de otra forma nunca nos hubiese llamado. No porque no nos conociese, sino porque no había un contexto que lo facilitase. Ahora ese contexto existe.
El segundo: tenemos agendada una sesión para explorar oportunidades conjuntas con otro partner. Todavía no hay proyecto, pero hay conversación. Y la conversación es el primer paso de todo.
El tercero: hemos calendarizado una reunión con un cliente nuestro al que vamos a presentar a otro partner de DANOK. Nosotros llevando negocio a la red. Porque esto funciona en todas las direcciones o no funciona.
Y aquí viene lo importante: esto es solamente lo que estamos haciendo nosotros. Somos ocho partners. Los ocho estamos generando movimientos similares. Multiplicad por ocho y empezaréis a ver la dimensión de lo que se está cocinando.
Oportunidades de negocio en red
No voy a vender humo. Todavía no hay resultados que poner encima de la mesa. Lo que hay son oportunidades en marcha, conversaciones abiertas, proyectos en fase de definición. Pero la maquinaria ya gira. Y cuando ocho consultoras especializadas empiezan a mover oportunidades de manera multilateral, los frutos no tardan en llegar. Y cuando lleguen, van a ser exponenciales.
La estructura que viene
La tarea que tenemos por delante es clara: construir la estructura que permita no sólo sostener esto, sino ampliarlo. Procesos, gobernanza, coordinación operativa. Todo lo que hace falta para que una alianza de consultoras de este tipo escale sin perder lo que la hace valiosa.
Las sensaciones que tengo son difíciles de describir, las cosas como son. Llevamos quince años (que sí, que este año hacemos 15 años, ni más ni menos) construyendo una consultora desde Zaragoza para el mundo, compitiendo en un mercado donde el tamaño importa más de lo que debería. Y ahora, por primera vez, siento que estamos jugando en otra liga. No porque hayamos crecido solos, sino porque hemos encontrado la forma de crecer juntos.
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.
Ilustración de Hugo Tobio
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.
¿Os acordáis de del.icio.us? Para quienes trabajábamos con internet a mediados de los 2000, esa herramienta era un básico. Joshua Schachter creó algo que desde mi punto de vista fue brillante: un sistema de marcadores sociales basado en etiquetado libre que creaba lo que se llamó «folksonomía”, es decir, conocimiento organizado por la gente, no por taxonomías formales. Yahoo lo compró en 2005 y, como tantas otras adquisiciones, lo dejó morir lentamente. Imagino del.icio.us en 2026 y veo Linkwise.
Hace tiempo que sigo echando de menos la simplicidad de esa aplicación. No me interesa en absoluto un Notion con mil funcionalidades, no un sistema complejo de gestión de conocimiento. Sólo guardar un enlace, ponerle dos tags, encontrarlo después. Así que he decidido construir mi propio clon como side project para 2026.
Me he marcado como objetivo que este post documente el proceso: cómo he construido Linkwise usando Mocha (una herramienta de vibe coding de la que ya he hablado por ahí en alguna ocasión), los aprendizajes desde la perspectiva de UX, y las recomendaciones que haría a otros profesionales que estén explorando estas nuevas formas de crear productos digitales.
El contexto: vibe coding y límites claros
Antes de empezar quiero hacer, una vez más, una aclaración importante: esto es una prueba de concepto, no es una aplicación en producción. No hay un equipo de tecnología detrás, no hay QA, no hay infraestructura robusta. Esto es lo que una persona con un perfil no técnico puede construir en unas horas usando herramientas de IA generativa para codificar. Ni más ni menos. Y esto me parece importante aclararlo e insistir en ello, para que no haya dudas y para que las expectativas sean realistas y honestas.
Elegí Mocha porque permite iterar rápidamente mediante prompts en lenguaje natural. No es muy distinta a otras aplicaciones de este estilo, pero tengo que reconocer que para mí es la más simple y la que genera resultados, con menos fricción y menos complejidad posterior. El flujo es sencillo: describes lo que quieres, la herramienta genera el código, revisas el resultado, y ajustas el prompt si es necesario. Es vibe coding. Confías en que la IA entiende tu intención y traduce tu descripción a código funcional. Eso es mucho confiar, pero por eso las iteraciones tienen todo el sentido del mundo y marcan la diferencia.
Esto tiene ventajas bastante evidentes de velocidad, pero también limitaciones claras que iré mostrando. Parafraseando el estupendo libro de Enric JulianaAquí hemos venido a aprender, eso no lo olvidéis nunca.
Timeline: de la idea al MVP funcional
Día 0: definición del concepto (21 enero)
Lo primero fue cristalizar la idea. No quería replicar del.icio.us exactamente (aunque la nostalgia tiraba hacia que lo hiciese, pude con ese impulso), sino capturar su espíritu pero con una ejecución más pulida Y un tanto actualizada. Mis referencias de diseño son claras y transparentes:
Del.icio.us: densidad de información, etiquetado libre, funcionalidad sin florituras
37Signals/Basecamp: tipografía clara, espacios generosos, diseño honesto y directo
Decidí también el stack: auth con Google OAuth (por simplicidad), cumplimiento GDPR desde el principio (no en vano opero desde España), estética accesible AA. Y en inglés, porque así amplío el alcance potencial.
Primer aprendizaje UX: definir las referencias visuales concretas es fundamental cuando trabajas con IA. No basta con decir minimalista o limpio. Necesitas mucha más precisión para dar todo el contexto a la herramienta generativa: estilo 37Signals da contexto específico que la IA puede interpretar.
Día 1: prompt inicial y estructura base (21 enero)
Construí el primer prompt siguiendo una estructura que aprendí iterando:
Contexto del proyecto: qué quiero construir y por qué
Estética y principios de diseño: referencias concretas, paleta, tipografía
Features core: lista priorizada del MVP
Requisitos técnicos: auth, accesibilidad, GDPR
Exclusiones explícitas: qué NO incluir en el MVP
Por motivos que algún día contaré, siempre me he guiado por un principio: es tan importante saber lo que uno quiere, como especialmente saber lo que no. Listar explícitamente lo que no quieres evita que la IA añada funcionalidades útiles que lo complican todo innecesariamente.
El resultado: en menos de 40 segundos tenía la estructura base de la aplicación con auth de Google, base de datos configurada, y la estructura HTML semántica. Una auténtica revolución para mi yo fronter de 2003.
Aprendizaje UX: en diseño de producto, sabemos que definir qué NO hacer es tan importante como definir qué hacer. Con IA, esto se vuelve literal: si no lo excluyes explícitamente, aparecerá. Y al principio, o en ocasiones puede parecer que mola, pero no.
Días 2-3: iteración sobre funcionalidad core (21-22 enero)
Aquí empezaron las iteraciones. El patrón se fue repitiendo:
Mocha genera código según mi prompt
Reviso en preview
Encuentro algo que no funciona como esperaba
Ajusto el prompt con instrucciones más específicas
Repito
Algunos ejemplos concretos:
Problema: el formulario de añadir bookmark mostraba debajo toda mi lista de enlaces existentes. Esto rompía el foco y abría la puerta a una sobrecarga potencial en el rendimiento cuando hubiese una lista larga de enlaces.
Solución prompt: “la página para añadir un enlace no debería cargar debajo el resto de enlaces que ya tengo. Crea una página separada /add solo para el formulario.»
Resultado: página dedicada, mucho más limpia.
Problema: los tags se mostraban como pills modernas con bordes redondeados y colores. Muy alejado del espíritu del.icio.us.
Solución prompt: “remove pill/badge styling completely. Display as plain text separated by spaces or commas. Clickable but look like text links.«
Resultado: tags como texto simple, mucho más del.icio.us.
Problema: el diseño inicial era demasiado corporativo moderno, con mucho padding y elementos flotantes.
Solución prompt: un prompt completo describiendo la estética del.icio.us + 37Signals, con ejemplos específicos: «Bookmark titles: 22px, bold, classic blue link color (#0000EE). Domain URLs: 14px, gray (#666). Reduce card padding significantly (12-16px). More information visible on screen.«
Aprendizaje UX: el feedback visual inmediato que da una herramienta como Mocha, o similares, acelera un montón las iteraciones de diseño. En proyectos tradicionales, cada cambio estético requiere coordinación con desarrollo. Aquí puedes iterar sobre detalles visuales en minutos.
Pero hay un trade-off: la rapidez puede llevarte a no pensar lo suficiente antes de ejecutar. Me pasó varias veces que pedí un cambio, vi el resultado, y me di cuenta de que no había considerado el caso edge o la implicación en vista móvil.
Día 4: añadiendo inteligencia artificial para la sugerencia de tags (22 enero)
Una de las features que más me interesaba era usar IA para sugerir tags automáticamente al añadir un enlace. El razonamiento era claro: mantener consistencia en el etiquetado es difícil. Si ya tengo 20 enlaces etiquetados con ux-research, que la IA sugiera ese mismo tag (no user-research) cuando añado contenido similar. O lo que es lo mismo, que la tecnología me facilite la consistencia. Esto se notará mucho al escalar.
El prompt para conseguir esta feature:
When a user adds a new bookmark by entering a URL,
analyze the content and suggest 3-5 relevant tags
automatically based on:
- Page title, meta description, main content
- User's existing tags (prioritize their vocabulary)
- Format: lowercase, hyphens for multi-word tags
Configuré la API de OpenAI, lancé… y para sorpresa de nadie no funcionó. Los logs mostraban que la clave API no se estaba cargando bien en el entorno de desarrollo.
Aquí descubrí una limitación importante: Mocha tiene dos entornos (desarrollo y producción), y los secrets configurados sólo aplican a producción. Para desarrollo, necesitas un archivo .dev.vars local. La documentación no era del todo clara en esto (yo tampoco soy un experto en esta movida), y pasé bastante tiempo debuggeando algo que era simplemente configuración. Pero bueno, aprendí un montón, y eso que me llevo.
Aprendizaje UX: las herramientas de IA para desarrollo todavía tienen rough edges en temas de configuración de entornos, manejo de secrets, y debugging. Si estás acostumbrado a las guardrails de un entorno de desarrollo tradicional, te vas a encontrar con sorpresas.
La expectativa de describe lo que quieres y mágicamente funciona es aspiracional, no realista. No nos vengamos arriba. Hay que estar preparado para debugging tradicional.
Día 5: refinamiento visual o el sidebar de tags (22 enero)
Otra cosa que quería hacer porque me parecía maravillosa del original es recuperar el layout clásico de del.icio.us: lista de bookmarks a la izquierda, nube de tags en sidebar derecho. Esto es un cambio de layout importante que en código tradicional requeriría repensar estructura, CSS grid, responsive behavior…
El prompt:
Desktop layout (>1024px): two-column layout.
Left column (65-70% width): search box and bookmark list
Right sidebar (30-35%): tag cloud with all tags,
sorted alphabetically, clickable for filtering.
Mobile: single column, tag cloud above bookmarks.
Funcionó a la primera. Grid CSS generado correctamente, responsive breakpoints apropiados, sidebar con scroll independiente. Eso sí, en móvil el resultado no me convence cuando escala. Eso aún lo tengo que pulir.
Aprendizaje UX: para cambios estructurales de layout, estas herramientas son muy potentes. Lo que tradicionalmente podía requerir de horas de CSS y testing cross-browser, aquí sucede en segundos. Y me asombra y me sigue pareciendo magia.
Pero hay un matiz: no es facil ver el código intermedio y validar la implementación técnica. No nos queda más remedio que confiar en que la IA ha generado CSS mantenible y eficiente, y para una prueba de concepto está bien. Para producción, sería necesaria una auditoría técnica.
Día 6: paginación y detalles de UX (22 enero)
Estamos en un punto en el que con la funcionalidad básica ya funcionando, los detalles de UX se volvieron evidentes y más necesario. Y mi corazón de diseñador respiró tranquilo, porque me encontré en un territorio mucho más conocido:
Cargar todos los bookmarks de golpe no escala. Necesitaba paginación.
El bookmarklet (la feature estrella de del.icio.us) no funcionaba correctamente con React.
Para paginación, el prompt fue directo:
Display 10 bookmarks per page. Simple pagination
controls at bottom: ← Previous [1 2 3] Next →
Maintain filters and search when paginating.
URL should reflect current page (?page=2).
El bookmarklet fue más tricky. React bloquea javascript: URLs por seguridad. La solución pasó por usar useEffect para establecer el atributo href directamente en el DOM, bypassing el filtro de React. Obviamente, todo esto lo aprendí por el camino, me supuso mucha fricción, pero aquí estoy contando lo orgulloso como si supiera de lo que estoy hablando.
Aprendizaje UX: los detalles de UX (paginación, estados de carga, manejo de errores) requieren prompts específicos. La IA no va a añadirlos de manera proactiva porque son best practices. Tienes que pedirlos explícitamente. Y para eso tienes que saber lo que quieres. Y lo que no.
Esto es importante: el juicio profesional no se puede delegar. La herramienta genera lo que describes, no lo que deberías haber descrito. La responsabilidad de pensar en edge cases, accesibilidad, performance… sigue siendo nuestra.
Día 7: GDPR y contenido legal (22 enero)
Para operar en Europa, GDPR no es opcional. Necesitaba:
Esto es contenido legal más features técnicas, así que mi prompt fue muy específico (o al menos eso intenté):
Create comprehensive Privacy Policy compliant
with GDPR and Spanish LOPDGDD. Must include:
- Data controller information
- What data we collect and why
- User rights (access, rectification, erasure,
portability, complaint to AEPD)
- Data retention policies
- Cookie usage
Implement:
- Settings page with "Export all data" button
(downloads JSON)
- "Delete account" with confirmation flow
El resultado para mí fue bastante razonable: páginas legales bastante completas (aunque siempre recomendaría revisión por legal), y features de exportación/borrado funcionando.
Aprendizaje UX: Como pasa para otro tipo de contenidos, datos y procesos, para contenido legal o regulatorio, la IA es un buen punto de partida pero NO es sustituto de la revisión profesional. El texto generado cubre los puntos principales, pero en un proyecto real necesitaría validación legal.
Dicho esto, para una prueba de concepto, tener GDPR-awareness desde el principio es un ejercicio valioso. Te obliga a pensar en privacidad y derechos del usuario desde diseño, no como afterthought.
Día 8: pulido final, accesibilidad y metadatos (22 enero)
El último día ya fue para pulir detalles:
Accesibilidad: ARIA labels, navegación por teclado, contraste AA, HTML semántico
Metadatos: favicon, og:image para compartir en redes, apple-touch-icon
Contenido: página About explicando el proyecto y enlazando a mi perfil profesional (pero básicamente porque esto es algo que he elegido)
Para asegurar el tema de los metadatos vinculado con unos escenarios concretos, pedí que generara las imágenes porque tampoco quería utilizar más tiempo en esto:
Generate favicon.png, og-image.png, and
apple-touch-icon.png using:
- Grayscale design with classic blue accent
- Clean, minimal aesthetic
- "Linkwise" text or "L" monogram
Mocha generó las tres imágenes. No son diseño profesional, pero son apropiadas y funcionales. Para una prueba de concepto como esta son mucho más que razonables.
Aprendizaje UX: la capacidad de generar assets visuales básicos (iconos, imágenes sociales) dentro del mismo flujo de desarrollo acelera mucho el proceso. No son diseños award-winning ni de coña, pero cumplen su función.
Para producción, ninguna duda que haría falta el trabajo de diseño gráfico profesional. Pero para validar concepto rápidamente, ha sido suficiente para mi en este caso.
Aprendizajes consolidados para UX en un contexto de IA generativa
Después de esta experiencia, estos son los aprendizajes que me traigo aquí desde una perspectiva de experiencia de usuario:
1. El juicio profesional no se delega
La herramienta ejecuta lo que dices, pero no decide por ti qué construir o cómo debe comportarse. Ni lo contrario. Toda decisión de diseño, priorización de features, consideración de edge cases… sigue requiriendo criterio profesional.
Ejemplo concreto: la IA no me dijo oye, deberías añadir paginación porque si un usuario tiene 500 bookmarks va a ser inusable. Yo tuve que identificar ese problema y pedirle la solución.
2. La especificidad en prompts es equivalente a especificidad en wireframes
En diseño tradicional, un wireframe vago lleva a implementaciones que no son lo que esperabas. Con IA, un prompt vago lleva exactamente al mismo problema.
Los mejores resultados vinieron de prompts que especificaban:
Medidas concretas (22px, padding de 12-16px)
Referencias visuales precisas (estilo 37Signals, no decir sólo minimalista)
Comportamientos exactos (click en tag = añadir a filtro activo)
3. El feedback rápido permite una iteración de diseño rápida
Lo que más me sorprendió fue poder iterar sobre estética visual en minutos. Ver un cambio, ajustar, ver otro cambio… El ciclo de feedback es tan rápido que puedes explorar opciones de diseño que en flujo tradicional no intentarías ni de coña porque no vale la pena el esfuerzo de desarrollo.
Esto es potente, pero también es peligroso ya que podemos caer en ese escenario (que tanto odio cuando lo hacen los demás y yo soy quien gestiona el proyecto o la iniciativa) de micro-optimización sin fin. Hay que mantener disciplina de esto es suficientemente bueno para el objetivo actual.
4. Los detalles de UX requieren cariño
Los estados de carga, los mensajes de error, la validación de formularios, el manejo de fallos de red… Nada de esto aparece automágicamente (nótese mi creatividad literaria a estas alturas del post). Hay que pedirlo de manera especifica.
Mi checklist mental pasó a ser:
¿Qué pasa si la URL no carga?
¿Qué ve el usuario mientras espera?
¿Cómo se comunica éxito/error?
¿Funciona en móvil?
¿Es navegable por teclado?
5. La accesibilidad no viene gratis (pero se puede integrar)
Aunque especifiqué WCAG AA compliant desde el principio, muchos detalles de accesibilidad requirieron prompts específicos o ajustes manuales. ARIA labels, contraste de colores, navegación por teclado… son elementos que hay que revisar.
Dicho esto, cuando le pides explícitamente accesibilidad, la IA genera código bastante decente con HTML semántico, labels apropiados, y atributos ARIA correctos.
6. El debugging sigue siendo debugging
Cuando algo no funciona, necesitas habilidades tradicionales de debugging: revisar logs, entender errores, identificar dónde está el problema. La IA puede ayudar a generar la solución, pero primero tienes que diagnosticar. También es verdad que las herramientas actuales ayudan bastante, con un poquito de motivación, a ponerse con ello, aunque no se tenga experiencia previa.
En mi caso, los problemas de configuración de API keys, el bookmarklet roto por restricciones de React, y varios edge cases requirieron debugging manual. Pero lo he dicho, la motivación de ir desbloqueando logros, siempre ha sido uno de los elementos que más me ha ayudado a aprender. En 2026, pero también en 2004.
Recomendaciones para profesionales UX usando IA generativa
Basándome en esta experiencia, estas son mis recomendaciones para colegas que estén explorando estas herramientas, una vez más:
Para Diseñadores UX
1. Trata los prompts como entregables de diseño
Un buen prompt es como un buen wireframe más una buena especificación. Estructura tu prompt con:
Contexto y objetivos
Referencias visuales específicas (no genéricas)
Comportamientos esperados con ejemplos
Casos edge y estados de error
Lo que explícitamente NO quieres
2. Mantén un archivo de design tokens en tus prompts
Para consistencia visual, define desde el principio:
Reutilizar este «design system prompt» en todas las features nuevas ayuda a mejorar la consistencia.
3. Valida accesibilidad manualmente
Aunque pidas WCAG AA compliance, revisa:
Contraste real con herramientas como WebAIM
Navegación por teclado (prueba sin mouse)
Screen reader (al menos VoiceOver en Mac o NVDA en Windows)
No asumas que cumple AA sin verificar. Eso no sucedía antes de la IA y ahora tampoco.
4. Usa la velocidad de iteración de manera estratégica
Este es un temazo, porque buena parte de la vibra que nos devuelve el proceso de trabajar con este tipo de herramientas, se puede reconducir de una manera inteligente y muy productiva. El poder de iterar rápido puede llevarnos a perfectionism infinito. Ya os adelanto que eso es un error. Establecer criterios claros de good enough para cada etapa va a ser siempre la mejor estrategia. Os lo aseguro, después de haber gastado un buen puñado de tokens de manera inservible en el pasado (ojalá ese gasto sirva para que alguien aprenda lo que no hacer):
Prototipo funcional: funciona, no importa si es feo
MVP: funciona bien, estética básica correcta
V1: pulido, accesible, profesional
No te quedes atascado puliendo detalles cuando aún no has validado el concepto. De verdad.
Para Product Managers y Product Designers
1. La velocidad no reemplaza el pensamiento estratégico
Poder construir algo en horas no significa que debamos hacerlo. Las preguntas fundamentales siguen siendo las mismas:
¿Resuelve un problema real?
¿Para quién?
¿Cuál es el valor diferencial?
¿Es sostenible mantenerlo?
La IA acelera la ejecución, pero en ningún caso no sustituye estrategia. Pensar que eso es así es un error.
2. Usa prototipos funcionales para validación temprana
Antes, un prototipo interactivo requería herramientas especializadas (Figma, Principle…) y tiempo, bastante tiempo. Ahora podemos tener un prototipo que funciona de una manera más que razonable (con base de datos, auth, etc.) en tiempo similar o menor.
Esto cambia la conversación con stakeholders y clientes: ya no es imagina que esto funciona así, es aquí está funcionando, pruébalo y me dices qué te parece. El cambio no es menor.
3. Documenta las limitaciones
Cuando presentes un prototipo construido con IA, sé explícito sobre:
Qué ha sido generado vs. diseñado intencionalmente
Qué funciona vs. qué parece que funciona
Qué es code de producción vs. prueba de concepto
Qué requeriría reescribirse para escalar
Evitar crear expectativas incorrectas es ya un indicador de liderazgo en diseño y de madurez.
Estos prototipos son excelentes para validar conceptos, pero el código generado probablemente no es lo que nadie medianamente profesional pondría en producción. Vamos a pensar en ellos como wireframes funcionales, no como base de código final. Si la prueba de concepto funciona, tiempo de hacer estimaciones para que un equipo de coders se ponga a ello.
Para equipos completos
1. Establece un proceso de revisión
Aunque una persona puede construir el prototipo (este que os cuento es uno de esos casos), sigue necesitando:
Revisión de UX (¿cumple principios básicos?)
Revisión de accesibilidad (¿es usable para todos?)
Revisión de seguridad (¿hay vulnerabilidades obvias?)
Revisión legal (¿cumple regulaciones?)
La velocidad de construcción no elimina la necesidad de checks and balances. Por favor, estop tenemos que grabarlo a fuego.
2. Crea una biblioteca de prompts reutilizables
Como equipo, construid una colección de prompts que funcionan bien para:
Formularios accesibles
Layouts responsive
Patrones de navegación
Manejo de errores
Features comunes (búsqueda, filtros, paginación…)
Esto va a acelerar futuros prototipos y va a garantizar más consistencia. De todos modos la forma de organizar estas indicaciones va a tener un punto de personalización importante. Yo sólo propongo un marco general.
3. Diferencia «prototype thinking» de «product thinking«
Un prototipo hecho con herramientas IA generativa es perfecto para:
Validar conceptos de manera rápida
Explorar posibilidades de interacción
Comunicar visiones
Testear con usuarios reales para tomar decisiones de diseño mejor informadas
El rol del profesional evoluciona, no desaparece
Construir Linkwise me ha llevado aproximadamente entre 8 y 10 horas distribuidas en una semana. En un proceso tradicional, sólo las reuniones de kick-off, diseño, y setup inicial habrían consumido ese tiempo. Pero eso no significa que el trabajo profesional desaparezca. Significa que se transforma:
De ejecutor a director: menos tiempo escribiendo código/píxels, más tiempo decidiendo QUÉ construir y CÓMO debe comportarse
De especialista técnico a orquestador: la habilidad crítica pasa a ser comunicar la intención (una forma de outcome) de manera clara y validar los resultados
De construcción a criterio: el valor no está en ensamblar componentes, sino en saber QUÉ ensamblar y POR QUÉ
Linkwise es una prueba de concepto. No tiene el pulido de un producto diseñado por un equipo profesional, ni de lejos. Tampoco tiene la robustez técnica de código revisado por ingenieros senior (lo he montado yo, que no tengo ese perfil). No tiene la profundidad de UX research que informaría decisiones en un proyecto real. De hecho no ha habido research.
Pero como herramienta para validar una idea, explorar posibilidades, y aprender sobre estas nuevas formas de trabajar… es exactamente lo que necesitaba.
Y eso, me parece, es el punto clave: estas herramientas no reemplazan el trabajo profesional, pero sí permiten que los profesionales exploremos más rápido, validemos más temprano, y enfoquemos nuestro expertise donde más valor aporta.
El futuro no es IA hace diseño UX. Ni de lejos, al menos hoy. El futuro es profesionales UX usan IA como herramienta para diseñar mejor, más rápido, y con más foco en lo que realmente importa: resolver problemas reales para personas reales.
Nota: Linkwise está disponible en linkwise.torresburriel.com como prueba de concepto abierta. Si quieres probar, guardar tus propios enlaces, o simplemente curiosear, eres bienvenido. Sólo recuerda: esto es un experimento, no un producto en producción.
Y si te interesa el tema, en Torresburriel Estudio estamos explorando cómo estas herramientas cambian nuestros procesos de diseño y consultoría UX. Siempre abierto a conversar sobre esto: linkwise@torresburriel.com
Marzo de 2007. Lo recordaré siempre porque ahí es cuando empezó todo, ahí es cuando abrí mi cuenta en Twitter, en un momento en el que la plataforma apenas era conocida fuera de los círculos tecnológicos más frikis. Casi 20 años después, en febrero de 2026, he decidido no renovar mi suscripción de pago. Y creo que merece la pena explicar por qué. Aunque sólo sea como ejercicio de terapia, como dinámica de gestión del duelo. Sí, esto es un fin de ciclo de Twitter en lo que a mi respecta.
Esto no es una decisión impulsiva. Llevo meses dándole vueltas, intentando encontrar razones para seguir. He sido usuario de pago, contra todo lo que la razón y mis principios me aconsejaban, precisamente porque quería sacar el máximo partido a la plataforma, independientemente del ruido ambiental. He invertido tiempo, dinero y energía en mantener una presencia activa, en compartir conocimiento y en construir conversaciones, relaciones, contactos y todo tipo de dinámicas en positivo.
Pero hay un momento en que los números y los resultados son claros: el alcance es mínimo y el crecimiento nulo. Y no hablo sólo de métricas de esas que le engordan a uno el ego (que esas, por cierto, hace tiempo que dejaron de ser importantes para mí). Hablo de conversaciones reales, de intercambio de ideas, de ese valor que justifica invertir recursos económicos y temporales en una plataforma. Tan simple como eso.
El coste real de la toxicidad
El dinero, siendo honesto, en este caso es lo de menos. Para una empresa como Torresburriel Estudio (en realidad para cualquier empresa medianamente sostenible), el coste de una suscripción a Twitter es ridículo en términos de presupuesto. Lo que no es ridículo es el coste de oportunidad del tiempo invertido.
El nivel de toxicidad, basura, gentuza y trollsha superado cualquier límite razonable. Y esto no sólo pudre la experiencia directa, sino que tiene efectos secundarios más sutiles y desde mi punto de vista perniciosos: afecta al comportamiento de las personas que podríamos considerar “normales”. La interacción desaparece. La gente deja de compartir. El miedo, creo, a ser el siguiente objetivo de una horda enfurecida paraliza la conversación que nace con el objetivo de compartir.
La moderación como virtud perdida
Siempre he creído que en la moderación está la virtud, aunque también es cierto que no siempre lo he practicado. Especialmente en los últimos años, he intentado mantener un equilibrio entre lo directo y lo reflexivo, entre lo informal y lo intelectual. Pero Twitter ha dejado de ser un espacio donde esa moderación tenga sentido o siquiera sea posible. Ahora solamente hay espacio para la confrontación directa, que un escándalo mayúsculo sea superado por el siguiente, el insulto y la polarización extrema.
No hay espacio para el matiz. No hay lugar para el pensamiento pausado. Ni hablamos de que haya espacio para la fraternidad, la colaboración, la ayuda mutua y el compañerismo. Todo se convierte en trinchera, en posicionamiento extremo, en ruido ensordecedor que ahoga cualquier intento de conversación que merezca la pena.
Lo que se pierde
Es una pena, y lo digo sin ironía. Todavía quedan algunos perfiles que comparten contenido interesante, reflexiones valiosas, conocimiento genuino y algo de espíritu colaborador. Pero el conjunto, para mí, hace que ya no merezca la pena. Es como intentar mantener una conversación inteligente en medio de un estadio durante un derbi: puede que tu interlocutor tenga cosas interesantes que decir, pero el contexto lo hace insostenible.
Nada es para siempre
Casi 20 años dan para mucho. He visto nacer tendencias, he participado en conversaciones que luego se convirtieron en movimientos, he conocido a personas extraordinarias, he hecho negocios muy interesantes y sobre todo he aprendido muchísimo. Twitter fue, durante mucho tiempo, una herramienta profesional valiosa y un espacio de aprendizaje continuo. Tantas veces me pregunté que no sabía cómo había podido estar en internet hasta la llegada y existencia de Twitter. Y, cómo son las cosas, estoy cerrando una de las últimas páginas de esa historia.
Todo tiene un final. Y reconocer cuándo algo ha dejado de aportar valor no es rendirse, es ejercer el criterio profesional que llevo aplicando casi dos décadas en mi trabajo: saber cuándo una herramienta, un proceso o una relación ha dejado de ser productiva.
La decisión
No renovaré mi suscripción. Probablemente mantenga la cuenta, por si acaso, pero sin inversión activa de tiempo ni recursos. Redirigiré esa energía a otros espacios, otras conversaciones, otras formas de compartir conocimiento y construir comunidad. La mera existencia de este nuevo blog creo que ya apuntaba hacia donde iba el futuro.
Porque al final, de eso se trata: de construir, no de resistir. Y Twitter se ha convertido en un ejercicio de resistencia que ya no estoy dispuesto a mantener.
El problema no es nuevo, pero últimamente se ha agravado. La democratización de las plataformas de contenido ha creado un ecosistema donde cualquiera con seis meses de experiencia y una cuenta de LinkedIn puede venderte su framework definitivo para tu carrera en UX. Y lo peor de todo este rollo es que a veces suena hasta convincente, porque todo está envuelto en un vocabulario que parece profesional, hay infografías bonitas por todas partes, e incluso hay como un ambiente que genera la ilusión de que existe un camino correcto que tú, pobre mortal confundido, todavía no has descubierto.
Pero aquí está la verdad incómoda: no existe ese camino correcto. Y quien te diga que lo tiene, o está mintiendo o está vendiendo algo (generalmente, las dos cosas a la vez).
El contexto que nadie te cuenta
Vamos a hacer un ejercicio muy simple que consiste en poner las cosas en perspectiva.
¿Cómo va a servir el mismo consejo para todas estas personas? Pues está claro que no puede. Se llama principio de realidad. Pero, eso sí, no impide que LinkedIn esté lleno de posts que empiezan con “Los 5 pasos que todo diseñador UX debe seguir” o “El error que está arruinando tu carrera en diseño”. Con todo el cuajo que permite la plataforma.
Y aquí es donde me voy a poner pesado: la gente que más consejos da suele ser la que menos contexto tiene. No porque sean malas personas (nada que ver con eso, salvo alguna cosa), sino porque llevan poco tiempo en esto y todavía no han vivido suficientes fracasos como para saber que lo que les funcionó en su startup de 8 personas en San Francisco no se traduce automáticamente a una consultora europea, a una gran corporación bancaria, o a una cooperativa de autónomos.
La trampa de las trayectorias lineales (y el espejismo de la rapidez)
Me gusta mucho algo que sale en ese hilo de Reddit: las trayectorias no lineales son cada vez más valiosas: el tipo que además de UX es cineasta independiente o la persona que trabajó en desarrollo antes de pasarse a diseño. O uno de mis perfiles favoritos: quien tiene un background en psicología, o en periodismo, o en lo que sea. En resumen: las personas que atesoran esas experiencias tangenciales, que dan la perspectiva que el diseñador que ha seguido el camino correcto nunca tendrá.
Pero, y esto es importante, desde la perspectiva empresarial os aseguro que las trayectorias no lineales dan algo de miedo. Dan miedo porque existe el riesgo real de que la persona pierda el foco, de que modifique su carrera hacia otra parte alejada de la UX o de que un día se despierte y decida que en realidad lo suyo es el cine o la carpintería. Y tiene cierta parte de sentido porque como empresario o como gestor de equipos, tienes que lidiar con esa incertidumbre.
Pero aquí está el truco: esa incertidumbre existe de todas formas. La persona que ha seguido el camino lineal perfecto también puede decidir un día que está quemada y que se va a abrir una panadería en un pueblo. La diferencia es que la persona con trayectoria no lineal probablemente tiene más autoconocimiento, porque ya ha explorado otras cosas y ha decidido conscientemente quedarse en esto. Nunca, nunca perdamos esto de vista.
Y luego tenemos que abordar el otro problema que, desde mi punto de vista, es capital cuando hablamos de desarrollo profesional: la prisa. Todo el mundo quiere que todo pase muy rápido. Gente que lleva dos años en UX y ya está desesperada porque no es senior. Personas que llevan seis meses aprendiendo y ya quieren saber cuál es su especialización. De verdad que tenemos que ponerle freno a esto de una forma o de otra. Es como plantar un árbol y preguntarte a los tres meses por qué todavía no da fruta.
Una carrera profesional no se construye en dos días, ni en dos años, ni en cinco. Se construye en décadas. Con paciencia, con fracasos, con experimentos, con cambios de rumbo, y sobre todo, con mucho trabajo que nadie ve y que no es instagrameable. Lo siento, pero esto es lo que hay.
Por qué hay que desconfiar de los consejos de salón
Ya me he venido arriba, así que ahora viene la parte donde me pongo realmente pesado.
Si alguien te está dando consejos de carrera en UX y cumple alguna de estas características, desconfía:
Lleva menos de cinco años trabajando en esto (y créeme, cinco años es ser generoso)
Su experiencia se limita a un sólo tipo de empresa (startups, grandes corporaciones, agencias)
Nunca ha tenido que tomar decisiones difíciles de negocio relacionadas con contratar, despedir, o gestionar un presupuesto
Vende cursos o coaching de desarrollo profesional como actividad principal
Su consejo empieza siempre con “lo que tienes que hacer es…”
Habla en absolutos: siempre, nunca, todos, ninguno
No te hace preguntas sobre tu contexto antes de darte su opinión
El consejo de salón es fácil de dar. Es cómodo. Es el equivalente profesional a gritarle al árbitro desde el sofá. Pero hay que ser honestos y decir las cosas claras: construir una carrera real, en el mundo real, con sus limitaciones reales (económicas, geográficas, personales, familiares), es otra historia completamente diferente.
Lo que nadie te dice (pero deberías saber)
Por descontado, a estas alturas de mi carrera profesional, me siento mucho más que legitimado para escribir lo que voy a poner a continuación. Esta es la lista de cosas que son ciertas aunque sean incómodas. No son bonitas, no son fáciles de convertir en una infografía de LinkedIn, y probablemente no te gusten. Pero son honestas.
Tu carrera la construyes tú, y no hay atajos. Ningún curso, ningún bootcamp, ningún mentor milagroso va a hacer el trabajo por ti. Pueden darte herramientas, contexto, perspectiva. Pero el trabajo duro y sostenido en el tiempo sólo lo puedes hacer tú.
El autoconocimiento es más importante que las habilidades técnicas. Y el autoconocimiento se consigue con años de probar cosas, fallar, reflexionar, y volver a intentarlo. No leyendo posts de LinkedIn sobre cómo descubrir tu propósito en UX.
Las decisiones de carrera importantes siempre implican renunciar a algo. Si decides especializarte en research, estás renunciando a ser diseñador visual. Si decides liderar equipos, estás renunciando a hacer craft todo el día. Si decides trabajar en una consultora, estás renunciando a trabajar en producto. No existe la opción perfecta que te da todo.
La mayoría de las veces, lo que funciona es hacer lo contrario de lo que está de moda. Cuando todo el mundo está obsesionado con AI y con ser diseñador de productos digitales, puede que haya más valor en convertirte en un experto en investigación cualitativa tradicional. El mercado premia la diferenciación real, no seguir tendencias.
Necesitas mentores de verdad, no influencers de LinkedIn. Un mentor real es alguien que te conoce, que entiende tu contexto, que normalmente ya ha estado donde tú quieres estar, y sobre todo que está dispuesto a invertir tiempo en ti sin esperar nada a cambio.
Tu red profesional importa más que tu portfolio. Y tu red profesional no se construye sólo coleccionando contactos en LinkedIn. Se construye con tiempo, haciendo buen trabajo, siendo generoso con tu conocimiento, cumpliendo tus compromisos, y manteniendo relaciones reales a lo largo del tiempo que mencionaba al principio.
A veces el mejor consejo de carrera es: no lo sé, depende de lo que quieras tú. Porque es verdad. Dependiendo de si priorizas dinero, estabilidad, aprendizaje, impacto, balance con tu vida personal, autonomía, o lo que sea, las decisiones correctas son completamente diferentes. No hay una receta única en ningún caso.
Las trayectorias no lineales son valiosas, pero también son un riesgo. Si vas a explorar otras cosas, hazlo de manera consciente y porque te mueve la pasión. Entiende que estás apostando por diferenciación pero hay que tener siempre muy presente el principio de realidad y asumir la incertidumbre que te va a acompañar. Y, por descontado, ten claro por qué lo haces y qué límites te pones.
La especialización profunda tarda años en construirse y es aburrida. Los posts de LinkedIn hacen que parezca que puedes convertirte en experto en algo en seis meses. Mentira. No te lo creas. La especialización real requiere años haciendo más o menos lo mismo, profundizando, fracasando y refinando. No es sexy ni cool. Pero funciona.
Nadie sabe realmente lo que está haciendo, ni siquiera la gente con 20 años de experiencia. La diferencia es que quien lleva más tiempo lo sabe y está en paz con eso. Quienes llevan poco tiempo todavía creen que existe una respuesta definitiva y están desesperados por encontrarla.
¿Y entonces qué hago?
Si has llegado hasta aquí esperando que te diera cinco pasos accionables para construir tu carrera en UX, siento decepcionarte.
Lo único que puedo decirte es esto: empieza contigo mismo. Hazte preguntas difíciles. ¿Qué es lo que realmente quieres? No lo que deberías querer según LinkedIn, sino lo que tú, con tus circunstancias, con tus prioridades, con tu vida, realmente quieres. ¿Qué estás dispuesto a sacrificar? ¿Qué no estás dispuesto a sacrificar bajo ninguna circunstancia?
Y luego, busca personas que hayan hecho algo parecido a lo que tú quieres hacer, en contextos parecidos a los tuyos, y pregúntales cómo fue. No necesariamente para copiar su camino (porque no vas a poder), sino para entender qué decisiones tomaron, qué trade-offs hicieron, y por supuesto qué les salió bien y qué les salió mal.
Y acepta que te vas a equivocar y vas a meter la pata. Vas a tomar decisiones que en retrospectiva parecerán estúpidas. Ya verás las veces que vas a pensar aquello de: en su cabeza sonaba espectacular. Vas a rechazar oportunidades que luego resultarán haber sido buenas y vas a maldecir por ello. Vas a aceptar trabajos que serán un puto desastre. Forma parte del proceso. Lo importante no es no equivocarse, sino aprender de los errores y seguir adelante.
Porque al final, tu carrera no es una línea recta hacia un objetivo claro. Es un camino lleno de curvas y lleno de decisiones tomadas con información incompleta, de oportunidades que aparecen cuando no las esperas, y de mucho, mucho trabajo que nadie ve.
Y cualquiera que te diga lo contrario, ya te digo yo que te está contando una película.
Este es un soneto, es viernes y hay que destensar, dedicado al hecho de programar notificaciones nocturnas.
Programar envíos en horas donde el mundo duerme plácido y ajeno al teléfono vibrador, es arte que domina cierto funcionario inmundo que ignora que las doce son hora de sopor.
No es que la Seguridad Social me cause temor, ni que su mensaje traiga apocalipsis profundo, es que cuando suena el móvil con ese rumor mi cerebro ya imagina el desastre más rotundo.
«Será urgente«, piensa uno entre sábanas revueltas, «habrá crisis, incendio o conflicto«, te planteas, pero no: son las altas, las bajas, las vueltas
de un sistema que programa sin que lo veas sus envíos a medianoche, con políticas muertas de UX que convierten simples datos en peleas.
P.D.: si alguien de la Seguridad Social lee esto, hay una cosa que se llama «horario de envío recomendado» en cualquier plataforma de comunicaciones. Entre las 9h y las 18h suele funcionar bien. Eso de Programar notificaciones nocturnas no se hace. De nada.
Ayer alguien me preguntó cómo gestionamos los incentivos al hacer UX Research, o lo que es lo mismo, las tarjetas regalo que entregamos a participantes en sesiones de investigación con usuarios. Después de contestarle me di cuenta de que es uno de esos temas que normalmente damos por sabidos, que asumimos que se hace así pero que no siempre documentamos o compartimos de manera abierta.
Cuando hacemos tests de usabilidad, entrevistas en profundidad o llevamos a cabo cualquier otra técnica de investigación que requiera la participación activa de usuarios, compensar su tiempo no es sólo una cortesía profesional: es una cuestión ética y, además, mejora significativamente la calidad del reclutamiento. Quienes han estado en esta parte del negocio lo saben muy bien.
En el Estudio resolvemos esta cuestión usando tarjetas regalo de Amazon Business. Podría ser otra plataforma, aunque la elección es casi lo de menos. Lo que es realmente importante es cómo lo gestionas, porque aquí es donde he visto que muchas consultoras y equipos internos patinan.
Lo que hemos aprendido (a veces a golpes)
Primero: la transparencia es innegociable. Cada tarjeta que compramos tiene que quedar registrada en nuestro sistema: quién la recibe, para qué proyecto, en qué fecha, por qué importe. Parece obvio cuando lo cuento así, pero he visto sitios donde esto se lleva a ojo o en una hoja de cálculo compartida sin control de cambios. Esto acaba siendo un problema, tarde o temprano. Lo digo con conocimiento de causa.
Segundo: la trazabilidad nos salva. Las personas que participan firman necesariamente un documento de recepción del incentivo. No es desconfianza hacia nadie ni nada por el estilo. Es más bien un tema de profesionalidad. Nos protege a nosotros como empresa y protege al participante. Si mañana alguien pregunta ¿a quién le dimos qué?, tenemos respuesta inmediata y ademas documentada.
Tercero, y esto es crítico: consultar con la asesoría fiscal y jurídica. El tratamiento contable de estos incentivos tiene implicaciones que varían según el país, el tipo de contrato que tengas con el cliente, y hasta el perfil del participante. En nuestro caso, todo está documentado y validado por la asesoría. No improvisamos. Y si hay cambios normativos, nos adaptamos antes de que sea un problema.
Cuarto: el proceso es un incentivo en sí mismo. Cuando un participante ve que todo está organizado, que hay un documento claro, que recibe su compensación inmediatamente después de la sesión (o en un tiempo razonable), la experiencia mejora muchísimo. Eso se nota en la calidad de su participación y en la disposición a colaborar en futuras investigaciones.
Recomendaciones prácticas
Si estás montando este sistema en tu equipo o empresa, mi consejo es que diseñes el proceso antes de necesitarlo urgentemente. O lo que es lo mismo: que no te pille el toro. Define quién aprueba las compras, quién las ejecuta, quién las entrega, cómo se documentan. Y todo ello ponlo por escrito.
Crear plantillas para casi todo es una buena idea: solicitud de incentivos por proyecto, documento de recepción, registro en tu sistema de gestión. La estandarización reduce errores y acelera el proceso cuando tienes tres proyectos simultáneos con usuarios. Se llama RersearchOps.
Y sobre todo: no lo trates como un gasto menor o una gestión administrativa anecdótica. Los incentivos forman parte de la metodología de investigación con usuarios. Merecen el mismo rigor operativo que la preparación de guiones, el reclutamiento o el análisis de resultados.
La investigación con usuarios es exigente en muchos aspectos. La gestión de incentivos no debería ser una excepción.
Corría el año 2003 cuando trabajaba diseñando aplicaciones para la TDT. Estamos hablando de píxeles toscos, interacciones rudimentarias y un mando a distancia como dispositivo de entrada, que era la antítesis de cualquier experiencia fluida. En una de las reuniones de trabajo en el equipo, mi jefe (un tipo brillante donde los haya) nos retó a pensar en grande.
Tenemos que crear el próximo bombazo, como quien inventó los SMS premium.
Entre los ejemplos que mi jefe nos lanzó estaba este:
imaginad que la gente pudiera votar el destino de un personaje mientras ve una serie, o pronosticar el resultado de un partido en directo.
Me quedé con esa idea grabada a fuego. No porque fuera nueva, de hecho por aquel entonces la televisión interactiva llevaba años prometiendo revoluciones que nunca llegaban, sino por la ambición que destilaba. Y más, porque yo estaba acostumbrado a participar en reuniones de trabajo donde todo era absolutamente previsible. Pero bueno, que me estoy yendo. Desde entonces, he usado ese momento como referencia cada vez que me enfrento a un producto o servicio con el mandato de mejorarlo o reinventarlo.
Hoy leo que Netflix lanza una función de votación en directo. Veinte años después de aquella conversación, la idea parece que se materializa. Lo que son las cosas, hace dos semanas estuve hablando con un diseñador de producto de la compañía estadounidense. Ahora entiendo que los puntos se conectan, aunque sólo yo vea la línea.
Lo que me fascina no es que Netflix lo haga ahora, sino que haya tardado tanto. La tecnología estaba lista hace una década. El comportamiento de los usuarios también: llevamos años votando, comentando y participando en redes sociales mientras consumimos contenido. Faltaba que alguien con la escala de Netflix apostara por algo así de verdad.
A veces las ideas nacen antes de que el mundo esté preparado para acogerlas. Otras veces esperan a que la compañía adecuada decida que ha llegado el momento. En cualquier caso, me gusta pensar que aquel joven diseñador de 2003 tenía razón al creer que valía la pena soñar en grande.
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.
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 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.
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.
Ilustración de Hugo Tobio
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.
