Cómo usar Claude en diseño: briefs, textos de interfaz, crítica y documentos de entrega

Claude puede recibir una imagen, así que puedes soltar una captura de un frame de Figma, un wireframe o una pantalla ya publicada y hacerle preguntas directamente sobre ella: ¿tiene sentido esta jerarquía?, ¿es obvia la acción principal?, ¿coincide esto con el patrón usado en la pantalla anterior?

Está leyendo los píxeles de la forma en que lo haría una persona echando un vistazo a una captura, no analizando la estructura de capas o las propiedades de componentes de tu archivo de Figma. No conocerá tus design tokens, tu librería de componentes ni cuál es el frame 'real' a menos que se lo digas. Trátalo como una segunda lectura rápida, no como un revisor que conoce tu sistema de diseño.

La versión más útil de esto es acotada: una pantalla, una pregunta específica. '¿Está claro aquí el estado de error?' obtiene una respuesta más precisa que 'revisa todo este flujo', del mismo modo que un compañero de equipo da una mejor respuesta cuando le preguntas algo concreto en lugar de pasarle todo el archivo.

Supongamos que un proyecto empieza como empiezan la mayoría: un hilo de Slack con un product manager, una conversación de pasillo a medio recordar y unas líneas en un ticket que no coinciden del todo entre sí. En lugar de quedarte mirando una plantilla de brief en blanco, pega todo eso en Claude como material en bruto y pídele que separe la señal del ruido.

Pide directamente las partes que necesita un brief: cuál es el problema real que se está resolviendo, qué restricciones ya se han mencionado (una fecha límite, una limitación de la plataforma, una norma de marca), qué contaría como éxito y qué sigue sin resolverse. Claude a menudo saca a la luz una contradicción que se te había pasado, como una restricción mencionada una vez al principio del hilo que luego se dejó de lado.

El resultado no es definitivo. Es un primer borrador ya organizado en lugar de una página en blanco, lo que significa que la edición que haces después afina contenido real en lugar de inventar la estructura desde cero. Ahí está el ahorro de tiempo real: no en la redacción en sí, sino en saltarte la etapa de la página en blanco.

Leer sobre estos flujos de trabajo y realmente ponerlos en práctica son habilidades distintas. La ruta inicial de abajo está pensada para cerrar esa brecha en tres lecciones cortas, en este orden.

Empieza con "Las tres formas de usar Claude" del curso Los tres modos, una lección de cinco minutos que explica la diferencia entre un chat rápido, una sesión de trabajo conjunto más larga e iterativa, y Claude Code. La mayor parte del trabajo de diseño, ya sea una pregunta de crítica, una pasada de textos o un brief, vive en los dos primeros modos, así que esta lección te ayuda a elegir el adecuado en lugar de quedarte con la pestaña que tengas abierta por casualidad.

Después pasa a "El contexto es todo" de Prompting estratégico, también de cinco minutos. Es la lección que convierte un brief genérico en uno que refleja tu proyecto real: explica qué pegar (tus notas reales, tu voz de marca, la pantalla concreta) para que Claude no tenga que adivinar un contexto que nunca se le dio.

Termina con "El bucle de iteración" de Domina lo esencial, una lección de seis minutos sobre tratar la primera respuesta de Claude como un borrador y no como un veredicto. Para un diseñador, esa es la diferencia entre aceptar el primer conjunto de opciones de texto de interfaz que te da y realmente acotar ocho opciones a dos tras unas cuantas rondas de seguimiento.

La diferencia entre una respuesta genérica y una útil casi siempre es el contexto que le diste. En el trabajo de diseño en concreto, eso significa pegar las cosas que viven en tu cabeza o en tus archivos pero que nunca llegan a un prompt corto: las notas reales de la reunión en lugar del recuerdo que tienes de ellas, tus guías de voz de marca si las tienes por escrito, y la captura concreta en lugar de una descripción de la pantalla.

También significa ser específico sobre el alcance. "Revisa este flujo" invita a una respuesta vaga y dispersa. "Mira la pantalla de confirmación y dime si la acción secundaria compite con la principal" invita a una respuesta útil. Cuanto más acotada sea la pregunta, más merece la pena hacerla.

Si vas a hacer el mismo tipo de pregunta de forma repetida, como la misma revisión de accesibilidad en cada pantalla nueva o la misma guía de tono para cada texto de interfaz, merece la pena escribir ese contexto una vez y reutilizarlo, en lugar de volver a explicar tu voz de marca en cada conversación.

Claude no genera interfaces listas para producción, no manipula tu archivo de Figma y no tiene memorizadas tus guías de marca a menos que las pegues. Tampoco puede validar el acabado visual como lo haría un ojo entrenado; razona sobre estructura, jerarquía y claridad a partir de lo que es visible en la imagen, no sobre si algo se siente bien a nivel de píxel.

En cuanto a accesibilidad, trata sus revisiones como una primera pasada, no como una aprobación final. El trabajo real de accesibilidad necesita herramientas de verificación de contraste, pruebas con lectores de pantalla y a menudo una revisión especializada, sobre todo para cualquier cosa que se publique para una audiencia amplia. No le digas a un stakeholder o a un revisor de cumplimiento que un diseño se ha revisado en accesibilidad solo porque Claude miró una captura.

La misma precaución aplica antes de enviar nada a un cliente, un usuario o un compañero de equipo: lee lo que produjo Claude antes de enviarlo. Un documento de entrega con una nota de interacción equivocada pero dicha con seguridad es peor que no tener documento, porque un ingeniero construirá a partir de ella.

También es tan bueno como lo que le das. Un brief escrito a partir de un prompt de dos líneas se leerá de forma genérica; un brief escrito a partir de una transcripción real de una conversación o un conjunto real de notas sí reflejará el proyecto.