Ir para o conteúdo 
Resposta direta: um Discovery na prática começa com kick-off e alinhamento de expectativas, avança por entrevistas com usuários e stakeholders, análise de dados de uso e análise heurística, e fecha com workshop de alinhamento e priorização de backlog. Cada etapa produz um entregável concreto. Nenhuma tela é desenhada antes de o risco do projeto estar mapeado.
A maioria dos projetos digitais não quebra no código. Quebra antes, na decisão de construir a coisa errada. O Discovery existe para matar esse risco enquanto ele ainda custa reunião, não sprint.
Este artigo não é uma definição teórica. É o bastidor: o que acontece, dia a dia, nas primeiras semanas de um Discovery estratégico, o que se produz em cada etapa e por que nenhum wireframe aparece antes disso.
Antes do dia 1: o que precisa estar na mesa
Um Discovery sério não começa com uma reunião simpática. Começa com lição de casa dos dois lados.
Antes do kick-off, o time de consultoria pede:
- Acesso aos dados de analytics e de comportamento (GA4, mapas de calor, gravação de sessão)
- Documentação existente do produto: fluxos, backlog, decisões anteriores
- Lista de stakeholders e de clientes disponíveis para entrevista
- Metas de negócio do trimestre e do ano, em número, não em adjetivo
Se a empresa não tem dado nenhum, isso já é um achado. Operar um Ativo Digital sem medição é operar no escuro, e o Discovery vai precisar gerar essa base antes de qualquer conclusão.
Semana 1: kick-off e o mapa do problema
Dia 1 e 2: kick-off e alinhamento de contexto
O kick-off não é apresentação de slides. É uma sessão de trabalho com as pessoas que decidem: CEO ou CTO, head de produto, alguém do comercial ou do atendimento, alguém da tecnologia.
O objetivo é um só: fazer as visões conflitantes aparecerem agora, na sala, e não no meio do desenvolvimento, quando cada mudança de rota queima orçamento.
Perguntas típicas dessa sessão:
- Qual métrica de negócio esse projeto precisa mover? Receita, churn, custo de operação, CAC?
- O que acontece se nada for feito nos próximos 12 meses?
- Onde o time interno acha que está o problema? E onde o dado diz que está?
O que se produz: um documento de contexto com hipóteses declaradas, metas numéricas e a lista do que cada área acredita ser o problema. Esse documento vira a régua de tudo que vem depois. Nove entre dez vezes, as hipóteses da diretoria e as do time de operação não batem. Registrar essa diferença no dia 2 é barato. Descobrir ela no mês 4 de desenvolvimento é Dívida Técnica com juros.
Dia 3 a 5: dados de uso e análise heurística
Enquanto as entrevistas são agendadas, o time mergulha no que o produto já conta sozinho.
Análise de dados de uso. Funis de conversão, páginas de maior abandono, fluxos que os usuários realmente percorrem contra os fluxos que o time imaginou. Mapas de calor e gravações de sessão mostram onde o usuário hesita, clica em coisa que não é clicável, volta, desiste. Cada um desses pontos é um Custo Invisível: perda financeira que não aparece em relatório nenhum, mas aparece no faturamento.
Análise heurística. Avaliação estruturada da interface contra princípios consolidados de usabilidade, tela a tela, fluxo a fluxo. Não é opinião de designer. É checklist técnico com severidade classificada: o que bloqueia conversão, o que gera suporte, o que só incomoda.
O que se produz: um mapa de fricção do produto atual, com cada problema classificado por severidade e por impacto provável no negócio. Esse mapa ainda não é a verdade final. É a lista de suspeitos que as entrevistas vão confirmar ou derrubar.
Semana 2: as pessoas entram em cena
Entrevistas com usuários e stakeholders
Aqui mora o coração do Discovery, e é a etapa que mais empresa pula por achar cara. É o contrário: é a etapa mais barata de todo o ciclo de produto, porque cada hora de entrevista evita semanas de desenvolvimento na direção errada.
O formato típico:
- Entrevistas individuais de 45 a 60 minutos, roteiro semiestruturado
- Mix de perfis: clientes ativos, clientes que cancelaram, usuários internos, time de vendas e de suporte
- Foco em comportamento real, não em opinião: "me mostra como você fez isso da última vez" vale dez vezes mais que "o que você acha disso"
Quem quiser entender a mecânica dessa etapa em profundidade pode ler sobre como entender o comportamento do usuário com pesquisas UX. O ponto central: a pergunta certa não é "o que você quer no produto", é "o que te impede de resolver o seu problema hoje".
Pegue um cenário concreto de como isso se paga. Uma plataforma B2B chega com um backlog de 14 funcionalidades novas, estimadas em 9 meses de desenvolvimento. Uma semana de entrevistas com 12 clientes revela que 3 das funcionalidades mais caras do backlog atacam um problema que os usuários já resolvem bem fora do sistema, e que o abandono real está num fluxo de cadastro que ninguém do time interno considerava prioridade. Resultado da priorização: o backlog cai de 14 para 8 itens, o cronograma cai de 9 para 5 meses, e o item número 1 nem estava na lista original. Isso é Eficiência de Capital em estado bruto: o mesmo orçamento comprando o dobro de resultado.
O que se produz: sínteses de entrevista com padrões recorrentes, dores priorizadas por frequência e por impacto, e insumo direto para personas baseadas em evidência, não em achismo de sala de reunião. O processo de transformar isso em perfis acionáveis está detalhado no guia para criar personas com pesquisa UX.
Testes de usabilidade sobre o produto atual
Quando já existe produto no ar, uma rodada de testes de usabilidade com tarefas reais fecha o triângulo: o dado quantitativo diz onde o problema está, a entrevista diz por que ele existe, o teste mostra o problema acontecendo ao vivo. Ver um usuário travar três vezes no mesmo campo convence uma diretoria mais rápido que qualquer relatório.
Semana 3: do diagnóstico à decisão
Workshop de alinhamento
Todo o material volta para a sala com os decisores: mapa de fricção, sínteses de entrevista, achados dos testes. O workshop não é apresentação de resultados. É sessão de decisão.
O formato que funciona:
- Achados apresentados com evidência, nunca com opinião solta
- Cada achado conectado a uma métrica de negócio: isso custa conversão, isso custa retenção, isso custa horas de suporte
- Confronto explícito entre as hipóteses do kick-off e o que a evidência mostrou
É aqui que o Discovery paga a conta politicamente. Quando a evidência está na mesa, a discussão deixa de ser "a visão do CEO contra a visão do head de produto" e vira "o que o dado sustenta". Times que passam por isso saem alinhados de um jeito que nenhum documento compartilhado no Slack consegue produzir.
Priorização de backlog e roadmap
A última etapa transforma diagnóstico em plano. Cada iniciativa candidata é avaliada em dois eixos: impacto esperado no negócio e esforço de implementação. O que é alto impacto e baixo esforço entra primeiro. O que é baixo impacto e alto esforço morre, e morrer no papel é a morte mais barata que uma funcionalidade pode ter.
O que se produz no fechamento do Discovery:
- Diagnóstico consolidado com evidências, não opiniões
- Personas e jornadas baseadas em pesquisa real
- Mapa de fricção priorizado por impacto financeiro
- Backlog priorizado e roadmap com sequência de ataque
- Riscos mapeados: técnicos, de mercado e de adoção
Só depois disso alguém abre uma ferramenta de design. E quando abre, desenha com direção, não com esperança. Esse encadeamento entre diagnóstico, design e desenvolvimento está descrito na metodologia completa de UX orientada a resultado.
O Nielsen Norman Group, referência mundial em pesquisa de usabilidade, descreve a fase de discovery exatamente assim: o trabalho de entender o problema certo antes de comprometer recursos com uma solução, como detalha o artigo do NN/g sobre discovery.
Perguntas frequentes sobre Discovery na prática
Quanto tempo dura um Discovery?
Depende do escopo: complexidade do produto, quantidade de stakeholders, acesso a usuários e volume de dado existente. Um produto único com usuários acessíveis anda rápido. Uma operação com sistemas legados e múltiplas áreas exige mais imersão. O que não muda é a lógica: o tempo investido aqui é uma fração do tempo que se perde construindo a coisa errada.
Discovery serve só para produto novo?
Não. Produtos em operação são candidatos ainda melhores, porque já geram dado real de comportamento. Redesigns, migrações de sistema legado, quedas de conversão sem causa aparente e produtos com suporte sobrecarregado são cenários clássicos onde o Discovery encontra os Custos Invisíveis mais gordos.
Minha equipe precisa participar?
Precisa, e isso é parte do valor. Decisores participam do kick-off, do workshop e da priorização. Times de vendas e suporte entram como fonte de entrevista. Discovery feito em caixa preta, entregue em PDF sem envolvimento de ninguém, produz relatório de gaveta. Discovery feito com o time produz decisão.
O que impede o Discovery de virar só um relatório bonito?
A amarração financeira. Cada achado precisa apontar para uma métrica: conversão, churn, CAC, custo de operação. E a priorização final precisa virar roadmap com dono e sequência. Diagnóstico sem plano de ataque é custo. Diagnóstico com backlog priorizado é ativo.
Conclusão: o risco se paga antes ou se cobra depois
O Discovery na prática é isso: duas a poucas semanas de trabalho estruturado, kick-off, dado, entrevista, heurística, workshop, priorização, cada etapa com entregável concreto, tudo antes da primeira tela. Não é burocracia de consultoria. É a diferença entre investir orçamento com evidência ou apostar orçamento com opinião.
Os números do mercado são brutais com quem pula essa fase: 88% dos usuários não voltam depois de uma experiência ruim, e a dívida técnica de decisões mal fundadas consome até 40% do orçamento de TI. Do outro lado, o retorno médio de UX bem investido chega a 100:1. O risco do seu projeto vai ser pago de um jeito ou de outro. A única escolha é se você paga barato agora, em pesquisa, ou caro depois, em retrabalho.
Se o seu produto está nesse ponto, com visões conflitantes internas, backlog inchado ou uma decisão grande de investimento pela frente, um Discovery estratégico é o caminho de menor risco para decidir com evidência. Fale com a UX Agency e traga o seu cenário.
