Apostila completa de Design de Produtos com IA
Projetar com IA não é adicionar um botão de "gerar" — é desenhar para um material probabilístico: que às vezes acerta, às vezes inventa, demora, cobra e evolui. Esta apostila cobre os padrões de entrada e saída, como comunicar confiança e erro, os níveis de automação e o human-in-the-loop, a latência percebida e o custo na interface, os padrões de conversa e de agente, a avaliação de UX de sistemas não-determinísticos, e a ética, a acessibilidade e os componentes de IA num design system.
Projetar para o probabilístico
Objetivo: entender por que design de IA é diferente — o sistema é não-determinístico, falível, lento e caro — e quando não usar IA.
1.1 Determinístico × probabilístico
Numa UI tradicional, o mesmo input produz o mesmo output — você projeta caminhos finitos. Com um modelo de IA, o mesmo prompt pode dar respostas diferentes, algumas erradas, e a "correção" não é um bug a consertar, é uma propriedade do material. O design precisa acomodar:
- Variabilidade: a resposta muda; a UI não pode assumir um formato exato.
- Falibilidade: o modelo alucina, entende errado, recusa; o usuário precisa poder perceber e corrigir.
- Latência: segundos, não milissegundos; e variável.
- Custo por uso: cada geração custa; "gerar de novo" não é grátis.
- Evolução: o modelo muda (versão nova, provedor) e o comportamento junto.
1.2 IA como material, não como feature
"Colocar IA" não é uma decisão — é escolher aplicar um material com certas propriedades a um problema. A pergunta certa: este problema se beneficia de algo que aceita ambiguidade, gera linguagem/imagem, resume, classifica ou raciocina sobre texto — e o usuário tolera erro e espera? Se a tarefa exige exatidão determinística (somar valores, aplicar uma regra), use código.
Projete para o erro, não para o caso feliz. A demo mostra o caso feliz. O produto vive nos casos em que o modelo alucina, demora, recusa, ou o usuário não sabe o que pedir. Cada padrão desta apostila existe para tornar esses momentos toleráveis e recuperáveis.
1.3 Expectativas e o hype
- Prometer "mágica" cria decepção; prometer capacidades específicas ("resume reuniões", "acha o trecho relevante") calibra.
- Deixe claro o escopo (o que ele faz e não faz) e as limitações (pode errar datas, não tem acesso à internet, conhece até X).
- Um primeiro uso que falha bem (mostra como corrigir) constrói mais confiança que um que acerta por sorte.
1.4 Quando NÃO usar IA
- A tarefa tem uma resposta certa e verificável e o erro é caro (cálculo, conformidade, segurança).
- Uma regra simples ou um menu resolvem — IA seria mais lenta, cara e menos previsível.
- O usuário precisa de controle exato e repetível.
- Não há como o usuário verificar a saída e o erro passa despercebido.
- O custo (dinheiro, latência, privacidade, viés) supera o ganho.
Perguntas de abertura: "O que muda no design quando o sistema é probabilístico?" (variabilidade, falibilidade, latência, custo, evolução — projetar para o erro), "O que significa 'IA como material'?" (é uma propriedade com trade-offs, não um feature), "Quando você não usaria IA num produto?" (resposta determinística com erro caro; regra simples; controle exato; erro não verificável).
✏️ Exercício 1 — IA ou não
Para cada feature, decida "IA", "código" ou "IA + código com verificação", e justifique: (a) preencher automaticamente o endereço a partir do CEP; (b) sugerir uma resposta a um e-mail de cliente; (c) categorizar transações bancárias; (d) calcular o imposto de uma nota fiscal; (e) transformar uma foto de recibo em campos estruturados.
Gabarito (uma boa resposta): (a) código — é uma consulta a uma base; determinístico, erro caro. (b) IA — linguagem, tolera variação, o humano revisa e envia. (c) IA + código — o modelo classifica, mas com regras de override para padrões conhecidos e uma forma fácil de o usuário recategorizar (que vira sinal). (d) código — regra fiscal exata; nunca deixar um modelo "calcular imposto". (e) IA + verificação — o modelo extrai (OCR + estruturação), mas a UI mostra a imagem ao lado dos campos para o usuário conferir, destaca baixa confiança, e valida totais com aritmética.
Padrões de entrada
Objetivo: ajudar o usuário a dizer ao sistema o que quer — do campo aberto às affordances guiadas, entrada multimodal e o "blank page problem".
2.1 O problema da página em branco
Um campo de texto vazio com "Pergunte qualquer coisa" transfere todo o trabalho para o usuário, que muitas vezes não sabe o que o sistema consegue fazer nem como pedir. Sintomas: prompts vagos, decepção, abandono. As respostas:
- Sugestões / prompts de exemplo contextuais (não genéricos) — mostram capacidades e dão um ponto de partida editável.
- Templates / receitas para tarefas comuns ("Resumir este documento", "Reescrever mais formal").
- Chips / parâmetros — tom, tamanho, formato, idioma como controles, não como texto a digitar.
- Ações contextuais — o comando de IA aparece onde faz sentido (na seleção de texto, no cabeçalho de um item), já sabendo o alvo.
2.2 Campo aberto vs guiado
| Campo aberto (prompt livre) | Guiado (affordances) |
|---|---|
| Flexível, poderoso para quem sabe pedir | Descobrível, previsível, menos erro de prompt |
| Blank page problem; resultado depende da habilidade do usuário | Menos flexível; pode limitar usos avançados |
| Bom para: usuários experientes, casos abertos | Bom para: primeiro contato, tarefas repetíveis, contextos específicos |
A maioria dos bons produtos combina: guiado por padrão, com o campo aberto disponível — e as ações guiadas preenchem o campo, ensinando a formular.
2.3 Contexto: o que o sistema deve saber
- Deixe o usuário anexar contexto explicitamente: um documento, uma seleção, uma URL, um projeto, "o que conversamos antes".
- Mostre o contexto ativo (chips do que está incluído) e permita remover — o usuário precisa saber com base em quê a resposta virá.
- Entrada multimodal: colar/enviar imagem, arquivo, áudio (ver a apostila IA de Voz e Áudio), selecionar na tela.
2.4 Reduzir o custo de um prompt ruim
- Pré-visualização / interpretação: "Entendi que você quer X. Certo?" antes de gastar uma geração cara.
- Refino em vez de recomeço: "mais curto", "mude o tom", "foque em Y" como ações sobre a última saída.
- Autocompletar / sugerir o prompt enquanto digita.
- Histórico de prompts reutilizáveis.
Perguntas: "O que é o blank page problem e como resolver?" (campo vazio transfere o trabalho; sugestões contextuais, templates, chips de parâmetro, ações no lugar certo), "Campo aberto ou guiado?" (guiado por padrão + aberto disponível; o guiado preenche o campo e ensina), "Como o usuário controla o contexto?" (anexar explicitamente, ver o que está ativo, poder remover), "Como reduzir o custo de prompts ruins?".
✏️ Exercício 2 — Redesenhe a entrada
Um app de e-mail tem um botão "Escrever com IA" que abre um campo de texto vazio "Descreva o e-mail que você quer". A adoção é baixa e as reclamações são "não sei o que escrever" e "o resultado não é o que eu queria". Redesenhe os padrões de entrada.
Gabarito (uma boa resposta): tornar a IA contextual: se é resposta a um e-mail, o comando aparece na thread e já tem o contexto (o e-mail recebido) — o usuário escolhe uma intenção ("Aceitar", "Recusar educadamente", "Pedir mais informações", "Remarcar") em vez de descrever do zero. Chips de tom (formal/casual), tamanho (curto/detalhado) e idioma. Um campo de "detalhes opcionais" ("mencione que estarei fora na sexta") em vez de "descreva o e-mail". Preview do rascunho dentro do compositor, editável, com ações "mais curto / mais formal / regenerar" — refino, não recomeço. Para e-mail novo (sem contexto), oferecer templates ("cobrança amigável", "apresentação", "follow-up"). Guardar as escolhas frequentes do usuário como padrão.
Padrões de saída
Objetivo: apresentar a resposta de forma útil — streaming, formatação, incerteza visível, fontes, alternativas, e ações a partir da saída.
3.1 Streaming
- Mostrar o texto conforme é gerado reduz a latência percebida drasticamente e deixa o usuário começar a ler/avaliar antes do fim.
- Padrões: token a token (bom para texto conversacional), por bloco (parágrafo/seção — melhor quando a formatação importa), skeleton → conteúdo (quando a estrutura é conhecida).
- Permita cancelar durante o streaming (o usuário já viu que não é o que queria — não o obrigue a esperar nem a pagar o resto).
- Streaming e acessibilidade: leitores de tela não lidam bem com conteúdo que muda letra a letra — anunciar em blocos, ou oferecer "aguardar resposta completa" (Módulo 9).
3.2 Formatação e estrutura
- Renderize Markdown (listas, tabelas, código, títulos) — texto corrido de parágrafo único é difícil de escanear.
- Quando a saída é estruturada (uma lista de tarefas, campos extraídos, um comparativo), mostre como UI de verdade (cards, tabela, checkboxes acionáveis), não como texto que descreve a estrutura.
- Blocos de código / dados com botão de copiar; diffs quando a IA edita algo existente (Módulo 5).
3.3 Incerteza visível
- Um aviso discreto e persistente ("A IA pode cometer erros. Verifique informações importantes.") calibra sem alarmar.
- Sinalizar trechos de baixa confiança quando o sistema tem esse sinal (extração com score baixo, afirmação sem fonte) — sublinhado, ícone, cor + rótulo (nunca só cor — ver Cor).
- Não invente uma "barra de confiança" precisa se o número não é confiável — pior que não ter.
3.4 Fontes e atribuição (grounding)
- Quando a resposta vem de documentos (RAG — ver IA Generativa & RAG), cite as fontes inline (número, chip clicável que abre o trecho) — deixa o usuário verificar e aumenta a confiança justificada.
- Distinga visualmente o que veio das fontes do que o modelo "completou".
- Se não há fonte, não finja que há.
3.5 Alternativas e ações
- Regenerar (com aviso de custo/tempo se relevante); múltiplas opções lado a lado quando faz sentido (nomes, imagens, variações de texto).
- Ações a partir da saída: copiar, inserir no documento, aplicar a mudança, criar a tarefa, salvar — a IA gera, mas o valor está em usar o resultado com um clique.
- Editar a saída livremente — ela é um rascunho, não um veredito.
Perguntas: "Por que streaming?" (reduz latência percebida, permite avaliar antes do fim, permite cancelar), "Como você mostra uma saída estruturada?" (como UI acionável, não texto descrevendo estrutura), "Como comunicar incerteza sem alarmar?" (aviso persistente discreto + sinalizar baixa confiança quando há sinal; não inventar precisão), "Como funcionam as citações inline e por que importam?" (verificação + confiança justificada).
✏️ Exercício 3 — Padrões de saída de um "pergunte à base de conhecimento"
Um recurso responde perguntas com base na documentação interna. Especifique os padrões de saída: streaming, formatação, fontes, incerteza, ações, e o caso "não encontrei".
Gabarito (uma boa resposta): Streaming por blocos (a resposta costuma ter estrutura); botão cancelar. Formatação Markdown; se a resposta é um passo a passo, renderizar como lista numerada; se compara opções, uma tabela. Fontes: cada afirmação com um chip [1] clicável que abre o trecho exato do doc numa lateral, com o título e o link; uma lista "Fontes usadas" no fim. Incerteza: se o retrieval trouxe trechos com baixa relevância, um aviso "As fontes encontradas podem não cobrir bem essa pergunta"; nunca responder sem fonte fingindo ter. Ações: copiar, "abrir doc completo", 👍/👎 com campo opcional, "isso não respondeu". Não encontrei: dizer claramente ("Não encontrei nada na documentação sobre X"), sugerir reformular, oferecer abrir um chamado / perguntar a um humano — não alucinar uma resposta plausível.
Confiança, transparência e erro
Objetivo: calibrar a confiança do usuário (nem cega, nem cética demais), tornar o sistema legível, e projetar os erros específicos de IA.
4.1 Confiança calibrada
O objetivo não é "máxima confiança" — é confiança calibrada: o usuário confia na medida certa, verificando onde deve e delegando onde é seguro.
- Excesso de confiança (o usuário aceita tudo) → erros passam, dano.
- Desconfiança excessiva (revisa tudo obsessivamente) → a IA não economiza trabalho, adoção cai.
- Ferramentas: mostrar as fontes, sinalizar incerteza, deixar o erro ser visível e barato de corrigir, ser honesto sobre limitações desde o começo.
4.2 Legibilidade do sistema
- O que ele sabe: mostrar o contexto/memória que está sendo usado, e deixar editar e apagar (Módulo 7).
- O que ele pode fazer: capacidades e limites explícitos; as ferramentas/integrações ativas.
- Por que respondeu isso: uma explicação sob demanda ("mostrar raciocínio", "quais fontes", "o que considerei") — sem obrigar todo mundo a ler.
- De onde vem: gerado agora? cacheado? qual modelo/versão (quando relevante para o usuário avançado)?
4.3 Alucinação na interface
- Não dá para eliminar — dá para reduzir o dano: grounding com fontes verificáveis, saída estruturada validada, "não sei" como resposta aceitável e incentivada, e nunca colocar a IA como autoridade final em algo que o usuário não pode checar.
- Para dados factuais (datas, números, nomes, citações), tratar como precisando de verificação por padrão na UI.
4.4 Mensagens de erro de IA
| Situação | O que a UI deve fazer |
|---|---|
| Timeout / modelo lento | manter o "pensando" com progresso; oferecer cancelar; se falhar, "tente de novo" com 1 clique, sem perder o input |
| Rate limit / cota | explicar (não "erro 429"); dizer quando volta; oferecer alternativa (modelo menor, esperar, upgrade — sem dark pattern) |
| Contexto cheio | explicar em linguagem simples ("a conversa ficou longa demais"); oferecer resumir, começar novo tópico, remover anexos |
| Recusa (política/segurança) | dizer que não pode ajudar com aquilo, sem sermão; não bloquear a ferramenta inteira |
| Resposta vazia / incoerente | não mostrar lixo; "não consegui uma boa resposta" + regenerar / reformular |
| Ferramenta falhou (o agente) | dizer qual passo falhou e o quê; permitir repetir o passo, pular, ou assumir o controle |
4.5 Feedback loop
- 👍/👎 é o mínimo; melhor: o que estava errado (impreciso, formato, tom, não respondeu) e um campo livre opcional.
- A correção do usuário é o sinal mais rico: quando ele edita a saída, isso diz o que faltou — capture (com consentimento) para melhorar prompts/avaliação (ver a apostila LLMOps & Avaliação de Sistemas de IA).
- Feche o loop: se o feedback muda algo, o usuário deve perceber ("obrigado, isso ajuda a melhorar").
Perguntas: "O que é confiança calibrada e por que não 'máxima confiança'?" (confiar na medida certa; excesso deixa erro passar, falta mata a adoção), "Como você projeta erros de IA?" (traduzir o técnico — 429, contexto cheio, recusa, timeout — em linguagem e ações, sem perder o input), "Como lidar com alucinação na UI?" (grounding, verificação por padrão em fatos, "não sei" aceitável, não ser autoridade final), "Qual o sinal de feedback mais rico?" (a edição do usuário na saída).
✏️ Exercício 4 — Erros e transparência
Um assistente de análise de dados às vezes: (a) demora 40s e falha; (b) inventa um número que não está nos dados; (c) recusa uma pergunta por "política"; (d) responde com base em dados desatualizados. Para cada, descreva o que a UI mostra e as ações que oferece.
Gabarito (uma boa resposta): (a) durante os 40s: "Analisando… (isso pode levar até 1 min)" com opção de cancelar; ao falhar: "A análise não terminou. Tentar de novo?" com o input preservado; se repetir, sugerir uma pergunta mais específica ou um recorte menor. (b) prevenir: toda métrica na resposta vem com a fonte/consulta que a gerou (chip que mostra a query e o valor); a UI valida totais; se o modelo afirma um número sem consulta associada, marcar "não verificado" e oferecer "recalcular a partir dos dados". (c) "Não posso ajudar com essa solicitação específica" — curto, sem sermão, com a ferramenta continuando disponível para outras perguntas. (d) mostrar sempre a data dos dados ("Dados até 31/07") perto da resposta; se a pergunta implica algo mais recente, avisar "Os dados vão até 31/07; isso pode não refletir o mês atual" e oferecer atualizar a fonte.
Human-in-the-loop e níveis de automação
Objetivo: escolher o nível de autonomia certo, e projetar preview, aprovação, confirmação e reversibilidade.
5.1 O espectro de automação
| Nível | O sistema… | Bom quando |
|---|---|---|
| Sugere | propõe; o humano faz | alto risco, baixa confiança, o humano é o especialista |
| Rascunha | produz um resultado que o humano edita e conclui | economiza a parte chata; o humano garante a qualidade (e-mail, código, texto) |
| Faz com aprovação | prepara a ação; o humano confirma antes de executar | ações com efeito (enviar, apagar, comprar, publicar) |
| Faz e avisa | executa e reporta; o humano pode desfazer | baixo risco, reversível, alta confiança, volume alto |
| Autônomo | opera sem intervenção dentro de limites | tarefa bem definida, limites rígidos, monitoramento — raro em produto voltado ao usuário |
O nível varia por ação dentro do mesmo produto: um agente pode "fazer e avisar" para arquivar e-mails e "fazer com aprovação" para responder um cliente.
5.2 Preview e diff
- Antes de aplicar qualquer mudança em algo do usuário (um documento, uma config, um dado), mostre um preview ou um diff claro do que vai mudar.
- Deixe aceitar parcialmente quando fizer sentido (aceitar 3 das 5 edições sugeridas).
- Nada de "a IA reescreveu seu documento" sem o usuário ver o antes/depois.
5.3 Confirmação e reversibilidade
- Confirmação explícita para ações: destrutivas (apagar, sobrescrever), custosas (gastar crédito, disparar um job caro), externas (enviar e-mail, postar, chamar uma API de terceiro), ou de difícil reversão.
- Undo generoso para tudo que for reversível — reduz o medo e permite níveis de automação mais altos.
- Explique antes de agir: o agente diz o que vai fazer ("vou enviar este e-mail para 12 pessoas") antes de fazer.
- Limites e orçamento visíveis: "o agente pode gastar até X" / "fará no máximo N ações" — e para quando atinge.
5.4 Assumir o controle
- O usuário deve poder interromper o processo automático a qualquer momento e assumir — sem perder o trabalho feito até ali.
- Transição suave entre "a IA está fazendo" e "eu estou fazendo" (o resultado parcial é editável, o contexto é preservado).
Lance no nível mais baixo que ainda é útil (sugerir/rascunhar). Meça a taxa de aceitação e de correção. Só suba a autonomia de uma ação específica quando os dados mostrarem que o sistema acerta o suficiente e o erro é barato/reversível. Subir cedo demais gera um incidente que destrói a confiança e é difícil de recuperar.
Perguntas: "Descreva o espectro de automação e como escolher o nível" (sugerir → rascunhar → fazer com aprovação → fazer e avisar → autônomo; por risco, confiança, reversibilidade; varia por ação), "O que precisa de confirmação explícita?" (destrutivo, custoso, externo, difícil de reverter), "Por que preview/diff antes de aplicar?", "Como você decide subir a autonomia?" (dados de aceitação/correção + erro barato).
✏️ Exercício 5 — Níveis de automação de um agente de e-mail
Um agente de e-mail pode: arquivar newsletters, marcar como importante, redigir respostas, responder diretamente, agendar reuniões, cancelar reuniões. Atribua um nível de automação a cada, com a justificativa e o que a UI mostra.
Gabarito (uma boa resposta): Arquivar newsletters → "faz e avisa" (reversível, baixo risco, volume) — um resumo diário "arquivei 14 newsletters" com undo. Marcar importante → "faz e avisa" (reversível) ou "sugere" no começo, até calibrar. Redigir respostas → "rascunha" — o rascunho fica na thread, o humano edita e envia. Responder diretamente → "faz com aprovação" no mínimo, e só para casos muito rotineiros (confirmar recebimento, "obrigado") com uma allowlist; a UI mostra o texto e um "Enviar / Editar / Descartar" com timer curto opcional. Agendar reunião → "faz com aprovação" — mostra o convite (quem, quando, onde) antes de enviar. Cancelar reunião → "sugere" ou "faz com aprovação" com confirmação forte — é destrutivo e afeta outras pessoas; nunca automático.
Latência percebida e custo
Objetivo: fazer a espera parecer curta (streaming, skeleton, progresso, background) e tornar o custo/uso legível e justo.
6.1 A espera
- Streaming (Módulo 3) é a maior alavanca — o usuário lê enquanto gera.
- Skeleton com a métrica do conteúdo esperado (ver Motion de Interface) para respostas estruturadas.
- Estado "pensando" honesto: para agentes, mostrar as etapas ("buscando documentos… analisando… redigindo…") transforma espera opaca em progresso legível.
- Optimistic UI onde a ação quase sempre dá certo (aplicar uma sugestão) — mostrar o resultado já e reconciliar.
- Resultados parciais úteis: mostrar o que já está pronto (os 3 primeiros resultados) enquanto o resto vem.
- Cancelar sempre disponível durante a geração.
6.2 Esperar × background
- Tarefa < ~5–10s e o usuário precisa do resultado agora → esperar com streaming/progresso.
- Tarefa longa (analisar 200 páginas, gerar um relatório, um agente com muitas etapas) → rodar em background, liberar a UI, e notificar quando pronto (com o resultado acessível depois — não force o usuário a ficar olhando).
- Deixe claro qual é o caso ("Isso vai levar alguns minutos. Você pode fechar — avisamos quando terminar.").
6.3 Custo e uso na interface
- Se o produto tem créditos/cota/tokens, mostre o saldo e o consumo de forma compreensível (não "0,0034 USD" nem "1.204 tokens" para o usuário final — traduza para "≈ 3 respostas restantes hoje" ou uma barra).
- Antes de uma operação cara, sinalize ("Gerar o relatório completo usa ~10 créditos").
- Regenerar e "gerar mais opções" custam — deixe isso visível sem punir o uso normal.
- Rate limit gracioso (Módulo 4): degrade (modelo menor, fila) em vez de bloquear seco.
- Cache visível: "resposta salva desta pergunta" — o usuário entende por que foi instantâneo e não gastou.
Esconder o consumo até acabar. Fazer "regenerar" parecer grátis e cobrar por baixo. Empurrar o modelo caro como padrão sem o usuário escolher. "Você atingiu o limite" sem dizer quando volta nem oferecer alternativa. Gastar crédito numa geração que falhou por erro do sistema (não cobrar por falha nossa).
Perguntas: "Como reduzir a latência percebida de um recurso de IA?" (streaming, skeleton, progresso por etapas em agentes, optimistic UI, parciais úteis, cancelar), "Quando esperar e quando fazer em background?" (curto e necessário agora vs longo → background + notificação), "Como mostrar custo/uso ao usuário final?" (traduzir tokens/USD em algo compreensível; sinalizar operações caras antes; não cobrar por falha do sistema).
✏️ Exercício 6 — Espera e custo de um gerador de relatórios
Um recurso gera um relatório de 10 páginas a partir dos dados do usuário: leva 2–4 minutos, custa 10 créditos (o plano dá 100/mês), e às vezes falha na metade. Projete a experiência de espera e de custo.
Gabarito (uma boa resposta): Antes: ao clicar "Gerar relatório", um diálogo: "Isso leva 2–4 minutos e usa 10 créditos (você tem 100 este mês). Você pode continuar usando o app — avisamos quando ficar pronto." Confirmar. Durante: a tarefa vai para background; um indicador discreto no header ("Relatório: gerando… 40%") com etapas ("coletando dados → analisando → escrevendo → formatando"); o usuário navega livremente; cancelar disponível (e cancelar não cobra os 10 créditos, ou cobra proporcional ao que rodou, comunicado). Pronto: notificação in-app (e e-mail opcional) com link; o relatório fica salvo no histórico. Falha: "A geração falhou na etapa 'analisando'. Não descontamos créditos. Tentar de novo?" — com o input preservado. Custo: o histórico mostra "10 créditos" por relatório; a barra de créditos do mês fica visível nas configurações e alerta em ~80%.
Conversa, canvas e agentes
Objetivo: escolher entre chat, UI dedicada e IA inline; projetar memória e contexto; e a interface de um agente multi-etapa.
7.1 Chat não é sempre a resposta
| Forma | Boa para | Ruim para |
|---|---|---|
| Chat | exploração aberta, tarefas imprevisíveis, follow-up, quando o usuário não sabe as opções | tarefas repetíveis (relê tudo toda vez), ações precisas, descoberta de capacidades, resultado que precisa virar artefato |
| UI dedicada (formulário/painel de IA) | tarefa conhecida com parâmetros (gerar, resumir, traduzir), previsibilidade, integração no fluxo | casos abertos e conversacionais |
| IA inline / no canvas (seleção, comando "/", ação contextual) | agir sobre o conteúdo que já está ali, no contexto, sem trocar de lugar | tarefas que precisam de muito diálogo |
Muitos produtos combinam: ações inline para o comum, uma UI dedicada para tarefas nomeadas, e um chat para o resto. "Tudo é chat" costuma ser preguiça de design.
7.2 Memória e contexto
- O que persiste entre sessões (preferências, fatos sobre o usuário, projetos) deve ser visível, editável e apagável — uma tela de "o que a IA sabe sobre você".
- Adicionar à memória deve ser um ato claro (o usuário decide), não algo que acontece por baixo sem ele saber.
- Escopo: memória por projeto/espaço vs global; deixar claro o que está no escopo desta conversa.
- Esquecer: "esqueça isso", limpar a memória, e o efeito da LGPD (o usuário pode exigir).
7.3 Histórico
- Conversas salvas, tituladas (auto), buscáveis e retomáveis.
- Deixar ramificar (editar uma mensagem antiga e seguir por outro caminho) quando o produto se beneficia.
- Exportar / compartilhar uma conversa (com cuidado de privacidade — pode conter dados sensíveis).
7.4 A interface de um agente
Um agente que executa várias etapas (planeja, usa ferramentas, itera) precisa ser observável e controlável:
- Mostrar o plano antes de executar (quando a tarefa é grande) — e deixar ajustar.
- Progresso por etapa em tempo real: o que está fazendo, qual ferramenta chamou, o resultado de cada passo (colapsável).
- Ferramentas e permissões visíveis: o que o agente pode acessar/fazer; pedir permissão para o que é sensível (ver Criação de Agentes de IA, MCP).
- Interromper / ajustar / assumir a qualquer momento (Módulo 5).
- Ponto de aprovação antes de ações com efeito (Módulo 5).
- Resumo do que foi feito ao final, com links para o resultado e o que mudou.
Perguntas: "Chat sempre é a interface certa para IA?" (não — ruim para tarefas repetíveis, ações precisas, descoberta; usar UI dedicada e inline conforme o caso), "Como você projeta a memória de um assistente?" (visível, editável, apagável; adicionar é um ato claro; escopo; esquecer/LGPD), "Como deve ser a interface de um agente multi-etapa?" (plano visível e ajustável, progresso por etapa, ferramentas/permissões, interromper/assumir, aprovação para ações, resumo final).
✏️ Exercício 7 — Chat, painel ou inline
Um editor de documentos quer recursos de IA: (a) reescrever um parágrafo selecionado; (b) gerar um rascunho inteiro a partir de um briefing; (c) "converse com este documento" (perguntas, mudanças iterativas); (d) verificar consistência de termos ao longo do doc. Para cada, escolha a forma (chat / painel / inline) e descreva a interação e os pontos de aprovação.
Gabarito (uma boa resposta): (a) inline — seleciona o parágrafo, comando "Reescrever" com chips de tom/tamanho; o resultado aparece como diff sobre a seleção; aceitar/rejeitar/regenerar. (b) painel dedicado — um formulário de briefing (assunto, público, estrutura, tamanho); gera para uma área de rascunho separada do documento real; o usuário revisa e "inserir no documento". (c) chat lateral com o documento como contexto — bom para perguntas e pedidos iterativos; mudanças que ele propõe entram como sugestões/diffs no doc, nunca aplicadas direto. (d) painel/inline — um "verificador" que roda sobre o doc inteiro e lista inconsistências como itens navegáveis ("'usuário' vs 'utilizador' em 4 lugares"); cada item com "ir para" e "corrigir" (aplica um a um, com preview). Nada de reescrever o documento sem o usuário ver cada mudança.
Avaliar a UX de IA
Objetivo: métricas de produto para recursos de IA, instrumentação de feedback, testes com usuários para sistemas não-determinísticos, e o "red team de UX".
8.1 Métricas de produto
| Métrica | O que diz |
|---|---|
| Taxa de aceitação | quantas sugestões o usuário usa como estão (sinal forte de utilidade) |
| Taxa / grau de edição | quanto o usuário mexe na saída antes de usar (pouco = bom; muito = a IA não está economizando trabalho) |
| Taxa de regenerar / descartar | frustração; ou o padrão de entrada não está ajudando |
| Time to first useful output | do intent do usuário até algo que ele aproveita (não só "primeira resposta") |
| Abandono | começou a usar o recurso e saiu sem resultado |
| Retenção / recorrência do recurso | voltou a usar? virou hábito? |
| Taxa de fallback para humano | (em suporte/agentes) quantas vezes precisou escalar |
| Feedback explícito (👍/👎, motivos) | direção qualitativa; correlacionar com as outras |
8.2 Instrumentar o feedback
- Logar (com consentimento e privacidade — Módulo 9): o prompt, o contexto usado, a saída, a ação do usuário (aceitou / editou / descartou / regenerou), a edição feita, e o feedback explícito.
- Ligar isso ao pipeline de avaliação do modelo (ver LLMOps & Avaliação de Sistemas de IA) — a UX e o eval do modelo são o mesmo problema visto de dois lados.
8.3 Testes com usuários para o não-determinístico
- O mesmo roteiro dará respostas diferentes a cada participante — planeje para a variabilidade: roteiros com objetivos (não passos fixos), rodar mais sessões, observar como a pessoa reage quando o modelo erra (isso vai acontecer — é dado, não ruído).
- Perguntas: a pessoa percebeu o erro? soube corrigir? confiou demais/de menos? entendeu o que o sistema podia fazer?
- Dogfooding intenso — a equipe usando de verdade pega o que teste de laboratório não pega.
- Testar a confiança calibrada: dê tarefas onde a IA às vezes erra e veja se a pessoa verifica na hora certa.
8.4 Red team de UX
- Além do red team de segurança do modelo: o que acontece na interface quando o modelo erra feio na frente do usuário?
- Cenários: alucina um número num relatório financeiro; recusa algo legítimo; vaza um trecho de outro contexto; dá um conselho perigoso com confiança; o agente faz uma ação errada.
- Para cada: a UI limita o dano? o usuário consegue perceber e reverter? há um caminho de reportar? o incidente vira aprendizado?
Perguntas: "Que métricas você acompanha num recurso de IA?" (aceitação, grau de edição, regenerar/descartar, time to first useful output, abandono, retenção, fallback para humano), "Como você faz teste de usabilidade de um sistema não-determinístico?" (roteiros por objetivo, mais sessões, observar a reação ao erro, testar confiança calibrada), "O que é red team de UX de IA?" (simular o modelo errando feio na interface e checar se o dano é limitado e reversível).
✏️ Exercício 8 — Plano de medição
Você lançou "resumir thread" num app de mensagens. Defina: 4 métricas para saber se é bom, o que instrumentar, um roteiro de teste com usuário, e 2 cenários de red team de UX.
Gabarito (uma boa resposta): Métricas: (1) taxa de uso do resumo entre threads longas elegíveis; (2) taxa de "abrir a thread depois de ler o resumo" alta pode indicar que o resumo não bastou — ou que gerou interesse (analisar com feedback); (3) 👍/👎 e motivos ("faltou algo importante", "impreciso", "longo demais"); (4) retenção — % de usuários que usam de novo em 7 dias. Instrumentar: a thread (tamanho, participantes), o resumo gerado, a ação (leu / expandiu / deu feedback / ignorou), e — se o usuário corrigir/comentar — o quê. Roteiro de teste: "Você voltou de férias e tem uma thread de trabalho com 60 mensagens. Descubra o que você precisa fazer." Observar: confiou no resumo? checou a thread? o resumo omitiu algo que ela precisava? entendeu que é gerado e pode faltar coisa? Red team de UX: (a) o resumo atribui uma decisão à pessoa errada ("A Ana aprovou o orçamento", quando foi o João) — a UI mostra de onde tirou? é fácil ver que está errado? (b) a thread tem uma informação sensível (salário, demissão) e o resumo a destaca fora de contexto num preview de notificação — o resumo respeita a sensibilidade? há como não gerar resumo de certas threads?
Ética, acessibilidade e o design system de IA
Objetivo: evitar dark patterns de IA, garantir disclosure e privacidade, tornar a IA acessível, e sistematizar os padrões em componentes.
9.1 Dark patterns de IA
- Fingir ser humano quando não é (chat de "atendente" sem revelar que é bot) — em muitos lugares já é ilegal; sempre eticamente ruim.
- Antropomorfismo manipulador: o assistente "fica triste", "implora para não cancelar", finge emoções para influenciar.
- Confiança falsa: linguagem excessivamente assertiva, "certeza" fabricada, esconder a incerteza para parecer mais capaz.
- Empurrar consumo: sugerir "gerar mais opções" (que custam) sem necessidade; tornar o modelo caro o padrão.
- Consentimento enterrado para usar os dados do usuário como treino/contexto.
- Automação sem saída: dificultar assumir o controle ou desligar a IA.
9.2 Disclosure, consentimento e privacidade
- "Isto foi gerado/assistido por IA" onde importa (conteúdo publicado, respostas de atendimento, imagens) — e crescentemente exigido por regulação (ver Governança de IA, Ética & EU AI Act).
- O que vira contexto/treino: dizer claramente o que o produto envia ao modelo e se usa as interações para treinar; oferecer opt-out real; nunca enviar dados de terceiros sem base.
- Dados sensíveis no prompt/anexo: avisar, permitir redigir, ter política de retenção.
- Direito de exclusão (LGPD): apagar a memória, o histórico, o que foi aprendido.
9.3 Acessibilidade da IA
- Streaming e leitor de tela: conteúdo que muda token a token é caótico para quem usa leitor de tela — anunciar por blocos/ao concluir, usar
aria-live="polite"com cuidado, e oferecer "aguardar resposta completa". - Conteúdo que muda (a resposta cresce, o layout se move): gerenciar foco, não roubar o foco do usuário, não deslocar o que ele está lendo.
- Não depender de cor para "confiança" / "fonte" / "gerado por IA" — usar ícone + rótulo (ver Cor, Iconografia).
- Imagens geradas precisam de
alt— e o próprio sistema pode ajudar a gerá-lo, com revisão. - Entrada alternativa: quem não pode digitar prompts longos (voz — ver IA de Voz e Áudio —, sugestões, templates); a IA como ajuda de acessibilidade, não como barreira nova.
- Reduced motion nos indicadores de "pensando" e nas transições de streaming (ver Motion de Interface).
- Carga cognitiva: respostas longas e densas excluem; oferecer resumo/formato simples.
9.4 Componentes de IA num design system
Os padrões desta apostila viram componentes reutilizáveis — para consistência e para não redesenhar a cada recurso. Ver Design Systems & Design Tokens.
- PromptInput — campo com anexos de contexto (chips), sugestões, envio, contador; estados de foco/loading.
- ResponseStream — área de saída com streaming por bloco, Markdown, ações (copiar/inserir/regenerar), estado de erro.
- Citation / SourceChip — chip inline + painel de trecho da fonte.
- ConfidenceIndicator — sinal de incerteza (ícone + rótulo, nunca só cor), com regra de quando aparece.
- AISkeleton / ThinkingState — carregamento com a métrica do conteúdo; para agentes, o passo-a-passo.
- DiffPreview — antes/depois de uma edição sugerida, com aceitar parcial.
- AgentSteps — lista de etapas com status, ferramenta usada, colapsável, com interromper.
- ApprovalPrompt — "vou fazer X. Confirmar?" com o resumo da ação.
- FeedbackControl — 👍/👎 + motivos + campo livre.
- DisclosureBadge — "gerado por IA" / "assistido por IA".
- Motion tokens e UX writing próprios: a voz da IA (humilde, clara, sem se antropomorfizar demais), as strings de erro, os nomes das ações.
Perguntas: "Cite dark patterns de IA" (fingir ser humano, antropomorfismo manipulador, confiança falsa, empurrar consumo, consentimento enterrado, automação sem saída), "Que cuidados de acessibilidade a IA exige?" (streaming vs leitor de tela, foco em conteúdo que muda, não só cor para confiança, alt de imagens geradas, entrada alternativa, reduced motion, carga cognitiva), "Que componentes um design system de IA precisa?" (PromptInput, ResponseStream, Citation, Confidence, DiffPreview, AgentSteps, ApprovalPrompt, DisclosureBadge…).
✏️ Exercício 9 — Auditoria ética e de a11y
Um chatbot de vendas: (a) tem nome de pessoa e não diz que é IA; (b) responde sempre com muita certeza, sem fontes; (c) quando o usuário quer cancelar, o bot "fica chateado" e oferece desconto; (d) a resposta faz streaming letra a letra e o botão "falar com humano" só aparece depois. Aponte os problemas e as correções.
Gabarito (uma boa resposta): (a) disclosure: identificar-se como assistente de IA logo no início ("Oi, sou o assistente virtual da [empresa]"); em muitos lugares isso é obrigatório. (b) confiança falsa: fundamentar afirmações sobre produto/preço/política em fontes verificáveis (catálogo, termos) com citação; dizer "não tenho essa informação, vou te passar para uma pessoa" quando não sabe; calibrar a linguagem. (c) antropomorfismo manipulador + retenção coerciva: o bot não deve simular emoção para influenciar; o caminho de cancelamento tem que ser direto; oferta de retenção, se houver, é uma opção neutra e clara, não uma chantagem emocional. (d) acessibilidade: "falar com humano" (e outras saídas essenciais) sempre visível, não escondido atrás da animação; o streaming deve anunciar por blocos para leitor de tela e não roubar o foco; respeitar reduced motion no indicador. Extra: revisar se o bot fecha a interação sem deixar o usuário resolver o que veio fazer.
Mercado de trabalho: roadmap, entrevistas e portfólio
Objetivo: converter o conteúdo dos módulos em contratação — os cargos, um plano de estudo, um banco de perguntas e projetos que geram entrevista.
10.1 Onde essa habilidade pesa
- AI product designer: os fluxos e padrões dos recursos de IA de um produto.
- Design engineer: implementar os padrões (streaming, diff, agent steps) com performance e a11y.
- Conversation designer: a voz, os fluxos de diálogo, o tratamento de erro, o handoff.
- Design systems: os componentes de IA, os tokens, a governança e o UX writing.
- PM de IA: nível de automação, métricas, o que virar IA e o que não.
10.2 Roadmap de estudo (5–7 semanas)
| Semanas | Foco | Prática |
|---|---|---|
| 1 | Probabilístico, entrada, saída (Módulos 1–3) | Auditar 5 produtos de IA: mapear padrões de entrada/saída, streaming, fontes, erros |
| 2 | Confiança e erro (Módulo 4) | Redesenhar as mensagens de erro e a comunicação de incerteza de um recurso real |
| 3 | Human-in-the-loop (Módulo 5) | Especificar os níveis de automação de um agente, com preview/diff e pontos de aprovação |
| 4 | Latência, custo, conversa/agente (Módulos 6–7) | Prototipar a UI de um agente multi-etapa (plano, progresso, interromper, resumo) |
| 5 | Avaliação (Módulo 8) | Definir métricas e um roteiro de teste para um recurso; rodar 3 sessões |
| 6 | Ética, a11y, design system (Módulo 9) | Um mini kit de componentes de IA (PromptInput, ResponseStream, Citation, DiffPreview, AgentSteps) com UX writing |
| 7 | Portfólio | Publicar os estudos de caso com antes/depois e o raciocínio |
10.3 Banco de perguntas (com a resposta que aprova)
Júnior/pleno — "O que muda ao projetar para IA?"
O sistema é probabilístico: varia, erra, demora, custa e muda. Você projeta para o erro, não para o caso feliz — cada padrão (streaming, fontes, incerteza visível, preview, undo) existe para tornar os erros toleráveis e recuperáveis. E decide conscientemente quando não usar IA (resposta determinística com erro caro).
Pleno — "Como você resolve o 'blank page problem'?"
Não deixar o usuário sozinho com um campo vazio: sugestões contextuais, templates para tarefas comuns, chips de parâmetro (tom/tamanho/formato), e ações de IA no lugar onde fazem sentido (na seleção, no item) já com o contexto. Guiado por padrão, campo aberto disponível, e o guiado preenche o campo — ensinando a formular.
Pleno — "Por que e como fazer streaming da resposta?"
Reduz a latência percebida, deixa o usuário começar a avaliar antes do fim e permite cancelar (sem esperar nem pagar o resto). Token a token para conversa, por bloco quando a formatação importa, skeleton quando a estrutura é conhecida. Cuidar da acessibilidade (leitor de tela não lida bem com mudança letra a letra).
Pleno/sénior — "Descreva os níveis de automação e como escolher."
Sugerir → rascunhar → fazer com aprovação → fazer e avisar → autônomo. Escolhe-se por risco, confiança do sistema e reversibilidade, e varia por ação dentro do mesmo produto. Confirmação explícita para o destrutivo, custoso, externo ou difícil de reverter. Lançar no nível mais baixo que ainda é útil e subir com dados de aceitação/correção.
Sénior — "Como você comunica e calibra a confiança do usuário?"
O alvo é confiança calibrada, não máxima: mostrar fontes verificáveis, sinalizar baixa confiança quando há sinal (ícone + rótulo, não só cor), tratar fatos como "verifique" por padrão, ser honesto sobre limitações desde o início, e fazer o erro ser visível e barato de corrigir. Excesso de confiança deixa erro passar; desconfiança total mata a adoção.
Sénior — "Chat é a interface certa para IA?"
Nem sempre. Chat é bom para exploração aberta e follow-up; é ruim para tarefas repetíveis (relê tudo toda vez), ações precisas, descoberta de capacidades e quando o resultado precisa virar artefato. Muitos produtos combinam ações inline (para o comum), UI dedicada (tarefas nomeadas) e chat (o resto). "Tudo é chat" costuma ser falta de design.
Sénior — "Como você avalia a UX de um recurso não-determinístico?"
Métricas: aceitação, grau de edição da saída, taxa de regenerar/descartar, time to first useful output, abandono, retenção, fallback para humano — instrumentadas junto com o eval do modelo. Testes com roteiros por objetivo (não passos), mais sessões, observando a reação ao erro e se a confiança fica calibrada. Mais dogfooding e um "red team de UX" (o modelo errando feio na interface — o dano é limitado e reversível?).
Armadilha — "A demo funcionou, é só colocar um botão de gerar"
A demo é o caso feliz. Sem padrões para o erro (incerteza visível, fontes, preview, undo, mensagens de erro humanas), o custo e a latência na interface, o nível de automação certo, a acessibilidade do streaming e a disclosure, o recurso gera um incidente de confiança no primeiro erro real. Design de IA é 80% os casos não-felizes.
10.4 Projetos de portfólio que geram entrevista
- Redesign de um recurso de IA real (âncora): pegar um recurso de IA de um produto conhecido com UX fraca (blank page, sem fontes, erros crus, sem preview) e refazer os padrões, com antes/depois e o raciocínio.
- Kit de padrões de IA: PromptInput, ResponseStream, Citation, ConfidenceIndicator, DiffPreview, AgentSteps, ApprovalPrompt, DisclosureBadge — como uma página de design system, com estados e UX writing.
- Estudo de human-in-the-loop: um agente com os 5 níveis de automação mapeados por ação, preview/diff, aprovações e o plano de "subir a autonomia com dados".
- Estudo de latência/streaming: a mesma tarefa com espera opaca vs streaming + progresso por etapas + background + notificação, com o raciocínio de quando usar cada um.
- Teste de usuário documentado de um recurso não-determinístico, incluindo como as pessoas reagiram aos erros do modelo e o que mudou no design.
10.5 Fontes para continuar
- Padrões: Shape of AI (shapeof.ai) — biblioteca de padrões de UX de IA; a seção de IA do Nielsen Norman Group.
- Guidelines: People + AI Guidebook (Google PAIR); Microsoft HAX Toolkit (Human-AI eXperience) e as HAX Guidelines; Apple — Human Interface Guidelines: Machine Learning / Generative AI; IBM — Design for AI.
- Escrita e conversa: materiais de conversation design (Google, Conversations with Things); UX writing para IA.
- Implementação: os padrões de UI do Vercel AI SDK (streaming, tool calls, generative UI); estudos de caso de produtos (Notion AI, Linear, GitHub Copilot, Raycast, Arc).
- Nesta trilha: Design Systems & Design Tokens, Motion de Interface, Cor, Layout, Grade & Espaçamento, Iconografia, Acessibilidade Digital & WCAG; e Criação de Agentes de IA, MCP, IA Generativa & RAG, LLMOps & Avaliação de Sistemas de IA, IA de Voz e Áudio, Governança de IA, Ética & EU AI Act.
Cinco ideias sustentam o design de produtos com IA: (1) o material é probabilístico — projete para o erro, a latência e o custo, não para a demo; (2) entrada guiada (contra o blank page) e saída acionável com streaming, fontes e incerteza visível; (3) confiança calibrada — o erro precisa ser visível e barato de corrigir; (4) escolha o nível de automação por ação, com preview/diff, aprovação e undo, e suba com dados; (5) ética, acessibilidade e componentes de sistema — sem dark patterns, com disclosure, e os padrões viram um kit reutilizável.