
Threshold de Doherty pode guiar interfaces de IA que parecem mais rápidas
A tese: o threshold de Doherty não morreu, mudou de lugar
Em artigos de UX, a maioria das equipes justifica a lentidão de produtos de IA com explicações técnicas - "o modelo leva oito segundos", "inferência é cara". Segundo o autor, essa leitura erra ao supor que o limiar de 400 milissegundos de resposta, estabelecido por Walter Doherty e Ahrvind Thadani em 1982, teria sido aposentado pela IA generativa. O que aconteceu, na verdade, é uma reescrita do que o limiar rege: a interação generativa foi dividida em dois eventos - o reconhecimento (o sistema provou que ouviu) e a resposta (a resposta em si é boa?) - e o limiar de 400 ms migrou para o reconhecimento, do lado da interface, não do modelo.
O autor destaca que o paper original, "The Economic Value of Rapid Response Time", era antes de tudo um argumento econômico: abaixo de ~400 ms, a produtividade subia mais rápido do que o tempo economizado explicava, porque as pessoas param de agrupar o pensamento ao redor das pausas e mantêm um único fio de raciocínio. O limiar nunca mediu a velocidade da máquina, mas quanto tempo uma pessoa segura um pensamento. E ele já foi revalidado desde então: o estudo da Deloitte Digital "Milliseconds Make Millions" (2020) mostrou que 0,1 segundo de melhoria elevou conversões em 8,4% em 37 marcas; pesquisa sobre turnos de conversa encontrou intervalo mediano de ~100 ms entre falas; e Jakob Nielsen reformulou os mesmos limites para a web (0,1 s parece instantâneo, 1 s mantém o fluxo, 10 s é o limite da atenção).
Dois relógios, dois orçamentos
O artigo propõe que toda interação de IA rode dois relógios. O relógio um começa quando o usuário se compromete (enter, clique, toque) e termina quando a interface prova que ouviu - ecoar o prompt no thread, mudar o botão, mostrar o esqueleto. Meta de 100 ms, teto de 400 ms; é trabalho de front-end, sem dependência de inferência. O relógio dois começa quando o pedido sai e termina quando a resposta está utilizável; aqui as pessoas esperam, às vezes muito, desde que haja um retorno que compense. O que quebra não é a duração, é o silêncio: a regra deste relógio é honestidade, não velocidade, com estados reais, cancelamento disponível e rollback verdadeiro em atualizações otimistas.
A confusão típica é ler métricas como o tempo até o primeiro token, reportado pela Artificial Analysis em segundos para modelos de raciocínio, e tratar uma medida do modelo como medida da interface. O modelo pode levar oito segundos; o instante após o envio não. O autor observa que o Google já aplica uma régua mais dura ao clique: a métrica Interaction to Next Paint considera bom o padrão de até 200 ms no 75º percentil.
Por que a latência virou orçamento de supervisão
A aposta mudou de natureza. Em 1982, resposta lenta custava throughput; em um produto de IA, custa supervisão - todo recurso de IA assume que há alguém atento o bastante para pegar o modelo errando, e é exatamente isso que o limiar protege. Streaming não resolve: transformar espera em leitura não faz nada pelo meio segundo em que não há nada para mostrar. E animações que simulam progresso compram paciência com afirmação falsa - usuários perdoam lentidão, não serem gerenciados.
Em agentes, o problema se multiplica: uma execução com várias chamadas de modelo e ferramentas herda o problema a cada salto. No exemplo de um agente de revisão de contratos (extrair cláusulas, comparar com o playbook, sinalizar lacunas, rascunhar redlines), um único spinner esconde em qual etapa o documento errado foi pego - o usuário descobre no fim. Com telemetria da Microsoft de 2025 mostrando o usuário médio de Microsoft 365 recebendo 117 e-mails e 153 mensagens de Teams por dia útil, com interrupção a cada dois minutos, atrasos de reconhecimento se multiplicam pela fila de trabalho do usuário corporativo. Quem sai da aba volta para aceitar o resultado, não para revisá-lo: o humano no loop vira carimbo, e o produto se redesenha para notificações e históricos que ninguém escopou.
Ações propostas
O artigo fecha com um plano: dividir o orçamento no documento de especificação, com um responsável por cada número; ecoar sempre o input antes de qualquer requisição; substituir animações de "pensando" por estados reais; medir a latência do primeiro toque em dispositivos reais, como se faz com Interaction to Next Paint; dar a toda espera uma saída (cancelar, editar, recomeçar) e uma justificativa; e auditar agentes salto a salto antes de investir em inferência mais rápida. A conclusão: a linha de 400 ms é o número de performance mais útil do design de interfaces porque é atingível hoje, sem mexer no modelo - a latência do modelo é problema do fornecedor; os primeiros 400 milissegundos são da equipe.