Categoría: Diseño

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

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

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

El problema de la fragmentación

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

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

Sistemas de diseño como infraestructura

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

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

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

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

El valor del Playbook UX

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

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

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

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

Plataformas low-code como base del ecosistema

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

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

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

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

El perfil de desarrollador como usuario

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

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

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

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

Migración progresiva y deuda técnica

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

Aplicaciones nuevas

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

Aplicaciones existentes

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

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

Conclusión

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

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

No es fácil.

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

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

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

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

Diseñar para que no tengas que confiar

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

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

Dans dice que ha tenido una experiencia estupenda.

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

El humanismo digital es entender lo incómodo

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

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

El precio de no venderte

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

Para terminar

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

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

Llevo varios meses observando cómo mi timeline de LinkedIn y Twitter se llena de tutoriales sobre Claude Code. Antes fue Cursor, antes V0, antes Lovable, antes ChatGPT. Siempre hay una herramienta nueva que genera un patrón muy parecido: early adopters entusiastas, contenido tutorial en cascada por todas partes, promesas de productividad exponencial, y esa sensación de estar perdiéndote algo fundamental si no te subes al carro. Yo no sé en vuestro caso, pero esto último lo llevo regular.

De todos modos no me malinterpretéis: Claude Code es extraordinario. Lo uso. Me ahorra tiempo. Genera código que funciona. Eso no es tan duda. Exactamente igual que Lovable o Gemini. Pero no voy a escribir sobre cómo usar estas herramientas, ni a hacer hilos explicando sus capacidades, ni a posicionarme como experto en una herramienta que dentro de seis meses puede ser irrelevante o estar integrada en algo más grande que la deje desactualizada. No será porque no haya pasado ya suficientes veces.

Fuera del mainstream divulgativo por decisión

Aquí viene lo interesante y en lo que me gustaría incidir: esta decisión me coloca conscientemente fuera del mainstream divulgativo actual. Mientras otros legítimamente acumulan visibilidad explicando el qué y el cómo de cada novedad, yo sigo empeñado en hablar del para qué y del por qué. De gobernanza de diseño, de liderazgo de equipos distribuidos, de sistemas que escalan, de ética en la construcción de producto digital.

Es una apuesta arriesgada en términos de alcance inmediato, lo sé. Y mucho más en tiempos como los actuales. El contenido sobre herramientas específicas genera engagement porque resuelve problemas concretos y urgentes. “Cómo usar X para hacer Y en Z minutos” funciona. Lo sé perfectamente. Lo veo funcionar todos los días. Pero tiene fecha de caducidad. Esto es algo que ya ponía en práctica cuando dirigía la Escuela de Diseño en Platzi: el mejor contenido es el evergreen, porque los estudiantes aprenden más, es más sostenible y desde una perspectiva de negocio es más rentable. Aunque, una vez dicho esto, es justo precisar que cada estrategia tiene su sentido en el contexto en el que se inscribe. Y yo estoy compartiendo el mío, que tiene sus circunstancias y que explican esta decisión.

Criterio profesional frente a dependencia tecnológica

Lo que intento construir aquí va también en esa línea. Llevo 23 años escribiendo sobre diseño y experiencia de usuario, y algo que he aprendido es que las herramientas son commodities temporales. Lo que perdura es el criterio profesional para saber qué problema estás resolviendo, para quién, y si esa solución es la adecuada en un contexto específico. La capacidad de gobernar sistemas de diseño, de crear entornos donde la gente pueda hacer mejor su trabajo o de mantener la coherencia estratégica en organizaciones complejas. El proyecto es grande, apasionante y, si os digo la verdad, sigo aprendiendo todos los santos días desde aquel septiembre de 2003, en el que me lié la manta a la cabeza, sin saber dónde acabaría.

No estoy diciendo que hablar de herramientas sea malo. Es necesario y es valioso, además de legítimo. Simplemente no es lo que yo quiero aportar. Prefiero ser el que ayuda a decidir si necesitas esa herramienta, cómo integrarla en tu stack sin generar dependencias críticas o ayudarte a entender qué implicaciones tiene para tu equipo y tu governance.

Agnosticismo tecnológico como estrategia

Uso IA generativa a diario. Claude para escribir, para explorar ideas, para documentar procesos. Gemini para sintetizar sesiones de trabajo o de campo. NotebookLM para escudriñar documentación, Lovable para conceptualización visual. Mocha para generar POCs a la velocidad del rayo. V0, Orchids, Google AI Studio y HeroUi Chat para enseñar a mis estudiantes.

Pero no me caso con ninguna. Mantengo agnóstico el criterio y pago por todas ellas (un presupuesto, oiga). Estoy seguro de que dentro de dos años estaremos usando otras cosas, y lo que importará seguirá siendo saber construir un producto que funcione para usuarios reales que se mueven en contextos específicos.

El coste y el valor de la sostenibilidad editorial

Esta posición tiene un coste: menos visibilidad inmediata, menos viralidad, menos sensación de estar en la cresta de la ola. Pero tiene algo que valoro más: sostenibilidad. Y cuidado, la sostenibilidad es una estrategia de visibilidad, pero también de adquisición y retención.

El contenido que escribo hoy en día y aquí sobre cómo estructurar un equipo de diseño, sobre cómo gestionar stakeholders difíciles, sobre cómo implementar DesignOps o ResearchOps en organizaciones distribuidas, seguirá siendo relevante dentro de cinco años. Los tutoriales de herramientas, no tanto. Este es un criterio y una decisión editorial.

Más allá de la ansiedad del early adopter

Y, además de todo lo que acabo de describir, hay algo más profundo, que me importa más. Esa obsesión colectiva con estar al día de cada novedad tecnológica genera una ansiedad profesional innecesaria. Esa sensación permanente de estar quedándote atrás si no dominas la última plataforma. Es algo agotador y contraproducente.

Lo que diferencia a un profesional senior no es conocer en detalle todas las herramientas, sino tener el criterio para saber cuándo, cómo, en qué contexto y por qué usar cada una.

La apuesta por lo que perdura

Así que seguiré aquí, en este blog personal intencionadamente periférico respecto al mainstream del momento, escribiendo sobre lo que creo que importa a largo plazo. Sobre liderazgo en diseño sin paternalismo, sobre construir equipos que funcionen, sobre mantener la dignidad profesional en entornos complejos, sobre diseño como práctica estratégica y no solamente como ejecución táctica.

Las herramientas irán y vendrán. Ya sucedió en el pasado reciente. El criterio, si lo cultivas, permanece. Y esa es la única ventaja competitiva sostenible que conozco.​​​​​​​​​​​​​​​​

Llevo dos décadas trabajando en diseño de experiencia de usuario y he escuchado el mantra de los «equipos empoderados» más veces de las que puedo contar. La promesa hay que reconocer que es seductora: dale a los equipos problemas que resolver en lugar de características que construir, y verás cómo florece la innovación. La realidad, como casi siempre, es bastante más compleja.

Hay un artículo de Laura Klein en Nielsen Norman Group, de la factoría NNG, que me leí en el tren el otro día, sobre por qué la mayoría de los equipos de producto no están realmente empoderados. El texto es francamente honesto y describe con bastante precisión los síntomas, pero hay algo que me falta: el principio de realidad. Porque el problema no es sólo que las organizaciones no tengan “equipos empoderados”, que a veces (o muchas veces) eso es así. El problema es que el empoderamiento, el rollo de los equipos empoderados, tal como se vende en la literatura de producto, es muchas veces incompatible con cómo funcionan realmente las empresas reales, las que pagan nóminas.

La tensión fundamental: certeza vs. iteración

Las empresas necesitan certezas. Lo afirmo y lo mantengo. Llevo gestionando una empresa 15 años. No es un capricho ni es una supuesta resistencia al cambio motivada por una pulsión conservadora: es supervivencia organizacional. Las nóminas, en general, no se pagan bajo un modelo de experimentación continua. Para quienes los tienen (no es mi caso), los inversores no invierten en el vacío. Los clientes grandes no firman contratos con empresas que improvisan su roadmap cada sprint.

Esta tensión que hay entre la certeza que necesita el negocio y la iteración que promete el producto no es un bug del sistema, sino más bien una característica producto de trabajar en organizaciones complejas. En castellano simple: son lentejas. Pero tenemos a una buena parte del discurso sobre equipos empoderados ignorando esto olímpicamente. Con este escenario tenemos un punto de partida retador.

Cuando en una empresa la dirección anuncia que la prioridad estratégica del año es la inteligencia artificial, no están pretendiendo ser malvados ni presentarse como el grinch de los usuarios. Simplemente están haciendo su trabajo. Quien paga la fiesta, manda. La pregunta que importa no es «¿por qué no nos dejan seguir nuestra investigación de usuarios?«, sino «¿cómo convertimos este requisito de mierda en algo que no sea una mierda?«.

El verdadero problema es la ausencia de liderazgo en diseño

Klein describe un escenario que podemos reconocer: un equipo usa modales para las confirmaciones, otro usa mensajes inline, un tercer equipo lleva al usuario a una página nueva. Los botones dicen «Enviar» en un sitio, «Guardar» en otro, «Continuar» en un tercero. El tono del microcopy oscila salvajemente entre formal y casual. Un sindiós.

Si me permitís la analogía, un revuelto parecido al que el diseño de los iconos de Tahoe nos ha traído.

El diagnóstico de Klein: los equipos no tienen el poder suficiente para coordinarse. Mi diagnóstico: no hay liderazgo en diseño.

Si esto pasa en el sitio en el que trabajas, me parece que hay altas posibilidades de que alguien no está haciendo su trabajo. Y ese alguien probablemente tiene Lead, Principal o Director en su título. Porque, amigas y amigos, coordinar la experiencia de usuario a través de equipos que trabajan de manera autónoma es precisamente el trabajo del liderazgo en diseño. Esto no es un extra, no es algo que podríamos hacer en caso de tener tiempo. Mas bien este es, literalmente, el cometido principal de esa posición.

Porque, permitidme, voy a invocar al principio de realidad: los usuarios no ven equipos; los usuarios ven un producto. Volvemos a hablar un poco como en los 2000, pero la pedagogía es también un poco esto.

El problema no es que los equipos tengan autonomía. El problema es que se les da autonomía sin la estructura de gobierno que garantice coherencia. Es empoderar a perfiles sin visión holística, con incentivos perversos y skills debatibles, y luego sorprenderse de que el resultado sea un Frankenstein. Vamos a ser serios.

La madurez profesional es trabajar con las restricciones, no contra ellas

Una de las frases más reveladoras del artículo de Klein es cuando describe a una product manager que fue contratada para ser una pensadora estratégica pero se ha convertido en una project manager enfocada enteramente en logística y coordinación.

La conclusión implícita es que esto es malo, que el sistema ha fallado, que la logística y sobre todo la coordinación no son la tarea estratégica que hay que abordar. Pero ahora yo me pregunto en público y en voz alta: ¿y si esa coordinación es el trabajo estratégico? ¿Y si en organizaciones complejas, con múltiples equipos y dependencias entre sistemas compartidos, la capacidad de coordinar efectivamente es la habilidad diferencial?

Porque aquí está el secreto que nadie quiere admitir: en la moderación está la virtud. Que sí, que tengo ya frases de abuelete, que ya lo sé. Pero es que entre un idealismo un poco ingenuo del equipo totalmente autónomo y el ordeno y mando tradicional, existe un espacio de madurez profesional donde:

1. Aceptas que no controlas el roadmap, ya que esto pasa más de lo que nos gustaría, pero a veces es lo que hay.
2. Eliges tus batallas, porque no puedes pelear cada mandato top-down.
3. Construyes reputación mediante ejecución ya que si tu equipo tiene fama de tomar buenas decisiones y de entregar trabajo de calidad, conseguirás más margen de maniobra, más credibilidad.
4. Conviertes calabazas en carrozas, o por lo menos, en algo presentable, algo que no sea vergonzoso.

Esto último es especialmente importante. Cuando, por poner un ejemplo, la dirección te manda integrar IA porque es la prioridad estratégica del año, tienes dos opciones: quejarte de que no te dejan seguir tu investigación de usuarios, o estrujarte el cerebro para hacer de ese requisito algo memorable. O, insisto, al menos algo que no sea una mierda.

Las herramientas del principio de realidad

La buena noticia en todo este panorama es que, incluso en situaciones imperfectas (perdón: se dice «principio de realidad«), puedes tener impacto estratégico. Se puede trabajar incluso en escenarios poco favorables. Pero eso requiere de mucho trabajo y del uso de herramientas específicas:

1. Visualiza el journey completo del usuario

Si sólo nos centramos en nuestro trozo de producto, estamos perdidos. El liderazgo en diseño implica entender el journey end-to-end, a través de diferentes canales y touchpoints. Sí, esto entra en conflicto con la idea de equipos individuales empoderados, cada uno con su problema y con su métrica. Pero es que esa idea, cuando hablamos de diseño de equipos y ejecución de roles, es toxicidad pura.

2. Construye relaciones antes de necesitarlas

Si partimos de la base de que la construcción de liderazgo necesita obligatoriamente una estrategia de tejer relaciones, consensos, intereses comunes y complicidades, esto no debería ser un tema de conversación. Y sin embargo, hay que seguir insistiendo: hablar con otros equipos antes de necesitar algo de ellos es parte irrenunciable de nuestro trabajo.

Entender cómo nuestro trabajo afecta sus métricas y prioridades es nuestra responsabilidad. El trabajo en equipo implica entender de dónde viene el request que recibimos y dónde va nuestro delivery.

3. Documenta todo

Pues si hay que seguir insistiendo en esto, se hace. Pero sí, tenemos que documentar. No necesitaremos explicar nuestros razonamientos o posiciones en reunión tras reunión si todo eso está escrito y es accesible en algún sitio. Y además, tendremos el canario en la mina para detectar debilidades de liderazgo: si las mismas preguntas surgen una y otra vez a pesar de estar documentadas, hay un problema de proceso o de personas.

4. Trabaja con liderazgo para definir métricas que importen

Nadie dijo que fuera fácil. Pero es que si las métricas que caen en nuestro lado no capturan lo que realmente importa, nuestro trabajo es proponer alternativas y convencer. Esto requiere credibilidad, y esa credibilidad se construye entregando resultados consistentes. La ejecución sigue siendo diferencial.

5. Elige problemas con menos dependencias

Esta es una actitud que podría denominarse conservadora, pero la compro. Si podemos elegir entre trabajar en algo que requiere coordinación con catorce equipos y algo que podemos resolver con nuestro equipo y dos dependencias, la segunda opción nos dará más autonomía real. Y luego ya iremos viendo y ya iremos construyendo. No hay que olvidar que con victorias vamos ganando credibilidad y eso siempre ayuda en la construcción de los consensos y de las complicidades que necesitamos.

Lo que nadie quiere decir en voz alta

Hay algo que es muy incómodo en el discurso sobre equipos empoderados: la suposición implícita de que las restricciones organizacionales son el enemigo. Que si pudiéramos eliminar la burocracia, las dependencias, los mandatos top-down, entonces sí que haríamos productos increíbles.

Es una fantasía. Y honestamente me parece tratar a las personas como si fueran menores de edad.

Las restricciones son el contexto en el que trabajamos. Las dependencias existen porque los sistemas son complejos y los productos están cada vez más integrados. Los mandatos estratégicos vienen de arriba porque alguien tiene que tomar decisiones de negocio que van más allá de lo que un equipo individual puede ver.

El problema no son las restricciones. El problema es la falta de liderazgo para lidiar con esas restricciones y hacerlo bien. Y específicamente, en diseño, el problema es que seguimos sin asumir que coordinar una experiencia coherente a través de equipos autónomos es nuestro trabajo principal.

No es responsabilidad del PM que se ha convertido en coordinador. Es responsabilidad del diseñador senior que no ejerce liderazgo. No es responsabilidad de la organización. Es responsabilidad del Head of Design que no ha establecido sistemas de gobierno del diseño.

Una invitación a la honestidad brutal

Después de veinte años en esto, he llegado a una conclusión: el discurso sobre empoderamiento de equipos es a veces una forma de evitar conversaciones difíciles sobre liderazgo, gobernanza y madurez profesional.

Es más fácil culpar a «la organización» que admitir que quizá no tenemos las habilidades necesarias para coordinar de manera profesional a través de la complejidad. Es más cómodo quejarse de que «no nos dejan hacer nuestro trabajo» que reconocer que nuestro trabajo ha evolucionado y ahora incluye coordinación política, construcción de consenso y navegación de restricciones.

Las empresas que funcionan bien no son las que han eliminado las restricciones. Son las que han desarrollado músculo organizacional para trabajar productivamente dentro de esas restricciones. Y en diseño, ese músculo se llama liderazgo.

Así que la próxima vez que escuches a alguien lamentarse de que su equipo no está realmente empoderado, pregúntale: ¿has documentado tu razonamiento? ¿Has construido relaciones con los equipos de los que dependes? ¿Has propuesto métricas alternativas? ¿Has entregado resultados consistentes que te den credibilidad? ¿Estás ejerciendo liderazgo en diseño para garantizar coherencia?

Porque si la respuesta es no, el problema no es el empoderamiento. El problema eres tú.

Para quien le interese, aquí dejo el artículo de Klein, subrayado y comentado.

A partir de hoy, todos los artículos de este blog van a contar con una ilustración de Hugo Tobio. Una ilustración de la que, por supuesto, él posee los derechos porque son suyas. Unas ilustraciones que cede de manera desinteresada y que me hacen sentir honrado y agradecido. Unas ilustraciones que quieren contribuir a la difusión de los contenidos de este blog personal.

Conocí a Hugo hace años gracias a su trabajo en las ilustraciones que hace todas las semanas para La Bonilista, la famosa newsletter de David Bonilla. De todos modos Hugo es diseñador. De los buenos. Conectamos muy bien porque ambos somos del sector, y aunque a veces tenemos visiones distintas sobre alguna tecnología, el componente personal es básico y fundamental.

Este blog está deliberadamente alejado de mi empresa. No quiero tirar de imágenes de catálogo ni similares para acompañar con imagen mis movidas. He buscado sets por ahí, pero es todo descartable, para ser diplomático. Tampoco quiero usar generadores de IA para esto. Quería ilustraciones de alguien, y ese alguien es Hugo.

Cuando le planteé el tema, su generosidad me pilló desprevenido. Me propuso crear todas las ilustraciones que necesitara. Su condición era simple: necesita la temática y un poco de qué va el artículo. Así que antes de empezar hemos hecho algo así como definir un estilo.

Su propuesta de enfoque ha sido clara y profesional:

• No usar figuras antropomórficas
• Blanco y negro con un color como acento
• Usar elementos alegóricos: una taza con dos asas, una maleta de viaje con sellos
• Lineal y colores planos texturizados sobre fondo blanco

Me ha dado un rubor considerable aceptar su oferta, las cosas como son. Hugo es ante todo un fabuloso profesional, pero sobre todo una buena persona. Un tipo decente. Un tipo honrado. Eso es lo que más me gusta y lo que más admiro de él. En la valoración profesional vinculada con las ilustraciones, lo mejor será que opine la audiencia, si quiere.

A partir de hoy, cuando veáis una ilustración en este blog, sabréis que viene de Hugo Tobio, el dibujolari más famoso de Getxo y resto del mundo. Y sabréis que detrás hay una colaboración que me hace sentir afortunado, porque se basa en algo que cada vez escasea más: la generosidad profesional sin segundas.

Gracias, Hugo.​​​​​​​​​​​​​​​​

La muerte en directo de Sergio, un streamer catalán que murió en directo por sobredosis mientras hacía streaming a un grupo de suscriptores de pago, ha puesto sobre la mesa una realidad muy chunga que llevamos ya un tiempo evitando nombrar. Pepa Bueno, en el telediario de TVE, ha acuñado una expresión que resume perfectamente el fenómeno: mendicidad digital.

No es un caso aislado, por desgracia. En España hemos conocido el ejemplo de Simón Pérez, cuya espiral autodestructiva ha quedado documentada en los memes donde aparecía claramente bajo los efectos de sustancias, hablando de hipotecas junto a su pareja. Lo que comenzó como unas risas ha derivado en algo mucho más feo: la monetización del deterioro personal de otro ser humano.

Desde que en 2020 trabajamos en el Estudio en la revisión de experiencia de usuario para una plataforma vinculada con el negocio del streaming, hay una pregunta me persigue: ¿qué responsabilidad tenemos quienes diseñamos estas plataformas en proteger a las personas que las usan? Y no me refiero solo a proteger al usuario final que consume contenido, sino también y especialmente a quienes generan ese contenido y pueden estar poniéndose en riesgo.

El problema no es sólo ético, es de diseño

Hay una tendencia mas o menos establecida a trasladar por defecto toda la responsabilidad al ámbito legal (fuerzas de seguridad o legislación) o moral (la ética individual de quien paga por ver esto). Pero lo cierto es que esa perspectiva no quiere mirar de frente a una verdad clara: las plataformas digitales no son espacios neutrales. Están diseñadas. Y cada decisión de diseño, cada affordance, cada flujo de interacción, cada sistema de notificaciones o cada mecánica de monetización, configura comportamientos de los usuarios y facilita ciertas acciones a la vez que dificulta otras. Esto es así.

Creo que no hace falta explicar que cuando una plataforma permite que alguien transmita en directo durante horas sin pausas, consume sustancias frente a la cámara, y recibe incentivos económicos directos por mantener esa transmisión activa, no estamos sólo ante un problema de libertad individual. Estamos ante un problema de diseño que facilita y monetiza conductas de riesgo.

Vamos a hacer un pequeño repaso de marcos de trabajo en diseño ético, que es algo que no es nuevo, pero tiene todo el sentido del mundo en este contexto. El Ethical OS Toolkit, desarrollado por el Institute for the Future, proponía unas zonas de riesgo (enlace a Web Archive) que toda plataforma digital debería considerar. Entre ellas: adicción y economía dopamínica, vigilancia del estado del bienestar emocional, y responsabilidad algorítmica.

El Center for Humane Technology lleva años documentando cómo ciertos patrones de diseño explotan vulnerabilidades psicológicas humanas.

En Design Ethically tenemos a nuestra disposición un framework para trabajar los procesos que llevan a tomar decisiones de diseño con garantías éticas.

Por supuesto, no faltan recursos accesibles, gratuitos, sencillos de entender, pedagógicos, accionables y útiles como por ejemplo Ethical Design: What Is It and Key Principles Of Ethical Design.

Y aquí estamos, seguimos construyendo plataformas como si estas consideraciones fueran opcionales.

La anatomía del problema: patrones de diseño que facilitan el daño

Vamos a hacer un repaso de qué elementos de diseño están presentes en estos casos de mendicidad digital:

Sistemas de monetización sin protección

Las plataformas implementan sistemas de donaciones, suscripciones y pagos en tiempo real que incentivan la prolongación del contenido sin considerar el estado del creador. Cuanto más tiempo en directo, más ingresos potenciales. No parecen existir mecanismos suficientes que detecten patrones de comportamiento que puedan ser catalogados como preocupantes o que sugieran pausas.

Ausencia de detección de riesgo en tiempo real

Las plataformas más avanzadas implementan sistemas de moderación de contenido para detectar violencia explícita o contenido sexual. Pero ¿dónde están los sistemas que detecten signos de intoxicación, fatiga extrema o deterioro del estado de un creador? La tecnología existe. La voluntad de implementarla tiene que ser reforzada.

Gamificación sin límites

Los sistemas de logros, badges, contadores en tiempo real de espectadores y donaciones funcionan como refuerzos intermitentes que mantienen al creador enganchado a seguir produciendo contenido, incluso cuando su estado físico o mental debería ser una señal de alarma para detenerse. Hay mecanismos que monitorizan algunas variables vinculadas al tiempo prolongado de emisiones pero no parece que las funcionalidades se enfoquen en la protección y cuidado de los creadores de contenido.

Opacidad en los algoritmos de recomendación

Los algoritmos que determinan qué contenido se promueve no son neutrales. Si un contenido controvertido o extremo genera más engagement, el algoritmo lo premiará con mayor visibilidad, independientemente de si ese contenido es dañino para quien lo genera o consume.

Falta de controles parentales justificados

Existe un tabú en torno a implementar controles que puedan interpretarse como paternalistas. Pero hay contextos donde el paternalismo está justificado: cuando existe un riesgo evidente para la salud o la vida de una persona. Las plataformas médicas implementan alertas cuando detectan patrones preocupantes. La pregunta abierta y seguramente no exenta de controversia es ¿por qué las plataformas de streaming no pueden hacer lo mismo?

Diseño responsable en plataformas de contenido en directo

No se trata de censurar ni de eliminar libertades. Se trata de diseñar sistemas que protejan a las personas de sí mismas cuando están en situación de vulnerabilidad, de la misma forma que diseñamos coches con airbags o edificios con salidas de emergencia.

Propuestas desde el diseño de producto

Detección de patrones de riesgo mediante IA

Implementar sistemas de análisis de comportamiento que detecten:

• Transmisiones de duración más prolongada de lo habitual (más de X horas sin pausas)
• Cambios en patrones de habla o movimiento que puedan indicar intoxicación
• Comentarios de la audiencia que expresen preocupación por el estado del streamer
• Incrementos repentinos en donaciones correlacionados con comportamientos de riesgo

Cuando se detecten estos patrones, el sistema debería activar protocolos de protección, no de penalización.

Pausas obligatorias y límites de duración

De la misma forma que las aplicaciones de bienestar digital implementan límites de uso, las plataformas de streaming podrían:

• Requerir pausas cada X horas de transmisión continua
• Establecer límites diarios de horas en directo configurables (con la opción de que el streamer los desactive, pero activados por defecto)
• Implementar algo así como un “modo seguro” que se active automáticamente ante señales de riesgo

Separación temporal entre contenido y monetización

Esta es una medida radical pero eficaz: desacoplar la monetización en tiempo real del contenido en directo. De esa forma las donaciones y pagos podrían procesarse con un diferimiento de, por ejemplo, 24-48 horas, lo que eliminaría el incentivo inmediato de prolongar transmisiones potencialmente peligrosas para recibir más ingresos.

Canales de intervención para la comunidad

Habilitar mecanismos para que la propia comunidad pueda reportar situaciones de riesgo con consecuencias inmediatas:

• Botón de “preocupación por el creador” (distinto del reporte de contenido inapropiado)
• Sistema de escalado rápido cuando múltiples usuarios expresan preocupación
• Protocolo de contacto con servicios de emergencia si la situación lo requiere

Transparencia algorítmica y control de amplificación

Los algoritmos de recomendación deberían incluir:

• Penalización de contenido que muestre comportamientos de riesgo evidente
• Indicadores bien visibles para usuarios de que están viendo contenido que pueda resultar perturbador

Formación obligatoria para streamers

Yo sé que puede sonar un tanto extraño, pero el tema no es menor. Antes de habilitar funciones de monetización, requerir que los streamers completen módulos formativos sobre:

• Riesgos de las transmisiones prolongadas
• Señales de alerta de problemas de salud mental
• Recursos disponibles si necesitan ayuda
• Responsabilidad hacia su audiencia

El papel de los diseñadores y gestores de producto

Porque al final, aquí vamos a acabare hablando de lo que nos impacta como profesionales del diseño. Implementar estas medidas requiere sí o sí de voluntad, pero también de valentía profesional por parte de quienes contribuimos al diseño y desarrollo de estas plataformas.

Elementos que debemos incorporar en nuestros procesos, o por lo menos considerarelo:

1. Risk assessment en la fase de diseño: utilizar frameworks para anticipar cómo nuestras decisiones de diseño pueden facilitar daños.
2. Considerar métricas que vayan más allá del engagement: medir no sólo cuánto tiempo pasan los usuarios en la plataforma, sino también indicadores de bienestar, reportes de preocupación, y contenido que genera angustia.
3. De verdad, necesitamos equipos multidisciplinares: incluir en los equipos de producto a profesionales de psicología, trabajo social y ética aplicada, no sólo como consultores externos sino como miembros permanentes (cuando aplique, claro).
4. Principios de diseño explícitos: documentar y hacer públicos los principios éticos que guían el diseño de la plataforma, y rendir cuentas cuando no se cumplen.
5. Protocolos de emergencia: tener claridad sobre qué hacer cuando se detecta una situación de riesgo: quién toma decisiones, cómo se contacta con el creador, cuándo se involucra a servicios de emergencia.

Checklist de diseño responsable para plataformas de contenido en vivo

Como aquí estamos para aprender y para facilitar que otros lo hagan, vamos con una lista accionable que cualquier equipo de producto puede implementar, de manera gradual o de manera completa, dependiendo de su contexto:

Antes de lanzar

• Hacer un ejercicio de previsión de riesgos usando el Ethical OS Toolkit
• Definir y documentar principios éticos explícitos de la plataforma
• Establecer límites técnicos por defecto (duración de streams, pausas obligatorias, etc.)
• Diseñar sistema de detección de patrones de riesgo
• Crear protocolo de intervención ante situaciones de emergencia
• Configurar canales de reporte diferenciados (contenido inapropiado vs. preocupación por el/la streamer)
• Implementar formación obligatoria para streamers antes de habilitar la monetización

Durante la operación

• Monitorizar las métricas de bienestar además de las de engagement
• Hacer auditorías periódicas de contenido amplificado por algoritmos
• Revisar reportes de preocupación y actuar sobre ellos
• Evaluar si las pausas obligatorias están funcionando
• Analizar la correlación entre monetización y comportamientos de riesgo
• Mantener abierto un canal de comunicación con organizaciones de salud mental

Evaluación continua

• Medir el impacto de las medidas implementadas (no sólo en las métricas de negocio)
• Recoger feedback de streamers sobre cómo las medidas de protección afectan su trabajo
• Documentar los casos de éxito de estos protocolos
• Mantener conversaciones activas con la comunidad sobre estos temas

Gobernanza

• Incluir profesionales o roles de ética y bienestar en los equipos de producto
• Establecer un comité/roles de revisión ética con poder de veto sobre las funcionalidades de la plataforma
• Definir KPIs de responsabilidad social además de los KPIs de negocio
• Habilitar presupuesto específico para iniciativas de diseño responsable (aquí es donde se ve realmente el compromiso con el tema)
• Formar a todo el equipo en principios de diseño ético y humano

El diseño como acto político

Yo sé que me ha quedado un post largo y por momentos puede hasta resultar como que estoy regañando a la audiencia. Pero es que diseñar, en un sentido amplio, es tomar decisiones sobre cómo será el mundo. Cada interfaz, cada pantalla, cada flujo de interacción, cada sistema de incentivos configura comportamientos y, en última instancia, vidas. A los hechos mencionados al principio me remito. Es un tema muy serio.

La mendicidad digital no es un problema tecnológico que haya que resolver con más tecnología. Es un problema ético que requiere, entre otras cosas, que quienes diseñamos y construimos plataformas asumamos la responsabilidad de anticipar y mitigar los daños que nuestro trabajo puede causar.

Sergio no debería haber muerto en directo. Simón Pérez no debería haber podido monetizar su deterioro personal ante miles de espectadores. Y ambos casos deberían avergonzarnos lo suficiente como para que dejemos de construir plataformas que faciliten o promuevan estas situaciones.

Tenemos las herramientas. Tenemos el conocimiento. Lo que necesitamos es la voluntad colectiva de usarlos. No para censurar, ni para limitar libertades, sino para diseñar sistemas que protejan la dignidad y la vida de las personas que los habitan. Yo sé que no sólo depende de nosotros, por supuesto que no. Pero un esfuerzo como este en un post largo, aburrido por momentos, un tanto ejemplarizante y abierto, bien merece que nos haga calibrar la importancia de estas cuestiones.

El diseño puede ser una forma de cuidado, atención, empatía y protección.

Hace tiempo Freddy Vega me dijo algo que se me quedó grabado: lo importante es lo que sucede a partir de ahora. Lo de atrás importa poco, sólo debemos quedarnos con lo aprendido para llevar la mejor caja de herramientas de aquí en adelante.

Ayer vi compartido por bastantes personas un un gráfico de Tim Urban que visualiza esta idea de forma brutal. Muestra cómo desde el momento en que nacemos hasta hoy, hemos recorrido un único camino entre miles de opciones que se fueron cerrando. Pero lo realmente potente está en el lado derecho del gráfico: desde hoy hacia adelante, tenemos ante nosotros infinitas posibilidades abiertas.

Esta imagen es muy potente. Me ha hecho pensar sobre lo que significa liderar equipos de diseño porque hay una paradoja incómoda en ella: es tremendamente liberador y tremendamente exigente al mismo tiempo. Y como líderes, necesitamos entender ambas caras para ayudar a nuestros equipos a crecer.

La liberación de los caminos cerrados

Una de las conversaciones complicadas que tenemos que afrontar como líderes es cuando alguien del equipo viene lastrado por decisiones del pasado. “Debería haber aprendido desarrollo front”, “tendría que haberme especializado en research antes”, “perdí años en proyectos que no me aportaron nada”. Siendo sinceros, yo mismo pienso más de una vez y más de dos todas las semanas en cosas así.

El gráfico de Tim Urban deja claro algo que a veces nos cuesta asumir: esos caminos cerrados ya no importan. No es que no hayan sido relevantes en su momento, es que obsesionarse con ellos es mirar hacia el lado equivocado del diagrama. Y es una forma bastante estúpida de perder el tiempo.

Como líderes, una de las cosas más valiosas que podemos hacer es ayudar a nuestro equipo a soltar esa carga. No se trata de negar el pasado o de fingir que todas las decisiones pasadas fueron las buenas, sino de reconocer lo aprendido y fijar la mirada hacia delante. Porque mientras alguien está lamentando no haber tomado aquel curso de service design hace cinco años, hay diez caminos abiertos esperando que elija uno.

He visto a diseñadores brillantes bloqueados por decisiones que tomaron (o que no tomaron) hace una década. Y lo curioso es que el bloqueo no viene del pasado en sí, sino de seguir mirándolo como si pudiera cambiarse. No puede. Los caminos negros están cerrados. Punto.

Nuestra responsabilidad como líderes es hacer visible esta realidad. No para minimizar frustraciones legítimas, sino para canalizar la energía hacia donde realmente puede generar movimiento: hacia adelante. Así de simple.

La responsabilidad de los caminos abiertos

Aquí viene la parte incómoda, tanto para nosotros como para nuestros equipos: si hay infinitas posibilidades abiertas desde hoy, también hay la responsabilidad de elegir. Y elegir es renunciar. Y es incómoda porque a veces es mucho más fácil no tomar esas decisiones. Pero hay que hacerlo.

Cada vez que alguien de tu equipo decide profundizar en accesibilidad, está dejando de profundizar en otra cosa. Cuando una persona se especializa en research cualitativo, está posponiendo (quizá para siempre) convertirse en experta en analytics. Y está bien. Es necesario. Pero requiere una decisión activa.

Como líderes no podemos ni debemos elegir por nuestro equipo. Pero sí podemos (y debemos) crear el contexto para que tomen decisiones conscientes. No es cuestión de presionar para que se especialicen o de forzar planes de carrera rígidos. Se trata de hacer visibles las opciones, de hablar abiertamente sobre las implicaciones de cada elección, y de acompañar sin paternalismos. No olvidemos que estamos asumiendo un cierto nivel de madurez en el equipo, necesario para poder llevar adelante este tipo de iniciativas.

El gráfico de Tim Urban nos recuerda también algo que a veces olvidamos: tener opciones abiertas no significa que todas se puedan recorrer a la vez. El tiempo y la energía son finitos para todos sin excepción. Parte de nuestro trabajo como líderes es ayudar a que las personas de nuestro equipo entiendan esto sin sentirse limitadas, sino empoderadas para elegir con criterio.

Crear contexto, no caminos

Si lideramos un equipo de diseño, el gráfico nos plantea una pregunta directa: ¿estamos ayudando a nuestra gente a ver los caminos verdes o estamos reforzando su obsesión con los caminos ya cerrados?

Las canas que pueblan mi cabeza me permiten decir que he aprendido algunas cosas sobre cómo abordar esto que pueden ser útiles:

Compartir información, no instrucciones. Las personas necesitan contexto para tomar decisiones, no que les digamos qué decidir. Si hay una oportunidad de liderar un proyecto de design systems, tenemos que explicar qué implica, qué se aprende, qué se sacrifica. Luego, que decidan ellas.

Normalizar el cambio de dirección. Alguien que ha estado tres años enfocado en UX research puede perfectamente pivotar hacia product design. Los caminos verdes (abiertos) siguen ahí. No deberíamos convertir las decisiones pasadas en identidades inamovibles. Como líderes, tenemos que dejar claro que cambiar de rumbo no es fracasar, es elegir.

Reconocer el coste de oportunidad. Cada proyecto, cada aprendizaje, cada especialización tiene un coste: el tiempo que no se dedica a otra cosa. Hablarlo abiertamente con el equipo ayuda a que las decisiones sean más conscientes y menos frustrantes después. No se trata de desanimar, sino de ayudar a decidir con los ojos abiertos.

Celebrar los aprendizajes de los caminos cerrados. Que un camino esté cerrado no significa necesariamente que fue un error recorrerlo. Puede que lo aprendido en aquel proyecto fallido sea exactamente lo que alguien necesita para el siguiente. Pero eso solamente se ve mirando hacia adelante, no hacia atrás. Como líderes, debemos ayudar a conectar esos puntos.

Generar espacios de conversación honestos. Las mejores decisiones sobre caminos profesionales no se toman en las evaluaciones anuales de desempeño. Se cocinan en conversaciones informales, en momentos de confianza, cuando hay espacio para la duda y la exploración sin presión. Crear esos espacios es nuestra responsabilidad, que además es ineludible.

No forzar la urgencia, pero nunca permitir la parálisis. Hay personas que necesitan tiempo para decidir y otras que se quedan eternamente en modo exploración. Como líderes, nuestro trabajo es calibrar cuándo dar espacio y cuándo invitar a la acción. No hay una fórmula que yo pueda compartir ahora, pero sí hay señales: cuando alguien lleva meses diciendo que quiere cambiar de enfoque pero no da ningún paso, seguramente necesita un empujón. Cuando alguien acaba de descubrir una nueva área y quiere zambullirse de cabeza, quizá necesita que le recuerdes que los caminos verdes seguirán ahí mañana. No olvidemos aquel viejo eslogan de un comercial de neumáticos: la potencia sin control no sirve de nada.

Lo que sucede a partir de ahora

Vuelvo a la frase de Freddy Vega porque me parece que captura perfectamente el equilibrio del gráfico de Tim Urban: lo importante es lo que sucede a partir de ahora, llevando contigo lo aprendido.

Como líderes de diseño, nuestra responsabilidad no es elegir los caminos de nuestro equipo. Es crear el entorno donde esa elección sea posible, informada y apoyada. No paternalista, no directiva, pero sí consciente.

Esto significa varias cosas en la práctica:

Primero, tenemos que ser honestos sobre las opciones reales que existen. No todos los caminos verdes son igual de accesibles para todas las personas en todos los momentos. El contexto importa: la estructura del equipo, las necesidades del negocio, las habilidades actuales de cada persona. Pero tampoco podemos usar esto como excusa para cerrar puertas demasiado deprisa.

Segundo, debemos estar dispuestos a invertir en el desarrollo de nuestro equipo incluso cuando eso signifique algo que puede gustarnos: que nos dejen o cambien de rol. Los caminos verdes no tienen por qué quedarse dentro de nuestra organización. Si creemos en el desarrollo profesional, tenemos que aceptar que a veces la mejor decisión para alguien es explorar un camino que nosotros no podemos ofrecerle. Este es un reto guapo que conviene que tengamos presente, porque las cosas a veces son así.

Tercero, necesitamos revisar este comportamiento nosotros mismos. Tenemos que ser honestos con nosotros mismos y preguntarnos si estamos tomando decisiones activas sobre nuestro propio desarrollo o estamos en piloto automático. Tenemos que dar respuesta honesta a si revisamos nuestros propios caminos verdes o seguimos lamentando los ya cerrados. La coherencia importa porque entre otras cosas somos un espejo, en el cual el equipo se fija.

Los caminos negros ya están cerrados. Los verdes están esperando. Como líderes, nuestra pregunta no es qué debió haber elegido cada persona antes. Nuestra pregunta es cómo creamos las condiciones para que puedan elegir bien ahora.

Y “bien” no significa “perfectamente”. Significa conscientemente, con información suficiente, con apoyo real, y con la libertad de cambiar de rumbo cuando sea necesario.

Porque al final, liderar equipos de diseño no es dictar caminos. Es ayudar a que las personas vean los suyos con claridad y tengan la valentía de recorrerlos.​​​​​​​​​​​​​​​​

Hace unos días, cuando supe que alguien iba a entrevistar a Nad Chishtie, responsable de diseño de Lovable, le sugerí que aprovechara para preguntarle sobre diversidad en el equipo. Es algo que me parece especialmente valorable en el vector de la edad. Es además un tema que me interesa particularmente porque en nuestra industria existe un sesgo importante que pocas veces se aborda con honestidad.

Una parte de la entrevista se ha publicado en Reddit, y aunque se pueden leer reflexiones valiosas sobre producto y gestión de equipos, mi pregunta no ha tenido respuesta. O no la incluyeron en el set list, o entendieron que no relevante incluirla. En cualquier caso, esa ausencia también dice algo.

Liderar diseño es tomar decisiones

Lo primero que destaca Nad es que buscan perfiles generalistas capaces de llevar un proyecto de principio a fin. Me ha flipado saber que en Lovable sólo hay un Product Manager, lo que significa que los diseñadores asumen una parte sustancial de la estrategia de producto: hablan con usuarios, acceden a los datos, deciden qué hay que construir y qué es susceptible de eliminar.

Hasta aquí todo bien, nada que objetar. Es un modelo que conozco bien y que en el contexto adecuado funciona. El problema desde mi punto de vista viene cuando leemos entre líneas.

Hay una cita del handbook de Lovable, según dice el autor, que me resulta fascinante:

You know you’re doing your job correctly when someone else tells you you’re stepping on their toes.

Es decir, sabes que estás haciendo bien tu trabajo cuando alguien te dice que le estás pisando. De momento suena a red flag de manual. Pero sigamos.

Entiendo la intención: fomentar la proactividad, que los diseñadores no se queden en su parcela. Pero hay que tener mucho cuidado con este tipo de frases porque si las elevamos a principio organizativo, pueden derivar en culturas donde la fricción permanente se normaliza y donde quien no pisa queda relegado. Me pregunto cuánto de esto es sostenible a largo plazo, especialmente para perfiles que no encajan en el arquetipo del profesional joven, disponible y sin cargas familiares.

Estrategia de gestión de talento

Aquí Nad hace una afirmación que comparto a medias:

I don’t really care so much about process… I’m going to trust that you used some process, and so we’ll find out more about that later when we talk.

Tiene razón en que muchos portfolios pecan de sobrevender el proceso, y a veces se siente que cada proyecto en un case study interminable que dice mucho y demuestra poco. Pero hay un matiz importante: el proceso no es sólo lo que haces, sino cómo piensas. Y eso, en una conversación de treinta minutos, se me antoja un poco complicado de evaluar.

Lo que sí me gusta, y mucho, es su énfasis en los side projects:

I put the exact same amount of weight on side projects.

No todo el mundo tiene la suerte de trabajar en productos con design systems pulidos y equipos bien dotados de presupuesto, tiempo y perfiles especializados. Un proyecto personal bien ejecutado puede demostrar más criterio y capacidad de decisión que tres años en una consultora donde te limitaban a ejecutar wireframes, por ejemplo.

Nad valora especialmente la calidad de las preguntas que hacen los candidatos en las entrevistas. En eso también estamos en la misma página porque lo considero un indicador de criterio muy importante.

Having a really strong point of view about the products that we’re building is the main thing, I’d say.

Aquí no puedo sino también estar muy de acuerdo. Llegar a una entrevista habiendo usado el producto, con opiniones formadas sobre el mercado y los competidores, es lo mínimo que debería esperarse de alguien que aspira a un puesto de diseño de producto. Lo contrario es como presentarse a un examen sin haber leído el temario. No solamente se queda muy mal si no se va con eso preparado, sino que además se pierden muchas opciones, por no decir casi todas, de continuar dentro de un proceso.

Falta de diversidad como debilidad estratégica

Y llegamos al punto que más me interesa. En toda la entrevista no hay una sola mención a la diversidad del equipo. La foto que acompaña al post muestra un grupo bastante homogéneo: jóvenes, aparentemente del mismo rango de edad, con una estética que ya conocemos.

No estoy diciendo que Lovable tenga un problema de diversidad. No tengo información suficiente para afirmarlo. Lo que sí digo es que cuando se habla de qué tipo de perfil profesional buscan, cuando se enfatiza la autonomía extrema, la disponibilidad para pisar a otros y la evaluación basada en primeras impresiones, se está describiendo un perfil muy concreto.

Nad pays close attention to his gut reaction in the first few seconds

Y ese perfil, queridas amigas y queridos amigos, por lo general, no incluye a profesionales de más de cuarenta años, personas con responsabilidades familiares, o gente que simplemente tiene una forma de trabajar más pausada y reflexiva.

El modelo de Lovable puede funcionar perfectamente para una startup en hipercrecimiento que necesita moverse rápido y romper cosas. Pero no es el único modelo válido, y desde luego no es el más sostenible a largo plazo.

Después de veinte años en esto he aprendido que los equipos más resilientes son los que tienen la voluntad política y el accionable de mezclar perfiles diversos: gente joven con energía y ganas de comerse el mundo, y profesionales con experiencia que ya han visto varias burbujas estallar. Unos aportan velocidad, otros aportan criterio. Y cuando solo tienes velocidad, tarde o temprano te la pegas.

Ayer fui con mi amigo Lizano a la presentación del último libro de Txarly Brown en Zaragoza y, si os soy sincero, esperaba una charla sobre diseño gráfico y música jamaicana. Lo que nos encontramos fue una clase magistral de supervivencia creativa, honestidad brutal y una reivindicación del fracaso como estilo de vida.

Txarly Brown no es un tipo normal y tampoco es un desconocido para nosotros, ni mucho menos.. Es una enciclopedia con patas de la subcultura catalana y española de los últimos 35 años, diseñador de portadas icónicas (especialmente en la escena ska y rumba), coleccionista compulsivo y, según él mismo, un dinosaurio tecnológico. Su libro, Grandes fracasos, no es una biografía al uso, y su presentación tampoco lo fue.

Aquí os dejo lo que, para mí, define a este personaje inclasificable tras escucharle hablar sin filtros.

Lo primero que me chocó fue algo así como la motivación del libro. Y he de reconocer que eso me enganchó (el ambiente al principio de la presentación era más frío que otra cosa, la verdad). No hay ego de artista, hay paternidad. Txarly contó que cuando su hijo cumplió 20 años y abandonó el nido, se encontró con un vacío existencial. Su hijo había crecido en un Ford Fiesta del 85 escuchando cintas de casete de los Amaya y Kiko Veneno como si fueran el MCU de Marvel, pero Txarly compartió que de alguna manera sintió la necesidad de cerrar etapas.

El libro es, básicamente, una carta larga (escrita en formato de mensajes de WhatsApp, sin palabras raras ni pretensiones literarias) para explicarle a su hijo quién demonios ha sido su padre antes de que se muera y solo quede una entrada fría en Google. Fue una historieta muy bien contada, con una alta carga emocional disfrazada de gamberrismo y palabrotas.

El título, Grandes fracasos, no es falsa modestia. Es una filosofía. Txarly nos explicó que el éxito es peligroso y estresante. Recordó anécdotas de clientes suyos que pasaron de llenar plazas de toros y petarlo, a tocar en garitos para 50 personas, gastándose la pasta en psicólogos para gestionar semejante transición.

Contó que prefiere definirse como una colección de micro-fracasos que, sumados, le han permitido vivir de lo que le gusta durante tres décadas y media. No tiene Discos de Oro ni Grammys, pero ha hecho 500 portadas y sigue en la brecha. «Soy un fracasado que ha podido vivir toda la vida de esto». Y qué queréis que os diga, me pareció la definición más sana de éxito que he oído en años. Honesta, sin filtros (literalmente, porque el diccionario de Txarly, por momentos, es hilarante) y brutal.

Esta parte, como digo, fue hilarante. En el contexto de un mundo obsesionado con la última actualización de Adobe y la IA, Txarly se plantó allí a confesar que trabaja con Freehand 8.0 (millenials y zetas: es un programa ya extinto) en un ordenador de 2008 que no puede conectarse a internet. He de reconocer que en ese momento la conversación corrió un serio riesgo de decantarse por lo que yo llamo mal envejecer, pero, afortunadamente, no fue así.

Es por eso que esta esta es la parte que más me fascinó. Conto que tiene ocho ordenadores antiguos guardados en armarios por si uno se le quema o se le rompe. Se niega a pagar suscripciones de software y se ríe de la obsolescencia programada. Es un artesano digital que diseña tipografías tomando como modelos rótulos viejos que ve por la calle porque le aburre la perfección de las nuevas helvéticas (ahí nos reímos todos mucho). Su método es el caos ordenado: lo guarda todo, fecha todo (aprendió a poner el año en los carteles a base de broncas) y su archivo es su memoria. Detrás de una interfaz llena de referencias de los 90s, palabrotas que adornan todo el discurso y anécdotas desternillantes de las noches barcelonesas y donostiarras, se esconde una pequeña Wikipedia de la subcultura ibérica que bien haríamos en reconocer.

Txarly contó algo propio de los genios o de los inconscientes: no tiene portfolio. Nunca lo ha tenido. La gente le contrata porque sabe quién es o porque él se enamora del proyecto. Si un grupo le gusta, les hace la portada, a veces cobrando en jamones o cenas.

Nos contó una anécdota tremenda de los 90s: por un despecho amoroso (una chica le rechazó por su compañero de piso y socio), robó un fax con la contratación del grupo The Breeders y se lo pasó a la competencia. Eso le costó ser desterrado de su casa y perder amigos en Barcelona, lo que le llevó a refugiarse los fines de semana en Donosti, convirtiéndose en un puente cultural entre ambas ciudades. «La lié, pero no hago nada conscientemente, soy un puto inconsciente». Es un genio.

Escucharle hablar de sus ídolos musicales es una mezcla de fanatismo y realidad cruda. Contó cómo trajo a Laurel Aitken (padrino del Ska) a España cuando nadie sabía quién era, recogiéndolo en un Ford Fiesta destartalado, o cómo acompañaba a Dr. Calypso cuando casi no sabían tocar. También habló de la decepción de conocer a leyendas como Prince Buster y descubrir que eran unos cretinos, aunque su música fuera genial.

Salimos de la presentación con la sensación de haber conocido a un superviviente. Eso sí, José Luis y yo antes de salir fuimos a saludarle porque Txarly colaboró durante la última etapa de la revista Ciclo, que a finales de los 90 ocupaba nuestro primer intento emprendedor. Txarly Brown diseña pósters para Metallica y Lady Gaga (trabajos alimenticios que pagan facturas) para luego poder dedicarse a diseñar discos para grupos jamaicanos que le pagan 100 euros.

Su libro promete ser eso: no una lección de diseño, sino una lección de vida de alguien que ha decidido que, si va a fracasar, lo hará a su manera, con su propia música y, por supuesto, usando Freehand 8.0.

Si tenéis la oportunidad de leer Grandes Fracasos, hacedlo. Aunque sólo sea para entender que, a veces, el plan B es mucho más divertido.