Qué necesita un agente de tu sistema de diseño en Markdown

El contenido del portfolio en texto estructurado para leerlo, compartirlo o usarlo como contexto en un asistente de IA.

_IA Y DISEÑO_

# Diseñar con IA: el proceso ha cambiado, el canvas aún no

Hace dos años la IA ayudaba a redactar un texto. Hoy interviene en cada paso del diseño, de la investigación a la entrega. Lo que no ha desaparecido es el canvas: Figma pierde peso, pero sigue siendo donde los equipos prueban, discuten y deciden.

Javier González · 11 nov 2026 · 7 min de lectura

## No es una herramienta nueva: es un compañero en cada paso

Cuando se habla de IA y diseño se piensa en generar pantallas a partir de un prompt. Es lo más visible y lo menos importante. Lo que ha cambiado de verdad el trabajo es que la IA ha entrado en todos los pasos del proceso, también en los menos vistosos: transcribir, agrupar, comparar, comprobar, traducir un diseño a código.

Esto es lo que veo en mi trabajo y en los equipos con los que colaboro, paso a paso.

### 1. Investigar
- **Antes:** Entrevistas, encuestas y notas a mano.
- **Ahora:** Transcripción y un primer agrupado de temas en minutos.
- **Sigue siendo humano:** Decidir a quién y qué preguntar; leer entre líneas.

### 2. Sintetizar
- **Antes:** Post-its y semanas de trabajo de afinidad.
- **Ahora:** Agrupaciones y resúmenes, contrastados con la fuente.
- **Sigue siendo humano:** Darle sentido y fijar prioridades.

### 3. Idear
- **Antes:** Bocetos y un puñado de opciones.
- **Ahora:** Decenas de variantes y referencias en una tarde.
- **Sigue siendo humano:** Elegir con criterio y descartar.

### 4. Diseñar y prototipar
- **Antes:** Pantallas estáticas en Figma.
- **Ahora:** Prototipos funcionales generados y afinados con agentes.
- **Sigue siendo humano:** Coherencia, jerarquía y detalle.

### 5. Validar
- **Antes:** Pruebas tras semanas de montaje.
- **Ahora:** Se prueba antes, con revisiones automáticas de accesibilidad y consistencia.
- **Sigue siendo humano:** Hablar con usuarios reales y decidir.

### 6. Entregar
- **Antes:** Especificaciones y reuniones de traspaso.
- **Ahora:** Componentes y estructura que el código ya entiende.
- **Sigue siendo humano:** Acordar las reglas y revisar el resultado.

Tres desplazamientos se repiten en todos los pasos.

- **El coste de la primera versión ha caído casi a cero.** Explorar diez opciones cuesta lo que antes costaba dibujar una.
- **El cuello de botella ya no es producir, es evaluar.** Con más opciones y más material, lo difícil es saber cuál es buena y por qué.
- **La entrega deja de ser un traspaso.** Cuando un prototipo es código real y las reglas están en el repositorio, diseño y front dejan de pasarse archivos y empiezan a trabajar sobre lo mismo.

Nada de esto elimina el juicio. Lo concentra: se hace menos de lo mecánico y más de lo que exige criterio.

## Por qué Figma sigue en el centro, por ahora

Figma está perdiendo peso. Los prototipos nacen cada vez más en código, las reglas del sistema viven cada vez más en un repositorio y los agentes leen estructura, no capas. Pero sigue siendo la herramienta de referencia, y creo que por una razón que no es técnica: un equipo necesita un lugar común para ver, discutir y decidir.

Hay cuatro cosas que un canvas hace muy bien y que ninguna alternativa ha resuelto todavía:

- **Probar.** Mover algo y ver al instante qué pasa, sin compilar ni desplegar.
- **Discutir.** Señalar, comentar y comparar junto a quien no programa: producto, negocio, dirección.
- **Visualizar.** Ver varias opciones y flujos a la vez, no una pantalla cada vez.
- **Iterar.** Deshacer, duplicar y rehacer sin coste, delante de todos.

Un stakeholder no revisa un pull request. Quiere un sitio donde ver la idea, tocarla y decir «esto no». Hoy ese sitio sigue siendo un canvas. Mientras los prototipos en código no ofrezcan la misma rapidez de conversación, Figma seguirá siendo útil.

Lo que sí está cambiando es su papel. De fuente de verdad pasa a ser una vista más: un lugar para explorar y acordar, conectado mediante tokens y variables a un sistema que vive fuera. Lo conté en [el artículo sobre sistemas de diseño headless](https://baguelus.com/es/articulos/sistema-diseno-headless/).

## El stack de herramientas, ayer y hoy

El cambio no es solo de herramientas. Antes cada paso tenía la suya y el traspaso de una a otra era manual. Hoy hay una cadena, con un agente en medio, que lee y escribe en casi todas.

| | Ayer | Hoy |
|---|---|---|
| **Investigar y sintetizar** | UserZoom, hojas de cálculo, Miro y post-its | Transcripción y agrupado con ChatGPT o Claude, automatizado con n8n |
| **Ideas y flujos** | Papel, pizarras, Miro | Variantes con un LLM; una pizarra compartida solo para decidir juntos |
| **UI y prototipos** | Sketch y después Figma; prototipos enlazados | Figma como canvas; prototipos funcionales con Lovable o Claude Code |
| **Entrega** | Documentos de especificación, Zeplin, reuniones de traspaso | Figma MCP, tokens y contratos en el repositorio, Storybook |
| **Construcción** | Front-end construido desde cero | Cursor, Claude Code o Codex con el sistema de diseño como contexto |

Lo que se mantiene es llamativo: Figma, Git y Storybook siguen ahí. Lo que ha perdido casi todo su sentido es la herramienta dedicada a «entregar»: la especificación como documento se ha convertido en estructura que el código lee.

## Qué espero de 2027 y 2028

Todo esto cambia cada pocos meses, así que lo que sigue son apuestas, no predicciones. Las dejo por escrito para poder revisarlas dentro de un año.

**Hoy · Finales de 2026**
- Figma sigue siendo el canvas de referencia.
- Los agentes escriben código de interfaz a partir de diseños y del repositorio.
- Se valida con prototipos en código.
- El sistema de diseño empieza a vivir fuera de Figma.

**2027 · Apuesta**
- Los canvas se acercan al código: lo que se discute es el componente real.
- Diseñar y construir dejan de ser dos archivos separados.
- Revisar lo que produce la IA se vuelve una tarea diaria del diseñador.
- Figma pasa de ser la fuente a ser una vista.

**2028 · Apuesta más incierta**
- Una herramienta de tipo nuevo: canvas visual conectado al código real y a las reglas del sistema.
- Los stakeholders comentan versiones vivas, no frames.
- El rol de diseño se inclina hacia curar restricciones, evaluar y decidir.
- Se generalizan los diseñadores que también construyen.

Lo que no apostaría: que los diseñadores desaparezcan, o que un prompt sustituya al canvas. Los equipos seguirán necesitando a alguien que entienda a las personas, defina las reglas y responda de lo que sale.

> La herramienta que reemplace a Figma no será un generador de pantallas. Será un canvas conectado al código real y a las reglas del sistema.

## Lo que me preocupa

- **Homogeneidad.** Si todos partimos de las mismas sugerencias, todo se parece.
- **Exceso de confianza.** Un resultado plausible no es un resultado correcto; hay que revisarlo con el equipo.
- **Accesibilidad y reglas.** Lo que no está escrito como regla, los agentes lo ignoran.

## Qué haría yo esta semana

1. **Elige un paso** donde pierdas más tiempo en tareas mecánicas y prueba la IA solo ahí.
2. **Escribe las reglas antes que los prompts:** tokens, componentes y criterios de aceptación.
3. **Mantén un canvas para decidir.** El código sirve para validar; el canvas, para conversar.
4. **Mide lo que cambia:** tiempo hasta la primera versión, rondas de revisión, errores en la entrega.