Escribe /design seguido de un brief concreto en la misma línea, indicando qué pantalla rediseñar y bajo qué criterio. Claude publica un lienzo con varias propuestas editables y te imprime el enlace en la terminal. Abres el lienzo, comparas las mesas de trabajo, eliges una, la ajustas a mano y le dices a Claude cuál implementar. Requiere Claude Code 2.1.234 o superior y un plan Pro, Max, Team o Enterprise.
Si ya sabes que `/design` existe y lo que quieres es usarlo bien, esta es la guía. Cuatro pasos, con el detalle que cambia el resultado en cada uno.
Antes de empezar, dos requisitos que se comprueban en diez segundos:
Si cumples los dos, sigue.
El comando no abre un formulario. El encargo va pegado, en la misma línea:
```
> /design redesign the composer based on what people actually use it for
```
Ese es el ejemplo oficial de la documentación, y vale la pena mirarlo con calma porque enseña la forma correcta de pedir.
No dice "haz un composer bonito". Dice qué rediseñar y bajo qué criterio: según lo que la gente de verdad hace con él. Le estás dando a Claude una regla para decidir, no un adjetivo.
Traducido a briefs que puedes copiar hoy:
El patrón es siempre el mismo: qué pantalla + para qué usuario o qué objetivo. Un brief sin criterio te devuelve variaciones decorativas. Un brief con criterio te devuelve decisiones.
Claude no te contesta con texto. Publica un lienzo y te imprime el enlace en la terminal.
Dentro hay varias mesas de trabajo (artboards), una al lado de otra, cada una con una propuesta distinta de esa misma pantalla. Verlas juntas es la mitad del valor: comparar tres opciones reales es un ejercicio muy distinto a leer tres párrafos describiéndolas.
Un consejo de uso: míralas antes de leer la explicación de cada una. Tu primera reacción visual, sin el argumento encima, es la información más honesta que vas a tener sobre cuál funciona.
Las mesas de trabajo son editables. No estás obligado a aceptar una propuesta tal como vino.
Este es el paso que la mayoría se salta, y es el que marca la diferencia entre usarlo como generador de ideas y usarlo como herramienta de trabajo. Casi nunca vas a querer la opción A entera: vas a querer la estructura de la A con el bloque de la C. Ajústalo ahí mismo, en el lienzo, antes de que nada toque tu código.
Cuanto más concreto dejes el lienzo, menos interpretación tendrá que hacer Claude después.
Vuelves a la terminal y le dices cuál. Claude toma esa mesa de trabajo y la implementa en tu código.
Ahí es donde el flujo se cierra: el boceto y la implementación no viven en dos herramientas distintas con una persona traduciendo en medio. Es el mismo hilo.
Recomendación práctica: haz esto sobre una rama limpia y revisa el diff como revisarías el de cualquiera. Que la propuesta visual esté aprobada no significa que la implementación lo esté.
1. Brief vago. "Mejora esta pantalla" no es un criterio. Si no le dices para quién o para qué, te devuelve gusto, no diseño.
2. Quedarte con la primera opción. El formato es un lienzo con varias propuestas precisamente porque la gracia está en comparar. Si eliges la primera sin mirar las otras, estás usando una herramienta de comparación como si fuera un generador.
3. Saltarte el ajuste. Ir directo de "me gusta la B" a "impleméntala" desperdicia el único momento en el que corregir sale gratis.
Es una vista previa de investigación. No sustituye a tu herramienta de diseño ni a un diseñador: no va a resolverte un sistema de diseño completo ni a entender el contexto de tu marca si no se lo das.
Lo que sí resuelve, y bien, es el trayecto más caro de cualquier cambio de interfaz: el que va de tener una idea a tenerla puesta.