Algunos están argumentando en Twitter, LinkedIn y otras redes sociales que tu proceso de diseño cabe en un archivo de texto. Que con eso, una inteligencia artificial puede trabajar con tu criterio y, en teoría, sin ti.
La idea se llama design.md. No voy a decir que es inútil, pero sí diré algo un poco más incómodo: solo funciona si el diseño es, en esencia, seguir reglas. Y ahí está el problema.
¡Vamos allá!
¿Qué es design.md?
La analogía viene del desarrollo. Los programadores llevan años manteniendo archivos como README.md o CLAUDE.md. Son documentos que capturan cómo funciona un sistema, qué decisiones se tomaron y por qué, qué convenciones seguir, etc.
Con la llegada de los agentes de la inteligencia artificial, estos archivos han pasado a ser todavía más importantes: son la forma de darle contexto a una herramienta que, sin él, genera resultados más incorrectos y desviados de las guías que debería seguir.
La propuesta para diseño es la misma: un archivo en texto plano donde documentas tus principios, tus sistema de diseño (tipografía, espaciado, color, componentes) e, idealmente, el razonamiento detrás de cada decisión. De esta manera, las reglas de tu trabajo son accesibles para cualquier herramienta de IA que vayas a usar.
Styles (Refero) es uno de los recursos que se viralizó más rápido: contiene los design.md de Apple, Stripe, y cualquier otro producto digital que pueda venirte a la cabeza.
Para que te hagas una idea, un design.md tiene esa pinta: recopila los tokens en un formato que cualquier herramienta de IA puede consumir fácilmente.
En designmd.ai encontrarás más, e incluso Google publicó uno para usar con Google Stitch.
Diseñar no es solo usar tokens
El design.md funciona como lo que promete ser, una guía para herramientas de inteligencia artificial, si aceptamos una premisa implícita: que el diseño es, en esencia, un conjunto de reglas que pueden extraerse, documentarse y ejecutarse.
Elige esta tipografía en estos contextos, usa este espaciado, o aplica este componente cuando el usuario necesite hacer X. Una vez documentado, en teoría ejecutable sin ti.
En teoría.
Porque eso solo es cierto si diseñar es, únicamente, producir interfaces.
Es una reducción que llevamos tiempo normalizando sin querer. La industria ha premiado durante años la velocidad de entrega, la fidelidad visual, y los sistemas de componentes bien construidos. Todo eso tiene valor, no me malinterpretes, pero si es lo único que defines como «diseño», estás construyendo el argumento para tu propia sustitución… y no hace falta esperar al design.md o a lo que venga después para que eso pase.
Lo que la IA ya hace
Seamos honestos: hay una parte del trabajo de diseño que la IA ejecuta, y la ejecuta rápido (que no siempre equivale a «bien»).
Hace unas semanas probé Claude Design con el sistema de diseño de uiFromMars Subí el archivo de Figma, pedí un rediseño de la página inicial y la de artículo y en pocos minutos tenía «algo» que parecía un diseño, porque utilizaba componentes que provenían del sistema de diseño. Claude hizo lo que le pedí: aplicó las reglas del sistema.
El problema no era que el resultado fuera feo (que lo era). El problema era que era una simple ejecución. No había ninguna pregunta seria detrás: ¿Para quién es esto? ¿Qué necesita alguien que llega a uiFromMars por primera vez? ¿Qué tiene que ocurrir después de que llegue? El output seguía el sistema… y aun así era incorrecto, porque nadie ni nada había pensado ni reflexionado cada decisión.
Eso es lo que llamo «parece que está bien», que es muy diferente de «esto está bien». La diferencia entre ambas cosas no es una cuestión técnica, es el criterio, el conocimiento y el oficio.
El diseño no es solo la interfaz
A estas alturas ya lo sabrás, pero el trabajo «real» de diseño no es aplicar un sistema predefinido: Es tomar decisiones que poco o nada tienen que ver con el sistema de diseño.
El diseño aparece cuando una heurística choca con una necesidad real del negocio y el equilibrio entre ambos se ve afectado. Aparece cuando los datos cuantitativos apuntan en una dirección y las entrevistas con usuarios apuntan en otra. Cuando algo es técnicamente correcto según las guías y aun así… está mal.
Uno de los ejemplos más claros de esto es el resultado de Snapchat en 2018. Hace ya varios años de ello, pero ejemplifica claramente qué pasa cuando se desconectan las partes. Lanzaron un rediseño que separó el contenido multimedia del feed de amigos con una lógica de producto aparentemente sólida, documentada, argumentada… y que aun así perdió 3 millones de usuarios activos en un trimestre y un 20% del valor en bolsa porque nadie estaba realmente escuchando a los usuarios. Estos lanzaron una petición para revertir los cambios llegó al millón de firmas.
El juicio, o el criterio, es lo que pasa cuando entiendes el sistema tan bien que sabes cuándo saltártelo. Cuando detectas que algo está mal aunque no puedas citar exactamente qué regla viola. Cuando llevas la conversación en una dirección que nadie había pedido porque intuyes algo que los demás todavía no están viendo.
Es también lo que distingue a los diseñadores que crecen de los que se estancan. No es casualidad que, de las tres habilidades que me han ayudado a crecer como diseñadora, ninguna sea técnica.
Lo que ningún archivo puede documentar
Hay una dimensión del diseño que no aparece en ningún design.md porque no es documentable: el contexto de la organización.
Ahora que lidero el equipo de diseño de WordPress.com es cuando más me doy cuenta de que diseño sin tocar interfaces. Sé qué batallas merece la pena luchar, reconozco cuando el enfoque de un proyecto no es el correcto, y sé navegar conversaciones complejas cuando todo el mundo apunta en direcciones distintas y debo encontrar la solución que aguante esta situación.
Nada de esto son reglas en un archivo markdown. Son el contexto, las relaciones personales y entre los equipos, la experiencia que he ido acumulando a lo largo de los años, etc.
Todo esto son exactamente las habilidades que, según los datos del mercado de trabajo en diseño en 2025, diferencian a los perfiles que consiguen trabajo de los que no. No es tanto lo bueno que sea tu portfolio, como tu capacidad de demostrar el impacto real de tu trabajo y tu capacidad de comunicar decisiones de forma efectiva.
Entonces, ¿design.md no sirve para nada?
No estoy diciendo esto.
Sobre el papel puede llegar a tener sentido: en equipos grandes o en productos complejos puede reducir fricción, mejorar la consistencia de los outputs y acelerar los resultados. Todo el mundo sabe qué guías seguir, y puedes producir interfaces consistentes de forma más rápida.
Pero un design.md solo captura lo que ya existe y lo utiliza. Es una lista de convenciones y acuerdos que se decidieron en un momento dado, pero no captura el por qué que hay detrás.
Volviendo al ejemplo de Apple que te compartía más arriba: el documento tiene una serie de tokens y «do» and «don’t», pero todo es técnico.
- Use 28px border-radius for all feature cards (#ffffff and #f5f5f7 backgrounds) — this exact value is the page's geometric signature.- Reserve #0071e3 exclusively for the primary 'Buy' CTA button. No other UI element uses this blue — its scarcity makes it the only color that reads as an imperative.- Use #f5f5f7 as page canvas and #ffffff as card surface. Never reverse this — cards must always be lighter than their parent background.- Do not center-align body paragraphs longer than 2 lines. Apple's body copy left-aligns in two-column feature layouts; centered text is reserved for single-line hero subheadings and price callouts.
Este tipo de documentos nunca se preguntan: oye, ¿pero de verdad necesitamos una landing page? Te facilita producirla, pero alguien debe decidir que debe existir primero, y por qué. Lo mismo con funcionalidades, nuevas secciones, etc.
La pregunta más útil
No se trata de preguntarte «¿puede la IA reemplazarme?» Es más bien «¿qué parte de mi trabajo es irreducible?»
Como he ido describiendo a lo largo del artículo, lo que no se puede automatizar no es la ejecución, es la pregunta previa a la ejecución. ¿Es este el problema correcto? ¿Estamos resolviendo lo que el usuario necesita o lo que el usuario dice que necesita? ¿Hay algo que se nos está escapando?
Esas preguntas requieren haber hablado con personas reales, haber entendido el contexto, haber desarrollado el ojo para detectar cuando algo parece bien pero no lo está. Eso no viene de un archivo con reglas. Viene de años de haber prestado atención al sector, a las tendencias, al contexto de la empresa en la que trabajas… y de seguir haciéndolo aunque las herramientas hagan cada vez más fácil saltarse ese paso.
Si quieres la versión práctica de esto (qué desarrollar, cómo posicionarte, qué priorizar en tu carrera ahora mismo), está todo en cómo no ser reemplazado por la IA como diseñador de producto.
En resumen: las interfaces se pueden documentar. El resto, no.
