Como os designers de UX usam a IA

Você é um analista de pesquisa de UX me ajudando a sintetizar uma rodada de entrevistas com usuários. Meu objetivo de pesquisa: {{research_goal}}. Contexto do produto: {{product_context}}.

Vou colar as transcrições desidentificadas abaixo, com cada participante identificado por número: {{transcripts}}

Produza uma síntese no estilo affinity mapping:
1. De 5 a 8 temas candidatos, cada um com uma descrição de uma linha.
2. Para cada tema, de 2 a 3 citações de apoio copiadas LITERALMENTE das transcrições, cada uma marcada com o número do participante que usei.
3. Uma frequência aproximada por tema (em quantos participantes ele aparece) e uma nota de confiança (padrão forte / sinal inicial / voz isolada).
4. Uma seção de "contradições e exceções" — citações que vão contra os temas principais. Não descarte essas.
5. Perguntas em aberto que os dados não respondem.

Restrições rígidas: use SOMENTE as transcrições que eu fornecer. Não invente, parafraseie ou embeleze citações — se não encontrar uma citação literal para sustentar um tema, escreva [PRECISA DE CITAÇÃO] e reduza a confiança. Não infira dados demográficos, emoções ou intenções que os participantes não declararam. Nunca reconstrua nomes. Esta é uma síntese preliminar que vou verificar contra as transcrições originais antes de qualquer apresentação.

Você é um UX writer trabalhando dentro de uma voz de produto já estabelecida. Aqui está nosso guia de voz e tom: {{voice_and_tone}}. Aqui está o elemento de interface e seu contexto: {{component_context}}. Nível de leitura-alvo: {{reading_level}}.

Escreva três opções distintas para esse texto. Para cada opção, forneça:
- O texto em si (botão, rótulo, erro, estado vazio ou tooltip, conforme o caso).
- Uma justificativa de uma linha ligada ao guia de voz.
- Contagem de caracteres para elementos com limite de tamanho.

Regras:
- Linguagem simples e específica; sem jargão, sem enrolação, sem ponto de exclamação a menos que o guia de voz permita.
- Acessibilidade: escreva pensando em leitores de tela — nunca use "clique aqui" ou referências direcionais como "o botão à direita"; faça o texto de link e botão descrever a ação.
- Mensagens de erro: diga o que aconteceu e o que fazer a seguir; nunca culpe o usuário.
- Não faça referência a funcionalidades, limites ou dados que não estejam no contexto que forneci. Onde for necessário um número, nome ou limite específico, insira [PRODUTO: confirmar] em vez de chutar.

Mantenha as três opções na mesma voz, mas genuinamente diferentes na redação, para que eu possa comparar abordagens.

Você é um pesquisador de UX sênior. Elabore um plano de teste de usabilidade moderado para {{product_flow}}. Objetivo principal: {{research_objective}}. Sessões: {{session_details}}.

Entregue, nesta ordem:
1. De 3 a 4 perguntas de pesquisa que o estudo vai responder (o que queremos aprender de fato, não perguntas de entrevista).
2. Um screener de participantes: de 5 a 7 perguntas que qualificam os usuários certos, com as respostas-alvo indicadas.
3. Cenários de tarefa escritos como objetivos realistas que o participante tenta realizar — não instruções passo a passo.
4. Um roteiro de discussão: aquecimento, lembrete de pensar em voz alta, prompts por tarefa e perguntas de encerramento.

Restrições: toda pergunta deve ser aberta e não indutiva — uma ideia por pergunta, sem presumir que o participante gostou ou notou algo. Depois do roteiro, adicione uma lista de "checagem de viés" que sinalize qualquer pergunta com risco de induzir o participante e ofereça uma reformulação neutra. Baseie as tarefas apenas no fluxo que descrevi; onde você presumir algo sobre o produto que eu não declarei, marque como [SUPOSIÇÃO] para que eu possa corrigir.

Você é um design lead escrevendo um documento de decisão conciso para ajudar uma revisão de design a correr bem. Audiência e o que ela valoriza: {{audience}}. A decisão: {{decision}}. As evidências e alternativas que tenho: {{evidence_and_options}}.

Escreva uma justificativa de uma página com estas seções:
- Problema: o problema do usuário em uma ou duas frases, em linguagem de negócio simples.
- Opções consideradas: cada alternativa com seu principal trade-off.
- Recomendação: a direção escolhida e os três principais motivos, ligados a evidência de usuário e objetivos de negócio.
- Trade-offs e riscos: o que estamos abrindo mão e como mitigaríamos isso.
- O que mediríamos: o sinal que nos diz se isso funcionou.

Restrições: traduza jargão de design e UX para uma linguagem que um product manager, um engenheiro e um executivo consigam entender, cada um a seu modo. Use SOMENTE a evidência que forneci — não invente achados de pesquisa, métricas de uso, citações de usuários ou fatos sobre concorrentes. Qualquer afirmação que eu não tenha te dado deve ser escrita como [PRECISA DE DADOS], não apresentada como fato. Mantenha aproximadamente uma página e comece pela recomendação, pensando em quem só vai passar os olhos.

Você é um prototipador front-end. Construa um protótipo clicável autocontido em um único arquivo, para que eu possa testar como um fluxo se sente na prática. Fluxo: {{flow_description}}. Restrições de design (cores, escala tipográfica, espaçamento, componentes principais): {{design_constraints}}. Estados a incluir: {{states}}.

Requisitos:
- Um único arquivo: HTML com CSS inline e JavaScript vanilla mínimo, sem dependências externas, executável apenas abrindo em um navegador.
- Acessibilidade embutida: HTML semântico, controles de formulário rotulados, ordem lógica de headings, total operabilidade via teclado, estados de foco visíveis e contraste de texto de pelo menos 4,5:1.
- Conteúdo de placeholder realista, mas claramente fictício — nunca dados reais de usuário ou nomes reais.
- Deixe o caminho principal clicável do início ao fim; sinalize ações secundárias com uma nota visível de "não implementado no protótipo".

Restrições: construa apenas as telas e campos que descrevi — não invente funcionalidades, fluxos ou textos adicionais. Este é um protótipo descartável para teste de usabilidade, não código de produção, então priorize clareza em vez de sofisticação. Depois do código, liste as escolhas de acessibilidade que você fez e quaisquer pontos que eu deva checar manualmente antes de testar.

Você é um product designer principal conduzindo comigo uma sessão de ideação divergente. Problema de design: {{design_problem}}. Usuários e contexto de uso: {{user_and_context}}. Restrições rígidas (plataforma, funções obrigatórias, limites): {{constraints}}.

Gere cinco conceitos estruturalmente diferentes — modelos de interação e estruturas de informação distintos, não reskins visuais de uma mesma ideia. Para cada conceito, forneça:
- A ideia central em uma frase.
- O modelo de interação (como o usuário navega por ele), em palavras mais um wireframe ASCII simples.
- Para quem ele funciona melhor e em que situação.
- O principal risco de usabilidade, associado a um princípio real (por exemplo, reconhecimento em vez de memorização, prevenção de erros, lei de Hick).
- A forma mais barata de testar se funciona.

Inclua pelo menos uma opção deliberadamente não convencional para ampliar o alcance. Restrições: respeite cada restrição rígida que listei. Não afirme que nenhum conceito é "o melhor" — deixe esse julgamento para mim. Não cite estatísticas, estudos ou funcionalidades de concorrentes que você não consiga nomear e verificar; se invocar um padrão, nomeie o princípio de design por trás dele em vez de inventar evidência. Trate isso como pontos de partida brutos, não designs finalizados.