Como usamos o ChatGPT no design de produtos digitais

A pergunta que a gente mais ouve sobre ChatGPT em projeto de produto é a errada. Não é “o que ele consegue fazer”. É “onde ele pode entrar sem estragar o trabalho”.

Design de produto é uma sequência de decisões que se apoiam umas nas outras. Se uma delas for tomada com base em texto plausível e sem lastro, tudo o que vem depois herda o erro, e ninguém percebe até a tela estar no ar. Por isso o método importa mais que a ferramenta.

Este artigo descreve o método que a Duplo D usa. Etapa por etapa, com o que entra, o que fica de fora, como a gente escreve o prompt, e os erros que já cometemos para não precisar cometer de novo.

01. A regra que decide tudo

Antes das etapas, uma regra única, e ela vale para qualquer ferramenta de IA generativa:

Um rótulo de botão você avalia em dois segundos. Um agrupamento de mil mensagens você confere abrindo uma amostra. Um resumo de entrevista você confere contra a transcrição. Nesses casos, o custo de errar é baixo e o de verificar também.

Agora o inverso: um dado de mercado que o modelo devolveu com número e fonte, uma citação de norma técnica, um argumento sobre o comportamento do seu público. Tudo isso sai com a mesma confiança e a mesma prosa bem construída, esteja certo ou completamente inventado. É aí que projetos tomam decisão errada com cara de decisão fundamentada.

Todo o resto deste artigo é aplicação dessa regra.

02. Etapa 1: ler o material que ninguém lê

Esta é a etapa em que o ganho é maior e o risco é menor, e por isso é sempre por onde a gente começa.

Todo cliente chega com mais material do que imagina. Conversas de WhatsApp de dois anos. Chamados de suporte. Avaliações de loja. Comentários em post. Planilha de motivos de cancelamento preenchida às pressas. Esse material responde perguntas que o cliente costuma pagar pesquisa para descobrir, e quase nunca é lido, porque ler mil itens é um trabalho que ninguém tem tempo de fazer.

O que a gente pede, em ordem:

Agrupamento com contagem. “Agrupe estas mensagens por assunto. Para cada grupo, dê um nome curto, a quantidade e três exemplos textuais.” A contagem transforma sensação em número, e os exemplos textuais permitem conferir se o grupo faz sentido sem reler tudo.

Separação entre problema e pedido. Cliente costuma pedir solução, não descrever problema. “Para cada item, separe o que a pessoa pediu do problema que ela estava tentando resolver.” Essa distinção sozinha já muda o escopo de muitos projetos.

Onde a pessoa desistiu. “Nestas conversas, identifique o momento em que o assunto morre sem resolução e o que estava sendo tratado ali.” É um mapa de atrito construído com material que a empresa já tinha.

Vocabulário real. “Liste os termos que os clientes usam para falar de cada assunto, na frequência em que aparecem.” É a matéria-prima da arquitetura da informação e do SEO, e quase sempre contradiz o vocabulário interno da empresa.

O que a gente confere sempre: abrir cinco itens de cada grupo e verificar se estão no lugar certo. Leva dez minutos e pega a maior parte dos erros de classificação.

O que a gente nunca aceita direto: a conclusão. Se o modelo diz “o principal problema é o preço”, isso é uma hipótese com aparência de achado. Frequência não é importância, e a queixa que aparece quatro vezes pode valer mais que a que aparece trezentas, se as quatro forem dos maiores clientes.

03. Etapa 2: nomear as coisas

Nomear é metade do design de produto e ninguém fala disso. O nome da seção, do plano, do status, do botão. Nome ruim gera dúvida, dúvida gera atendimento, atendimento gera custo.

É uma tarefa quase perfeita para IA: a saída é curta, a avaliação é imediata, e o volume ajuda. Pedir trinta nomes para uma seção custa segundos e a leitura da lista inteira leva um minuto.

O prompt que a gente usa tem uma característica: pede variação em eixos, não só quantidade.

A última frase é a parte que mais serve. Pedir os riscos de confusão devolve algo que a lista sozinha não daria, e é exatamente o tipo de checagem que se esquece de fazer às cinco da tarde.

04. Etapa 3: alternativas de fluxo e de interface

Esta é a etapa mais mal compreendida. A tentação é pedir a tela pronta; o valor está em pedir os caminhos.

Antes de desenhar, a gente descreve o objetivo e as restrições e pede abordagens diferentes de resolver. Cinco caminhos para o mesmo cadastro: tudo em uma tela, dividido em passos, progressivo com o mínimo primeiro, conversacional, ou preenchido a partir de um dado que já existe. Cada um com o que ganha e o que perde.

Isso ataca o vício mais comum do ofício, que é apaixonar-se pela primeira solução. Quando explorar ficou barato, não explorar virou escolha, e escolha ruim.

Três coisas que a gente pede nesta etapa:

Os casos que quebram o fluxo. “Liste as situações em que este fluxo falha ou fica estranho.” O modelo é bom nisso porque leu muitos sistemas, e lembra do usuário sem sobrenome, do cadastro duplicado, do CEP que não existe. Não substitui a análise de quem conhece o negócio, mas cobre o esquecimento.

O texto de interface completo. Rótulo, ajuda, erro, estado vazio, confirmação, sucesso. Escrever tudo isso de uma vez, com tom definido, evita a colcha de retalhos que aparece quando cada tela é escrita em um dia diferente.

A versão para quem já sabe. Sistemas são desenhados para o primeiro uso e vividos no centésimo. “Como este fluxo ficaria para alguém que faz isso todo dia?” costuma revelar que metade das confirmações sobra.

O que a gente não pede: layout final. O modelo devolve a média do que existe na internet, e a média é a razão pela qual tantos produtos recentes se parecem. Direção visual sai do design system e da marca, não do prompt.

Vale uma observação sobre o que acontece com o time nesta etapa. Quando aparecem cinco caminhos na mesa em vez de um, a conversa entre designer e cliente muda de natureza. Deixa de ser “gostei” ou “não gostei” de uma proposta única e passa a ser uma comparação com critério: qual deles resolve o problema com menos passos, qual é mais barato de construir, qual envelhece melhor quando o catálogo dobrar de tamanho. Essa é a parte do trabalho que a ferramenta não faz e que ela torna possível fazer com mais frequência, porque o custo de ter opções caiu.

E um cuidado que economiza retrabalho: as alternativas precisam ser realmente diferentes entre si, não cinco variações do mesmo desenho. Se as cinco chegarem parecidas, o problema costuma estar no pedido, que descreveu a solução em vez de descrever o objetivo e as restrições.

05. Etapa 4: revisar antes de entregar

A revisão é a etapa em que a IA mais paga o próprio custo, porque revisar é um trabalho que exige atenção constante e que a atenção humana faz mal no fim do dia.

As passadas que a gente roda:

Consistência de termo. “Nesta lista de textos de interface, aponte onde o mesmo conceito recebeu nomes diferentes.” Descobre que a mesma coisa é “conta”, “perfil” e “cadastro” em três telas.

Mensagem de erro que ajuda. Toda mensagem de erro precisa responder o que aconteceu e o que fazer agora. Pedir a revisão sob esse critério pega as que só cumprem a primeira metade.

Leitura por perfil. “Leia como alguém que nunca usou um sistema parecido e liste onde travaria.” Não substitui teste com usuário, e vale para pegar o óbvio antes de gastar teste com o óbvio.

Acessibilidade de conteúdo. Texto alternativo de imagem, rótulo de campo, título de link fora de contexto. É verificação de padrão em volume, exatamente o formato certo.

E o limite honesto: a IA não revisa acessibilidade de verdade. Contraste real, ordem de foco no teclado, o que o leitor de tela anuncia. Isso se mede e se testa. Já encontramos um acordeão com todos os atributos corretos que simplesmente não abria pelo teclado, e ele passaria em qualquer revisão de texto.

06. Como a gente escreve os prompts

Existe muita mística sobre isso e pouca substância. O que funciona em projeto de produto tem cinco partes, e a diferença entre um resultado inútil e um resultado aproveitável quase sempre está na segunda.

1. 1

   Papel e público

   Quem está falando e para quem. “Você está escrevendo para dono de oficina mecânica, pouco familiarizado com sistema.” Isso calibra vocabulário e nível de explicação melhor que qualquer instrução de tom.

2. 2

   Contexto real, colado inteiro

   A parte que quase todo mundo pula. Cole o material: as mensagens, o fluxo atual, as restrições técnicas, o texto que já existe. Prompt curto sobre assunto complexo devolve resposta genérica, e resposta genérica é a queixa mais comum de quem acha que a ferramenta não serve.

3. 3

   Tarefa única e verificável

   Uma coisa por vez. Pedir agrupamento, priorização e redação no mesmo prompt devolve as três feitas pela metade. E a tarefa precisa ter um jeito de conferir, senão não deveria estar sendo pedida.

4. 4

   Formato de saída

   Tabela com estas colunas, lista com no máximo duas palavras por item, um parágrafo por grupo. Formato definido é o que permite comparar duas rodadas e o que evita a parede de texto que ninguém lê.

5. 5

   Limite explícito

   “Se a informação não estiver no material que enviei, escreva ‘não consta’ em vez de supor.” É a instrução que mais reduz invenção, e a que mais gente esquece de dar.

07. Os erros que a gente já cometeu

Aceitar a conclusão junto com a organização. O modelo organizou mil mensagens em doze temas, e o relatório saiu com a ordem de prioridade dele. A ordem estava por frequência, e a prioridade do negócio era outra. Hoje pedimos o agrupamento e fazemos a priorização na mão, com o cliente na sala.

Pedir a tela pronta cedo demais. Recebemos algo plausível, gostamos, e passamos a discutir aquilo em vez de discutir o problema. A ferramenta encurtou o caminho até uma resposta e encurtou junto a etapa de duvidar dela.

Confiar em número devolvido pelo modelo. Dado de mercado, percentual, referência de estudo. Sai com a mesma confiança do resto. Hoje, número que vai para documento de cliente vem de fonte que dá para abrir.

Deixar o tom escorregar. Vários textos de interface gerados em sessões diferentes, cada um com um registro. O sistema ficou com voz de três pessoas. A correção é escrever o guia de tom antes e colar em todo prompt de redação.

Perguntar sobre o próprio produto. O modelo não conhece o sistema do cliente. Quando a pergunta é sobre o que existe lá dentro, a resposta é invenção educada. Para isso o caminho é outro: uma base de conhecimento com os documentos reais, com busca e citação da fonte.

08. O que nunca vai para uma ferramenta pública

Regra escrita, conhecida por quem executa, não só por quem assinou o contrato.

Não vai: base de clientes, dado pessoal identificável, contrato, credencial de acesso, chave de API, código proprietário do cliente, número financeiro não público, e qualquer documento que o cliente classificou como interno.

Vai: material público, texto que a própria empresa publicou, conteúdo anonimizado, e material do cliente quando existe autorização escrita e a ferramenta usada é a adequada.

Anonimizar não é só trocar o nome. Contexto identifica: cidade pequena, cargo raro, valor específico. Quando o conjunto identifica mesmo sem o nome, o material não está anonimizado.

E a alternativa correta quando a IA precisa mesmo dos documentos da empresa: uma base de conhecimento privada, com busca vetorial, citação da fonte e controle de acesso por perfil. É outro projeto, com outro custo, e é o caminho honesto. Colar contrato em ferramenta pública para economizar esse projeto é o tipo de economia que aparece depois como problema.

09. Perguntas frequentes

10. Resumindo o método

Use onde conferir é rápido. Cole o contexto real, sempre. Peça uma tarefa por vez, com formato definido e um limite escrito contra a invenção. Confira uma amostra antes de aceitar o todo. E mantenha fora da ferramenta o que não pode sair da empresa.

Nada disso é sobre a ferramenta. É sobre onde uma pessoa decide, e onde ela decidiu não decidir.