AI BoutiqueAI Driven Transformation

Fundamentos

Lean UX para IA: trate cada feature como hipótese, não entrega

Lean UX trata feature como hipótese e não como entrega. Como aplicar o método de Gothelf e Seiden para colocar IA em produção sem apostar às cegas no roadmap.

A maioria dos projetos de IA que fracassam não fracassa por falta de tecnologia, fracassa por excesso de certeza. Alguém decidiu no PowerPoint que "um copiloto para o time de vendas" era a resposta, o time construiu por três meses e só no lançamento descobriu que ninguém usava. O Lean UX, método que Jeff Gothelf e Josh Seiden publicaram em 2013 no livro homônimo, existe para atacar exatamente esse padrão, e envelheceu tão bem que parece escrito para a era dos agentes.

A ideia central: da entrega ao resultado

O Lean UX nasceu de uma pergunta simples: por que times de produto medem sucesso pelo que entregam, e não pelo que muda no comportamento de quem usa? A resposta do método é reorganizar o trabalho em torno de três movimentos.

Primeiro, declarar suposições. Todo projeto nasce cheio de crenças não ditas: "o usuário confia numa resposta gerada por IA", "o time de atendimento vai revisar as sugestões antes de enviar", "o modelo entende o vocabulário do nosso setor". O Lean UX começa colocando essas crenças na mesa, por escrito, com o time inteiro presente, incluindo engenharia e negócio, não só design.

Segundo, transformar as suposições mais arriscadas em hipóteses testáveis, no formato que virou marca registrada do método: acreditamos que [este recurso] para [este público] vai gerar [este resultado]; saberemos que é verdade quando virmos [este sinal no mundo]. A frase parece burocrática até o dia em que ela impede o time de gastar um trimestre numa aposta que ninguém sabia justificar.

Terceiro, construir o mínimo que teste a hipótese. No Lean UX, MVP não é a primeira versão pequena do produto: é um instrumento de medição. Se a dúvida é "o gestor confia num resumo automático de reunião", o experimento pode ser um humano gerando os resumos por uma semana atrás de uma interface simples, antes de qualquer modelo entrar em cena.

Por que isso rende ainda mais com IA

Produto tradicional carrega um tipo de incerteza: será que as pessoas querem? Produto com IA carrega dois: além da incerteza de demanda, há a incerteza de capacidade. Ninguém sabe de antemão se o modelo atinge qualidade suficiente na sua tarefa, com os seus dados, no seu contexto. Como vimos no relato de Böckeler sobre modelos locais, nem os especialistas preveem o resultado sem testar: modelos idênticos entregaram qualidade diferente em máquinas diferentes.

O Lean UX lida bem com isso porque obriga a separar as hipóteses. Uma coisa é "acreditamos que o vendedor quer sugestões de resposta"; outra é "acreditamos que o modelo gera sugestões que o vendedor aprova em 80% dos casos". A primeira se testa com discovery e protótipo; a segunda, com uma avaliação sistemática rodando nos seus dados reais. Misturar as duas é a receita do piloto eterno: quando o projeto patina, ninguém sabe se o problema é demanda ou qualidade.

Requisito é certeza emprestada. Hipótese é honestidade com método.

Há um terceiro encaixe, mais sutil. O Lean UX prega o time colaborativo desde o rascunho, com designer, engenheiro e negócio declarando suposições juntos. Em IA isso deixa de ser boa prática e vira necessidade: a fronteira do que o modelo consegue fazer muda o que vale a pena desenhar, e só quem está com a mão na avaliação sabe onde essa fronteira está hoje.

Como aplicar: um roteiro curto

Na próxima iniciativa de IA do seu time, antes de escrever qualquer requisito, reserve duas horas para uma sessão de declaração de suposições com todas as funções presentes. Separe o que sair em dois montes: suposições de valor (alguém quer, alguém confia, alguém muda de comportamento) e suposições de capacidade (o modelo dá conta, o dado existe, a latência serve). Escolha a mais arriscada de cada monte e escreva as duas hipóteses no formato completo, com o sinal mensurável definido antes de construir.

Depois desenhe o menor experimento que responda cada uma. Para valor, protótipo, concierge ou mágico de Oz resolvem muito antes de plugar modelo. Para capacidade, monte uma avaliação com 30 a 50 casos reais e critérios de aprovação explícitos, na linha do que discutimos em OKRs para IA: medir resultado, não entrega. E encerre cada ciclo com a pergunta do método: o que aprendemos muda a próxima aposta?

Quem já usa Lean Startup na camada de negócio e Jobs to Be Done na descoberta vai notar que o Lean UX é a peça que conecta os dois ao trabalho da semana: é o ritual que transforma estratégia em experimento com data para dar resposta. Gothelf, aliás, segue defendendo o mesmo princípio na era da IA: priorize pelo que você aprende, não pelo que você entrega.

O crédito é inegociável: o método é de Jeff Gothelf e Josh Seiden, e o livro Lean UX (O'Reilly, terceira edição em 2021) continua sendo a fonte primária que vale ler inteira.

Se o seu roadmap de IA está cheio de certezas e vazio de hipóteses, chame a gente no WhatsApp que a gente ajuda a transformar as apostas do seu time em experimentos com resposta rápida.

Perguntas frequentes

O que é Lean UX?

Um método criado por Jeff Gothelf e Josh Seiden que aplica o pensamento lean ao design de produto: o time declara suposições, transforma em hipóteses testáveis, constrói o mínimo para testar e mede resultado em comportamento do usuário, não em entrega de feature.

Como escrever uma hipótese de Lean UX para uma feature de IA?

Use o formato: acreditamos que [este recurso] para [este público] vai gerar [este resultado]. Saberemos que é verdade quando virmos [este sinal mensurável]. Para IA, acrescente uma hipótese técnica: acreditamos que o modelo atinge [qualidade mínima] nesta tarefa, medida por [avaliação].

Qual a diferença entre Lean UX e Lean Startup?

Lean Startup opera no nível do negócio e do produto inteiro; Lean UX aplica a mesma lógica de construir, medir e aprender ao trabalho cotidiano de design e discovery do time. Os dois se complementam.

← Todos os artigos