Como usar Claude no design: briefings, copy, crítica e handoff

O Claude consegue aceitar uma imagem, então você pode soltar uma captura de tela de um frame do Figma, um wireframe ou uma tela já publicada e fazer perguntas diretamente sobre ela: essa hierarquia faz sentido, a ação principal está óbvia, isso combina com o padrão usado na tela anterior.

Ele está lendo pixels da mesma forma que uma pessoa passando os olhos por uma captura de tela faria, não interpretando a estrutura de camadas ou as propriedades de componentes do seu arquivo do Figma. Ele não vai saber quais são seus design tokens, sua biblioteca de componentes, ou qual frame é o 'de verdade', a menos que você diga a ele. Trate-o como uma segunda leitura rápida, não como um revisor que conhece seu design system.

A versão mais útil disso é estreita: uma tela, uma pergunta específica. 'O estado de erro está claro aqui' gera uma resposta mais afiada do que 'revise esse fluxo inteiro', da mesma forma que um colega de equipe dá uma resposta melhor quando você pergunta algo específico em vez de entregar o arquivo inteiro.

Digamos que um projeto comece como a maioria começa: uma thread no Slack com um gerente de produto, uma conversa de corredor meio esquecida, e algumas linhas em um ticket que não concordam totalmente entre si. Em vez de ficar olhando para um template de briefing em branco, cole tudo isso no Claude como material bruto e peça a ele para separar o sinal do ruído.

Peça diretamente pelas partes que um briefing precisa: qual é o problema real que está sendo resolvido, quais restrições já foram mencionadas (um prazo, uma limitação de plataforma, uma regra de marca), o que contaria como sucesso, e o que ainda está sem resolver. O Claude frequentemente traz à tona uma contradição que você não notou, como uma restrição mencionada uma vez no início da thread e depois esquecida.

O resultado não é final. É um primeiro rascunho já organizado em vez de uma página em branco, o que significa que a edição que você faz depois está refinando conteúdo real em vez de inventar estrutura do zero. Essa é a economia de tempo real: não a escrita em si, mas pular a etapa da página em branco.

Ler sobre esses fluxos de trabalho e realmente aplicá-los são habilidades diferentes. O caminho inicial abaixo foi criado para fechar essa lacuna em três lições curtas, nesta ordem.

Comece com "As Três Formas de Usar o Claude", do curso Os Três Modos, uma lição de cinco minutos que cobre a diferença entre um chat rápido, uma sessão de cowork mais longa, de ida e volta, e o Claude Code. A maior parte do trabalho de design, seja uma pergunta de crítica, uma passada de copy ou um briefing, vive nos dois primeiros modos, então essa lição ajuda você a escolher o modo certo em vez de simplesmente usar a aba que estiver aberta.

Depois, passe para "O Contexto É Tudo", do curso Prompting Estratégico, também de cinco minutos. É a lição que transforma um briefing genérico em um que reflete seu projeto real: ela cobre o que colar (suas anotações reais, sua voz de marca, a tela específica) para que o Claude não fique adivinhando um contexto que nunca recebeu.

Termine com "O Ciclo de Iteração", do curso Domine o Essencial, uma lição de seis minutos sobre tratar a primeira resposta do Claude como um rascunho, não como um veredito. Para um designer, essa é a diferença entre aceitar o primeiro conjunto de opções de copy de interface que ele oferece e realmente reduzir oito opções a duas através de algumas rodadas de ajustes.

A diferença entre uma resposta genérica e uma útil é quase sempre o contexto que você deu a ela. Para o trabalho de design especificamente, isso significa colar as coisas que vivem na sua cabeça ou nos seus arquivos, mas que nunca chegam a entrar em um prompt curto: as anotações reais da reunião, em vez da sua lembrança delas, suas diretrizes de voz de marca, se você as tiver por escrito, e a captura de tela específica, em vez de uma descrição de uma tela.

Também significa ser específico sobre o escopo. "Revise este fluxo" convida a uma resposta vaga e dispersa. "Olhe para a tela de confirmação e me diga se a ação secundária compete com a principal" convida a uma resposta útil. Quanto mais estreita a pergunta, mais vale a pena fazê-la.

Se você vai fazer o mesmo tipo de pergunta repetidamente, como a mesma checagem de acessibilidade em cada nova tela ou a mesma orientação de tom para cada peça de copy de interface, vale a pena escrever esse contexto uma vez e reutilizá-lo, em vez de reexplicar sua voz de marca em cada conversa.

O Claude não gera UI pronta para produção, não manipula seu arquivo do Figma, e não tem suas diretrizes de marca memorizadas, a menos que você as cole. Ele também não consegue validar o acabamento visual da forma como um olho treinado consegue; ele raciocina sobre estrutura, hierarquia e clareza a partir do que está visivelmente na imagem, não sobre se algo parece certo no nível do pixel.

Para acessibilidade, trate suas checagens como uma primeira passada, não como uma aprovação final. O trabalho real de acessibilidade precisa de ferramentas de checagem de contraste, testes com leitor de tela e, muitas vezes, uma revisão especializada, especialmente para qualquer coisa que vá para um público amplo. Não diga a um stakeholder ou a um revisor de conformidade que um design foi checado para acessibilidade só porque o Claude olhou para uma captura de tela.

O mesmo cuidado se aplica antes de qualquer coisa ir para um cliente, um consumidor ou um colega de equipe: leia o que o Claude produziu antes de enviar. Um documento de handoff com uma nota de interação errada, mas dita com confiança, é pior do que nenhum documento, porque um engenheiro vai construir a partir dele.

Ele também só é tão bom quanto o que você dá a ele. Um briefing escrito a partir de um prompt de duas linhas vai parecer genérico; um briefing escrito a partir de uma transcrição real de conversa ou de um conjunto real de anotações vai realmente refletir o projeto.