Fluera

Produto · 10 de abril de 2026

Como aparecem as 'dificuldades desejáveis' dentro de um app

O framework de Bjork é a espinha dorsal do Fluera. Eis como um achado de pesquisa contraintuitivo vira decisões de design concretas — e quais são os trade-offs mais duros.

Por Lorenzo

Quando apresentamos o Fluera a observadores céticos, a ideia única que mais trabalha é as dificuldades desejáveis de Robert Bjork [Bjork, 1994] Bjork (1994) View in bibliography → . Uma vez que as pessoas absorvem que as condições de estudo mais fáceis quase sempre produzem resultados piores, o restante das nossas decisões de design para de parecer estranho e começa a parecer inevitável.

Mas “inevitável” está fazendo muito trabalho aí. Transformar um achado de pesquisa em uma interface de produto envolve trade-offs que não aparecem nas meta-análises. Eis um balanço parcial.

O canvas em branco

O app de estudo padrão tem um template. Você abre e há uma estrutura sugerida — um esqueleto de mind-map, uma lista de tópicos, um layout Cornell. O template baixa a energia de ativação. Parece útil.

Não é. Um template te deixa pular o passo de geração — o ato cognitivo de decidir o que pertence onde, o que se conecta a quê, qual é o conceito central. O passo de geração é a aprendizagem. Pular é pular a razão de ter o caderno.

O canvas do Fluera está em branco. Infinito, vazio, não intimidador. O custo é que novos usuários sentem o atrito imediatamente. Alguns vão embora. A gente aceita. A alternativa é uma ferramenta que atrai mais usuários e ensina a menos.

A IA que pergunta, não responde

Cada sessão de user research que fizemos incluiu pelo menos uma pessoa dizendo “seria útil se a IA pudesse me escrever um resumo”. Toda sessão sem exceção.

Eles têm razão de que seria útil. Erram em achar que a utilidade é o objetivo. Uma IA que te resume a aula é uma IA que cuida da parte do aprendizado que era seu trabalho. Você ganha um resumo. Sente que estudou. Não lembra de nada.

O Socratic Mode existe especificamente para não fazer a coisa que os usuários pedem. Interroga o canvas em vez de resumi-lo. No eixo da satisfação imediata, na primeira interação, ele perde para uma IA que explica. No eixo da retenção semanas depois [Roediger e Karpicke, 2006] Roediger e Karpicke (2006) View in bibliography → , vence por margens que fazem a preferência de curto prazo parecer insignificante.

O trade-off é real. Alguns usuários nunca cruzam o limiar. Para os que cruzam, a diferença é o produto.

O slider de confiança

Você terminou de escrever uma resposta. Toca “revelar a solução”. O Fluera te pede uma última coisa antes: avalie sua confiança, de 1 a 5.

É uma pequena interrupção. A cada trial soma dois ou três segundos. Ao longo de uma sessão, esses segundos se acumulam. Os usuários pedem para desligar.

O slider é estrutural. O efeito de hipercorreção de Butterfield e Metcalfe [Butterfield e Metcalfe, 2001] Butterfield e Metcalfe (2001) View in bibliography → — os erros cometidos com alta confiança, uma vez corrigidos, fixam mais do que erros com baixa confiança — exige que você tenha nomeado sua confiança antes da correção chegar. Sem o slider, você corrige na névoa e a correção desbota. Com o slider, o contraste fica explícito e a correção pousa.

A gente mantém o slider. O incômodo é o mecanismo.

Fog of War para preparação de prova

A maneira óbvia de se preparar para uma prova é reler os apuntes. A fluência aumenta. A preparação percebida aumenta. No dia da prova, o desempenho desaba — porque reconhecimento não é recuperação, e a prova pede recuperação.

Fog of War inverte a interação. No modo prova, o Fluera esconde o seu canvas — mascara as regiões que você já cobriu e te pede para recuperá-las da memória antes de revelar. A primeira sessão é terrível. Você fica diante de um canvas enevoado e descobre o quanto do que achava que sabia não consegue produzir.

Os usuários odeiam a primeira sessão. Adoram os resultados na prova. O atrito da primeira sessão é o que torna esses resultados possíveis.

O que não fazemos (e nos desculpamos por não fazer)

A evidência também sustenta algumas intervenções que não construímos. O interleaving — randomizar a ordem dos tópicos durante a prática em vez de praticar em blocos [Rohrer e Taylor, 2007] Rohrer e Taylor (2007) — é robustamente demonstrado para melhorar a transferência. Queremos construir funções de interleaving mais profundas. O obstáculo é que a sensação de produto de uma ordem de tópicos aleatória, sem design cuidadoso, pode ser profundamente desorientadora. A experiência do usuário desaba antes que o benefício cognitivo entre em jogo.

Gerenciar esse trade-off — preservar o flow enquanto se introduz atrito desejável — é o problema de design mais duro que temos.

O padrão

O padrão que atravessa todas essas decisões é: a preferência imediata do usuário é um sinal sistematicamente enganoso. Os usuários preferem a versão fácil. A versão fácil é pior. Construir a versão mais difícil costuma ser premiado depois — pela retenção, pelos resultados de prova, pelo raro usuário que volta e diz “achei vocês loucos, agora entendo”. Mas quase sempre é punido antes — pelo churn, pelas avaliações ruins, pela tentação de lançar a versão mais fácil na próxima.

A gente tenta resistir a essa tentação. Às vezes falha. Lança e recua e lança de novo.

A aposta é que, num campo — ed-tech — em que cada concorrente se rendeu à preferência do usuário e construiu ferramentas que dão sensação boa e ensinam pouco, há espaço para uma ferramenta pior na sensação e melhor no ensino.

Se você quer ajudar a gente a descobrir, a beta está aberta.