Anotaciones sobre diseño, experiencia de usuario, liderazgo, user research, emprendimiento, escalado de equipos y negocios digitales.
Autor: torresburriel
Llevo más de 20 años trabajando en diseño digital e investigación con usuarios. Soy CEO de Torresburriel Estudio, miembro español de UXalliance, presidente de UXPA Spain y autor de tres libros sobre diseño digital.
Voy a ser claro: yo entiendo que la gente tiene que vender. Entiendo que por momentos las cosas están apretadas y jodidas. Lo entiendo todo. Y lo entiendo porque yo también he montado una empresa, he fundado Torresburriel Estudio, que este año cumple quince años, somos veintisiete personas, y hemos tenido de todo. Altos, bajos, momentos estelares y momentos francamente complicados. Incertidumbre de la buena y de la mala. Y al final, todo se resume en algo muy simple: si vendes, la cosa funciona; si no vendes, no funciona. No hay más misterio.
Y yo soy el primero que lo sabe porque, básicamente, quien vende en mi empresa soy yo. Obviamente no solamente yo, pero es una empresa que lleva mi nombre, yo soy el fundador, y creo que está bastante claro que uno de los roles principales que me toca cumplir es el de un tipo que vende. Que además hace otras cosas, pero que vende.
Mi manera de vender: a fuego lento
He ido aprendiendo esta profesión de la venta y el desarrollo de negocio con el tiempo. Exactamente igual que aprendí a gestionar una agencia, a gestionar personas y a gestionar equipos. Nadie nace sabiendo vender. Lo que sí puedo contar es cómo lo hago yo.
Mi empresa creció de manera orgánica. Lo he contado muchas veces, pero no me importa repetirlo porque creo que tiene valor: yo empecé porque monté un blog. El blog de torresburriel.com. Y a partir de ahí, la gente me empezó a leer, me empezó a conocer y me empezó a llamar. Primero para pequeñas consultorías. Luego para proyectos más grandes. Después para cosas que requerían de más equipo del que yo solo podía aportar. Y cuando alcancé el límite máximo de lo que podía abordar por mi cuenta, empecé a contratar gente. Así hasta hoy.
Eso es un crecimiento orgánico. Y mi venta siempre ha sido orgánica. Lo he hecho compartiendo contenido, compartiendo lo que sabía, tratando de ayudar a otros haciendo lo que mejor se me da: escribir, contar lo que sé, y hacerlo de una manera particular. Sin fórmulas mágicas. Sin trucos. Sin plantillas copiadas de ningún lado.
Hoy las necesidades económicas de mi empresa son absolutamente exigentes. Somos veintisiete personas y la máquina tiene que seguir girando. Me toca vender más, claro. Pero la venta sigue siendo la misma: a fuego lento. Se cuece despacio. Obviamente siempre hay ventas rápidas, gente que viene, pregunta, quiere algo, se lo ofrecemos, le gusta y lo compra. Pero los grandes proyectos, los que nos tienen ocupados de verdad, se venden mientras dura el proceso comercial y también se siguen vendiendo mientras dura la ejecución del servicio. Cada entrega es una carta de presentación para la siguiente.
Lo que hay detrás de la venta a fuego lento
Todo esto se hace con honestidad. A veces con mucha fricción. La mayoría de las veces con esfuerzo. Equivocándote. Siendo humilde y reconociendo cuando lo haces mal. En definitiva: ganándote la confianza de las personas para quienes trabajas.
Esto no es ningún secreto. No es una metodología revolucionaria ni un framework con nombre en inglés. Es simplemente tratar a la gente como te gustaría que te tratasen a ti. Es entender que la confianza no se compra con un correo bien redactado, sino con tiempo de trabajo consistente, de cumplir lo que prometes y de dar la cara cuando las cosas se complican.
A veces parece que la gente cree que esto no se puede hacer así. Que hay que buscar atajos. Que si no estás haciendo outbound agresivo, estás perdiendo oportunidades. Que si no automatizas el envío de quinientos correos al día, eres un ingenuo.
No lo creo.
Lo que no deberías hacer
Y ahí es donde llega ese tipo de personas que entran en el correo electrónico de los demás sin preguntar, sin pedir permiso, ofreciendo soluciones mágicas y contando milongas. Es absolutamente espantosa la imagen que dejan las personas que intentan vender un producto o un servicio tratando de disimular que conocen a su interlocutor, cuando no han hecho el menor trabajo de investigación. No se han mirado ni tu web. No saben a qué te dedicas. No tienen ni idea de cuáles son tus necesidades reales. Y pretenden que les abras la puerta de tu negocio porque te han escrito un correo con tu nombre y una frase supuestamente personalizada.
La personalización de verdad no es meter el nombre de alguien en el asunto de un correo. La personalización de verdad es saber a quién le hablas, entender sus problemas, respetar su tiempo y encontrar la mejor forma de presentarte por primera vez. Y si no estás dispuesto a hacer ese trabajo previo, no vendas. O al menos no pretendas que te tomen en serio.
El resumen
Vender no es malo. Vender es necesario. Es lo que mantiene empresas, equipos y proyectos en marcha. Lo que es malo es vender sin criterio, sin respeto y sin haber hecho los deberes. Lo que es malo es tratar al otro como un lead en una hoja de cálculo en vez de como una persona que tiene su propio contexto, sus propias necesidades y su propia forma de decidir.
Mi método no es perfecto ni es rápido. Pero es honesto. Y después de un buen montón de años, puedo decir que funciona.
Por momentos me guardo las ganas de escribir esto. Y por momentos, como ahora, no puedo guardármelas porque necesito soltar una idea que me ronda la cabeza día sí y día también.
Imaginad que alguien llama a la puerta de vuestra casa. No le conocéis. No le habéis invitado. Pero insiste en que le abráis porque tiene algo que os interesa, que lo necesitáis, y que os lo va a dar porque hoy es vuestro día de suerte. Si eso pasara en la vida real, diríamos devesa persona que tiene una tuerca suelta.
Pues bien, algo parecido sucede cada día en mi bandeja de entrada.
No sé si es el último bootcamp de ventas, el último coach que ha descubierto el fuego, o las plantillas milagrosas que circulan por ahí. El caso es que recibo correos de gente que no sé de dónde ha sacado mi dirección, que incumple con alegría toda la legislación europea de privacidad habida y por haber, y que tiene la desfachatez de recriminarme que no le conteste. Que estoy ignorando la oportunidad de mejorar mis ventas. O de hacer más feliz a mi equipo. O de escalar mi negocio. Ponga usted aquí la promesa que quiera. Manda huevos.
Lo peor no es el spam. El spam tiene la decencia de no tomárselo a personal. Lo peor es el tono. Ese tono de te estoy haciendo un favor y tú no te enteras. Ese seguimiento agresivo disfrazado de persistencia. Esos correos de veo que no has abierto mi anterior mensaje como si mi silencio fuera un error que debo corregir.
No. Mi silencio es mi respuesta.
Llevo quince años con mi empresa. Nadie que me conozca mínimamente pensaría que lo que necesito es que un desconocido me diga cómo vender mejor o cómo gestionar a mi equipo. Y aunque lo necesitara, no sería a través de un correo no solicitado, escrito con una plantilla, enviado en masa, y que viola sin pestañear las normas más básicas de respeto profesional.
Esto no va de ser antipático; quizá ese grado de avinagramiento, me acompañó en tiempos pasados pero no ahora, en ningún caso. Va de poner las cosas en su sitio. Si quieres venderme algo, gánate el derecho a mi atención. Aporta antes de pedir. Conoce a quién le escribes. Respeta que el no también es una respuesta.
Y si todo eso te parece demasiado esfuerzo, quizá el problema no sea que yo no te haga caso. Quizá el problema sea tu método.
En estos casos me gustaría poder enviar un GIF como respuesta, pero las normas de urbanidad que me autoimpongo me lo impiden.
Hoy vengo con algo muy concreto de lo que escribiré más a menudo este año. Y es que hay una disciplina que lleva años ganando peso en los equipos de investigación con usuarios y que, sin embargo, sigue siendo la gran desconocida en el ecosistema de producto digital en español: ResearchOps, o lo que es lo mismo, las operaciones de investigación.
Ilustración de Hugo Tobio
La idea es sencilla de explicar y a su vez compleja de ejecutar. ResearchOps se ocupa de todo aquello que permite que la investigación con usuarios funcione de forma sostenible: desde la gestión de participantes y el consentimiento informado, hasta los repositorios de conocimiento, las herramientas utilizadas, los flujos de trabajo y la gobernanza de los datos cualitativos y cuantitativos que generamos en todo este proceso.
Una necesidad que nace de la práctica, no de la teoría
En Torresburriel Estudio llevamos trabajando en operaciones de investigación desde 2018. No porque leyéramos un artículo que nos iluminara, sino porque la realidad nos obligó. La carga de trabajo en el área de investigación con usuarios creció hasta un punto en el que ya no bastaba con hacer bien los tests con usuarios, las entrevistas en profundidad o los análisis. Necesitábamos estructura operativa para que todo ese conocimiento no se perdiera entre proyectos.
Los modelos de rolling research que desplegamos con nuestros clientes nos lo exigían. Y es que cuando se despliegan procesos de investigación con usuarios de forma continuada, no podemos permitirnos reinventar la rueda cada vez que arrancamos un ciclo. Necesitamos procesos, plantillas, repositorios y criterios compartidos. Necesitamos, en definitiva, operaciones.
De la necesidad al aprendizaje sistematizado
Lo interesante de estos años es que hemos ido acumulando un conocimiento práctico que ahora estamos convirtiendo en piezas pedagógicas. Los aprendizajes de casi una década operando investigación a escala nos han permitido entender qué funciona y qué no cuando intentas profesionalizar esta capa operativa. Y os aseguro que el proceso ha sido absolutamente fascinante. No ha sido fácil, eso sí.
Una de las lecciones fundamentales es que ResearchOps no va de industrializar la investigación. Va de crear las condiciones para que el aprendizaje fluya, se comparta y se reutilice. Es una diferencia sutil pero con un impacto práctico enorme, que al final se nota en los procesos de onboarding y en la propia gestión de proyectos de investigación con usuarios.
Por qué ahora
El momento, por mucho que las operaciones de research sean a veces invisibles, es relevante. Los equipos de producto maduros ya no discuten si hay que hacer investigación con usuarios. La conversación en esos equipos ha evolucionado hacia cómo escalar esa investigación sin perder rigor, cómo democratizar el acceso a los hallazgos y cómo convertir la investigación en un activo organizativo en lugar de sólo un output de proyecto.
Eso es exactamente el territorio de ResearchOps. Y pronto tendré muuuuucho más que contar al respecto.
Hoy ha sido un lunes al que definiría como una tormenta de arena. No voy mojado, si no me miras muy de cerca no se me nota, aparentemente mi ropa no está sucia, no me he despeinado. Pero me escuecen los ojos, tengo incomodidad en todo el cuerpo, me pica todo.
Ilustración de Hugo Tobio
Enero ha sido un mes complicado en el Estudio. Pero no por las razones que podríais imaginar. Los números están bien. Trabajo hay de sobra. Proyectos, también. Clientes, más que nunca.
Y ahí está exactamente el problema.
Cuantos más clientes, más interlocutores. Más procesos. Más personas en el equipo. Más situaciones que pueden generar fricción, rozamiento, principio de conflicto. No hablo de nada dramático, hablo de la acumulación de pequeñas gestiones, pequeñas tensiones, pequeñas decisiones que alguien tiene que tomar o ayudar a desbloquear. Y ese alguien, en última instancia, soy yo.
Tengo un equipo de gestión estupendo. De verdad. Pero hay cuestiones que terminan llegándome: a veces para decidir, a veces para sugerir un enfoque, a veces simplemente para escuchar cómo alguien del equipo comparte lo que le preocupa. Y todo eso se va sedimentando, poco a poco, generando una capa de incomodidad que por momentos me quita la alegría.
Quizá quitar la alegría sea una expresión un tanto exagerada. Pero es la mejor forma de decirlo que me sale ahora mismo, y prefiero ser impreciso que deshonesto.
Esto es algo que quienes emprendemos en solitario conocemos bien. Sin socios con los que repartir el peso. Sin grupos inversores que te den soporte y capital cuando las cosas se ponen regular. Sin nadie que un martes por la noche te diga tranquilo, esto lo sacamos entre los dos. Estás tú. Con tu criterio, con tu experiencia y con tus dudas.
Sé que esto es una carrera de fondo. Sé que todo llega y todo pasa. O al revés. Sé que he estado aquí otras veces y que he salido. Pero también sé que nunca lo había contado de una manera así.
¿Por qué ahora? Pues por algo tan simple como necesitar desahogarme. Soltarlo. Escribirlo, leerlo, releerlo. Esto es un poco de terapia, ni más ni menos.
No busco consejos. No busco que nadie me diga que todo va a ir bien. Sólo necesitaba sacarlo fuera y darme permiso para decir que hoy, un lunes de febrero, la arena me ha escocido un poco más de la cuenta.
Estos días se habla mucho de la prohibición de redes sociales a menores de 16 años. Estoy a favor. Pero no vengo a debatir eso, hay argumentos en todas direcciones y cada cual que llegue a sus conclusiones. Lo que ahora me ocupa como profesional del diseño de experiencia de usuario es otra cosa: es cómo se implementa la verificación de edad en productos digitales.
Llevo años viendo y contando cómo funcionan los dark patterns, las métricas de engagement diseñadas para generar adicción y las interfaces que explotan vulnerabilidades cognitivas. Que ahora el legislador ponga límites no me parece censura: es reconocer que el diseño no es neutral. Quienes diseñamos productos digitales tenemos una responsabilidad que durante demasiado tiempo hemos delegado en el es lo que pide el negocio. Ya era hora de asumirlo, me parece a mí.
Verificación de edad sin arruinar la experiencia
Pero vamos a dejarnos de historias y vamos a lo que es nuclear. El reto de verdad, desde mi punto de vista, está en conseguir verificación de edad efectiva sin convertir el registro en un infierno burocrático. Es un problema de diseño complejo. Las soluciones fáciles (declarar tu edad, marcar una casilla) no sirven para nada. Las que son más robustas (verificación documental, biometría) pueden ser invasivas o dejar fuera a usuarios. El equilibrio existe, pero requiere inversión en diseño e investigación, no parches cosméticos para cumplir el expediente.
Y lo digo claramente: esto no va de tecnología, va de voluntad. Los mecanismos técnicos para verificar edad existen. El problema nunca ha sido técnico: ha sido que a nadie le convenía implementarlos. Ahora que es obligatorio, veremos si las plataformas invierten en hacerlo bien o buscan el mínimo cumplimiento legal. Tengo mis sospechas sobre qué camino elegirán, al menos al principio.
Nuestro papel como UX es vigilar y auditar
Así que nuestro papel ahora, como profesionales UX, es auditar. La ley marca el qué. El cómo es territorio de diseño. Y ahí es donde creo que tenemos algo que decir: ¿los flujos de verificación son accesibles? ¿Respetan la privacidad? ¿Son comprensibles para usuarios de distintas edades? ¿Excluyen injustamente a determinados grupos? Vigilar esto forma parte de nuestro trabajo desde ya mismo.
Hace unos días, en la previa de la BilboStack 2026, estuve viendo una charla de Bart Farrell sobre creación y gestión de comunidades profesionales. Y mientras escuchaba, me encontré viajando mentalmente veinte años atrás, a aquel abril de 2005 en el que convoqué el primer Cocktail Cadius en Zaragoza.
Ilustración de Hugo Tobio
Bart hablaba de comunidades Cloud Native, de Slack con 17.000 personas, de livestreams globales, de embajadores repartidos por todo el mundo. Y yo recordaba cuando quedábamos el primer jueves de cada mes en un bar de Zaragoza para hablar de usabilidad con quien quisiera aparecer. Sin Slack, sin Discord, sin herramientas de gestión de comunidades. Con un blog en Blogia y muchas ganas.
Confieso que siento algo parecido a la envidia cuando veo a los responsables de comunidad actuales. Reconozco que hay una parte de mí que desearía dedicar más tiempo a ese trabajo. El principio de realidad me dice que mi sitio ahora está en otro lugar, pero la conexión emocional con aquella etapa sigue muy viva. Fueron años en los que fui muy, muy feliz gestionando de manera voluntaria el nacimiento y crecimiento de una comunidad. La de diseño y experiencia de usuario en Zaragoza.
El nacimiento de algo que no sabíamos que era importante
En 2005 la usabilidad era una palabra que sonaba a ciencia ficción en España. Existía Cadius, la Comunidad de Arquitectura De Información y USabilidad, una comunidad que funcionaba principalmente a través de internet y en la que celebraba encuentros mensuales en diferentes ciudades. Madrid y Barcelona tenían los suyos. Zaragoza no tenía nada.
Un día decidí que eso tenía que cambiar. No había un plan estratégico, ni un documento de objetivos, ni siquiera una idea clara de lo que podía salir de ahí. Simplemente pensé que sería interesante juntarnos unas cuantas personas que trabajábamos en diseño web para hablar de usabilidad y arquitectura de la información. Así, sin más pretensiones. El empujón definitivo me lo dió Ruben Pamplona y me animé a organizarlo.
El primer Cocktail Cadius de Zaragoza fue una convocatoria informal. Quedamos en un sitio, sin agenda, sin ponentes, sin nada que se pareciera a un evento organizado. Éramos unos cuantos locos, como se solía decir, hablando de cosas que al resto del mundo le parecían irrelevantes.
Y de ahí salió algo que duró ocho años.
El crecimiento: cuando lo informal se convierte en referencia
Al año siguiente, en marzo de 2006, celebramos el primer aniversario de Cadius Zaragoza con un evento en el Milímetro Digital de La Almozara. Un taller de Ruby on Rails y una charla sobre buenas prácticas en diseño web. Colaboraron Net2u, Warp Networks y la Asociación de Vecinos de La Almozara. La entrada era libre, claro.
Esa fue la primera vez que sentí que aquello había dejado de ser una quedada de colegas para convertirse en algo con cierta estructura. Seguía siendo informal y seguía siendo voluntario, pero ya había gente que esperaba que convocaras el siguiente encuentro. Y eso genera una responsabilidad que nadie te pide pero que asumes porque quieres que funcione. También os digo que todo esto lo hacía porque los niveles de motivación sobrepasaban cualquier recipiente. Las ganas, la fuerza, el empuje, la ilusión y la permanente sensación de descubrimiento eran un combustible inagotable para abordar casi cualquier cosa que se me pusiera por delante.
En noviembre de 2006 llevamos Cadius Zaragoza al parque tecnológico Walqa, en Huesca. Nos desplazamos en coches compartidos para visitar el Laboratorio Aragonés de Usabilidad. Hicimos un test con usuarios reales, cenamos juntos, y algunos compañeros escribieron crónicas que aún se pueden encontrar por ahí. El equipo del Laboratorio tomó en consideración las recomendaciones que surgieron de aquella visita y rediseñaron su web. José Antonio Chavarría hizo una propuesta que sirvió como punto de partida. Fue un caso de éxito rotundo de la comunidad.
Bart mencionó en su charla algo que me resulta a familiar: el burnout. Dijo que se había encontrado con él varias veces por no haber calculado bien cuánta energía tenía que invertir, no para arrancar, sino para sostener las iniciativas. Eso es exactamente lo que me pasó. También es cierto que yo cuando lo hacía, lo hacía en un plano 100% voluntario.
Organizar una comunidad de manera voluntaria tiene una trampa. Al principio todo es novedad, ilusión, primeras veces. Cada encuentro es una pequeña victoria. Pero llega un momento en el que la novedad desaparece y queda la rutina. Convocar, buscar sitio, confirmar asistencias, preparar contenido, gestionar imprevistos, repetir. Mes tras mes. Año tras año. Obviamente, eso desgasta.
En febrero de 2011 tomé una decisión difícil: ceder las riendas de Cadius Zaragoza a Dani Latorre y Mamen Pradel. Mis fuerzas ya flaqueaban y no podía atender mucho más que mi trabajo. Había llegado a mi límite aunque me costó hacerme a la idea y reconocerlo.
El 5 de septiembre de 2013, primer jueves de mes, no hubo Cadius Zaragoza. Y no lo hubo más. Fueron ocho años de reuniones más o menos informales, más o menos estables, más o menos concurridas. Pero llegó un momento en el que hubo que poner punto final.
Lo que funcionó entonces y sigue funcionando ahora
Escuchando a Bart hablar de sus aprendizajes con comunidades Cloud Native, me di cuenta de que muchas cosas no han cambiado en veinte años. Las herramientas son otras y la escala es diferente, pero los principios son prácticamente los mismos.
Bart habló de ofrecer y no pedir. También de crear espacios donde la gente pueda aprender, compartir conocimiento y estar con otras personas con las que comparten las mismas inquietudes. Eso era exactamente lo que hacíamos en Cadius Zaragoza. No pedíamos nada a cambio. Ofrecíamos un lugar donde juntarse con gente que hablaba tu mismo idioma profesional. Aunque es verdad que lo pasábamos bien. Muy bien.
Habló también de espacios seguros en los que alguien puede hacer una pregunta sin miedo a ser juzgado. En nuestros encuentros, como decía Óscar Embún, se trataba de cambiar la forma de pensar y restar protagonismo a la tecnología para volver la vista a los usuarios, a las personas. Silvia Arcos lo resumía mejor: en realidad lo importante son los usuarios, las personas. Ese era nuestro espacio seguro.
Habló también de empatía como requisito fundamental. De pensar en las necesidades de los demás antes que en las propias. De diseñar experiencias pensando en quién va a participar. Nosotros lo hacíamos de manera intuitiva, sin metodología formal, pero la esencia era la misma.
Y habló también de tener un propósito claro. En la comunidad Data on Kubernetes que gestionó, si alguien llegaba hablando de videojuegos, estaba y se le consideraba como fuera de lugar. Nosotros teníamos claro que hablábamos de usabilidad, arquitectura de información, diseño de interacción y disciplinas centradas en el usuario. Aunque también teníamos claro que la procedencia de personas de fuera del ámbito de estas disciplinas, traía otras conversaciones. Y la integración resultó una mezcla perfecta de armonía, colaboración y mutuo aprendizaje.
Lo que ha cambiado: las herramientas y la escala
Bart mencionó que a través de todos los canales que gestionaba llegó a tener alrededor de 17.000 personas en la comunidad. Livestreams, podcasts, informes anuales, embajadores en todo el mundo y recursos traducidos a varios idiomas. Con perras, chufletes, que se diría en mi pueblo.
Nosotros teníamos un blog en Blogia, una lista de correo y el boca a boca. Las convocatorias se publicaban en el blog y se difundían por email. Las crónicas las escribían los asistentes en sus propios blogs y las enlazábamos. Las fotos se subían a Flickr. No había métricas sofisticadas, no había dashboards, no había analytics.
Y sin embargo, funcionó durante ocho años.
Hoy las herramientas permiten escalar de una manera que entonces era impensable: Slack, Discord, Notion, herramientas de streaming, y podcasts distribuidos a escala global. Bart puede coordinar una comunidad con personas de la India, Guatemala, Japón o España desde su casa en el País Vasco. Nosotros coordinábamos encuentros presenciales en Zaragoza con gente que vivía como mucho a una hora en coche.
La comunicación es infinitamente más eficiente ahora. La viralidad existe. Un contenido puede llegar a miles de personas en horas. En 2005 teníamos que confiar en que alguien leyera nuestro blog, lo encontrara interesante y lo compartiera en el suyo. Pero tengo que reconocer que mi visión tiene el sesgo de los pioneros.
El sesgo de los pioneros
Cuando no existen las herramientas, todo es más difícil pero también es más emocionante. Cada cosa que conseguíamos tenía un sabor especial porque éramos muy conscientes de que lo habíamos conseguido con muy poco. La primera vez que conseguimos que viniera un ponente de fuera de Aragón fue una fiesta. La primera vez que un periódico local publicó una noticia sobre nosotros flipamos. La primera vez que alguien nos dijo que había encontrado trabajo gracias a los contactos de Cadius fue la confirmación de que aquello tenía sentido. Aunque en aquel momento nos parecía también flipante y nuestro nivel de inconsciencia nos permitía seguir adelante sin tomarnos las cosas demasiado en serio. El análisis y la visión que tengo ahora son mucho más serios, pero en aquel entonces todo era mucho más ligero, informal e inconsciente.
Esas primeras veces no se pueden replicar lamentablemente. Da igual cuántas herramientas tengas, da igual cuántos recursos manejes. La emoción de construir algo desde cero, cuando nadie más lo está haciendo, cuando no hay manual de instrucciones, cuando cada paso es territorio inexplorado y cuando todo te da un poco igual, esa emoción es irrepetible.
Quizá también es una cuestión de que añoramos lo que ya se fue. La nostalgia tiene esa capacidad de hacer más bonito el pasado y hacernos olvidar las dificultades. Pero incluso siendo consciente de ese sesgo, sigo pensando que aquellos años tuvieron algo especial que las comunidades actuales, con toda su sofisticación, no pueden reproducir.
Bart habló de prueba y error, de paciencia, de no abandonar después de dos o tres intentos. Nosotros tuvimos que aprender todo eso sin referentes, sin metodologías documentadas, sin comunidades de práctica sobre cómo gestionar comunidades de práctica. Aprendimos haciendo, equivocándonos, volviendo a intentar. Pero también pasándolo estupendamente bien, creando unos vínculos personales que aún se mantienen en muchos casos, y sabiendo que nuestro día a día era un permanente aprendizaje.
Lo que queda
Entre 2004 y 2011 lideré Cadius Zaragoza. De 2008 a 2012 presidí UPA Spain, ahora UXPA Spain. Fueron años intensos, de mucho aprendizaje y de conocer a gente extraordinaria. Gente como Silvia Arcos, José Antonio Chavarría, Javier Mendívil, Roberto Abizanda, y tantos otros que pasaron por aquellos encuentros y que hoy siguen trabajando en esto.
Cadius Zaragoza fue el evento que hizo despertar del letargo a un buen número de personas. Y en el que otros se fijaron para dinamizar la vida tecnológica zaragozana más allá de las pantallas. De algo sirvió.
Escuchando a Bart hablar de sus comunidades globales, con sus herramientas sofisticadas y su alcance mundial, me alegro de que existan. Son necesarias. Hacen un trabajo importante. Pero también me alegro de haber vivido aquellos años en los que todo era más pequeño, más artesanal, más cercano y más inconsciente.
La emoción de las primeras veces la recuerdo como insustituible. Y aunque probablemente en 2026 hay cuestiones que se gestionan de manera más eficiente que en 2005, hay algo que ninguna herramienta puede darte: la experiencia de haber construido algo cuando nadie más lo estaba haciendo.
Este pasado fin de semana he estado en la BilboStack 2026 y me he quedado con ganas de escribir sobre la charla de Carlos Iglesias. No porque dijera cosas que no supiéramos (la mayoría llevamos años masticando estas ideas) sino más bien por cómo las ha articulado y, sobre todo, por lo que hizo después.
ilustración de Hugo Tobio
El problema que todos conocemos
Carlos arrancó fuerte y honesto poniendo encima de la mesa algo que reconocemos enseguida quienes llevamos tiempo en esto: organizaciones que invierten cantidades obscenas de dinero en productos que nadie quiere usar. No es algo nuevo, pero es verdad que sigue pasando. Y sigue pasando porque las causas de fondo no se atacan.
La ley de Conway, los silos en las organizaciones y la obsesión por el output. Vaya trío. Todo esto lo hemos visto, lo hemos sufrido, y en muchos casos seguimos sufriéndolo. Carlos lo explicó bien: esa delegación de responsabilidad donde cada departamento se enfoca en sus entregables y le pasa el muerto al siguiente. El famoso el perro no es mío que tanto nos suena, ¿verdad?
La cuestión. Lo interesante es cómo conectó esto con lo que llamó la fetichización de los modelos. Spotify, Scrum, Kanban, Dual Track… Da igual el modelo. Lo adoptamos, lo pervertimos, y cuando no funciona decimos que el modelo no vale. En realidad lo que hemos hecho es quedarnos en la capa superficial sin entender del todo los principios que lo sustentan.
La propuesta: darle la vuelta al enfoque
La tesis central de Carlos es bastante sencilla de enunciar y un poco más difícil de ejecutar: en lugar de empezar por el output y esperar que mágicamente cambie comportamientos e impacte en negocio, empezar por definir qué es impacto y trabajar hacia atrás.
Aquí es donde entra su framework, que ha llamado Impact-Driven Growth. La arquitectura que Carlos propone tiene su sentido: una métrica de valor percibido por el cliente (CPVM) en la cúspide, métricas de impacto que te digan dónde enfocar el aprendizaje, y outcomes entendidos como cambios medibles de comportamiento. Todo esto antes de ponernos a idear iniciativas. Así de primera impresión puedo decir que me gusta. Bastante.
No voy a entrar en si esta estructura es mejor o peor que otras que existen. Lo que me parece valioso es el ejercicio de formalización. Carlos ha cogido 23 años de experiencia, los ha destilado en un modelo y los ha puesto sobre la mesa para que otros los usen, los critiquen o los mejoren. Ya sólo por eso la charla mereció la pena.
El cacharro: cuando la teoría se hace herramienta
Y aquí viene lo que me pareció más interesante de la charla: no se quedó en el framework teórico, y honestamente esto no es algo que uno no se suele encontrar habitualmente. Han construido una herramienta, que de momento llaman el cacharro, que implementa este modelo. Es algo así como un sistema experto que te acompaña en el proceso a la hora de definir métricas, de identificar comportamientos y de generar hipótesis.
La demo en directo tuvo sus momentos de tensión, como todas las demos en directo. Pero tuvimos la oportunidad de ver lo esencial: una herramienta que te hace las preguntas adecuadas, te propone métricas basadas en tu contexto, te ayuda a identificar outcomes y te genera un plan de hipótesis priorizadas. Si lo hubiese anunciado de esa forma, me hubiese generado un hype del que aún no me habría recuperado. Pero Carlos optó por contarlo poco a poco, enseñándolo.
Lo que me gusta de este enfoque es la intención de minimizar la fetichización. Si el problema es que adoptamos modelos sin entender sus principios, la solución pasa por crear un acompañamiento que nos guíe en la aplicación correcta. No nos da las respuestas sino que lo que hace es ayudarnos a encontrarlas.
Lo que sí podemos cambiar
Carlos encauzó el tramo final de su exposición con una idea que me pareció honesta: hay cosas que no podemos cambiar. La estructura formal de la organización, las habilidades de las personas a corto plazo o las piedras en el camino. Pero hay algo que sí podemos cambiar: las conversaciones. A eso añadió algo que me gustó bastante, porque le puso el principio de realidad: tenemos que dejar de lloriquear y de quejarnos.
Si todas las conversaciones que tenemos son sobre “output, output, output”, nuestras posibilidades de impacto se quedan limitadas. Pero si introducimos métricas de valor, outcomes e hipótesis cambiamos el marco de la conversación. Y eso sí que está en nuestra mano.
Una nota personal
Conozco a Carlos desde hace tiempo y le tengo aprecio. Por eso no quiero que esto suene a palmadita en la espalda. Lo que hace falta en esta industria es más gente que se atreva a compartir sus frameworks, sus herramientas y sus formas de trabajar. No para que los demás los adoptemos sin criterio, sino para que los evaluemos, los combinemos con nuestra propia experiencia y avancemos de manera colectiva. Que para eso somos una comunidad.
El modelo tendrá sus limitaciones, el cacharro tendrá sus bugs, y seguramente en un año Carlos estará iterando sobre todo esto. O no. Pero eso es precisamente lo valioso: el acto de formalizar, compartir y exponer al escrutinio público lo que uno ha aprendido, ni más ni menos ante una audiencia del nivel de la BilboStack.
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
