Beavrly

De um chat vencedor a uma plataforma completa de estimativas

Atuei como UX/UI designer do time na primeira versão, durante o hackathon HackathOrion, ajudando a criar os fluxos e interfaces. Após a premiação (1º lugar), assumi o projeto individualmente como estudo de caso, responsável por toda a pesquisa (desk research, comunidade, questionário e entrevista), análise competitiva, redefinição do fluxo de UX, design de interface e condução dos testes de usabilidade.

Setor

Produto Digital

Período

2025

Ferramenta

Figma, Maze

Atuação

Product Designer e UX Researcher

Setor

Produto Digital

Período

2025

Ferramenta

Figma, Maze

Atuação

Product Designer e UX Researcher

Da ideia vencedora ao estudo de caso real

Beavrly nasceu em um hackathon. A primeira versão funcionava como um chat de IA que, com base em documentos e na composição do time, gerava estimativas. A ferramenta venceu o primeiro lugar na competição.

Apesar da validação inicial, o produto era um MVP usado apenas internamente, sem contato com o mercado real. No final de 2025, retomei o projeto para transformá-lo em uma solução verdadeiramente utilizável. Meu objetivo era evoluir de um chat engessado para uma plataforma não linear de apoio contínuo ao planejamento.

O calcanhar de Aquiles de quem vende projetos

Profissionais que criam produtos digitais, como Product Managers, Tech Leads, Designers e Freelancers, enfrentam enorme dificuldade para estimar prazos e custos de forma confiável. As propostas são feitas manualmente, o que atrasa respostas para clientes e interfere no fechamento de negócios.

A versão original da Beavrly, embora funcional, era linear e pouco transparente. O usuário não conseguia visualizar como a IA chegava aos resultados, o que gerava desconfiança e limitava a adoção da ferramenta. O desafio era claro: dar flexibilidade, profundidade e clareza ao processo de estimativa.

Pesquisando para entender a dor real

Antes de redesenhar qualquer interface, mergulhei em uma etapa enxuta de product discovery. Por se tratar de um projeto de estudo com tempo limitado, priorizei coletar evidências rápidas e acionáveis para embasar as decisões de design, em vez de produzir um relatório acadêmico extenso.

A pesquisa se desdobrou em quatro frentes complementares:

Estudo teórico sobre estimativas
Analisei artigos e metodologias sobre estimativas baseadas em esforço, complexidade e histórico. Esse estudo me deu base para planejar as perguntas certas e entender as variáveis que impactam prazos, como escopo, riscos e maturidade do time.

Pesquisa em comunidades de tecnologia
Publiquei perguntas abertas em comunidades ativas no Reddit, Facebook e Discord. Recebi 15 respostas qualitativas riquíssimas que revelaram padrões claros:

  • Aceitação da imprecisão: "estimativa pressupõe imprecisão". O produto não poderia vender a ideia de precisão milagrosa, e sim uma gestão inteligente da incerteza;

  • Faixa de datas, não data fixa: toda estimativa deve ser um intervalo, nunca um único prazo fechado;

  • Dependência de dados históricos: a experiência passada é a âncora mais forte para prever o futuro;

  • A dor é a comunicação: o problema não é errar, é o cliente confundir estimativa com clarividência. O produto precisava gerar relatórios que educassem o cliente;

  • Escopo mal definido: a raiz de todos os erros. A ferramenta deveria ajudar o usuário a fazer as perguntas certas antes de calcular.

Questionário estruturado
Apliquei um questionário para validar os achados. Confirmou-se a dor do escopo mutável e a resistência ao uso de IA que "chuta prazos". A IA deveria focar em clareza e análise de escopo, não em adivinhação.

Entrevista em profundidade
Conversei com um UX/UI Designer experiente da comunidade. Numa conversa aberta e prática, ele mostrou as ferramentas que usa no dia a dia, como o NotebookLM, e executamos juntos a estimativa de um projeto fictício. Foi essa conversa que me apresentou o modelo de interface contextual que viria a inspirar o redesign.

Mapeando a concorrência
Mapeei três ferramentas de estimativa com IA para identificar lacunas reais de mercado: Appcost, CostGPT e Idealink.

A Appcost tem uma proposta visualmente clara e bem estruturada, com timeline automática e custo por funcionalidade, mas o fluxo é rígido: não dá para editar o escopo sem reiniciar a estimativa, e o chat só aceita texto, sem upload de arquivos.

A CostGPT vai além da estimativa e também gera sitemap, user stories e casos de teste, um diferencial real. Mas não salva login, perfil ou parâmetros: cada nova estimativa começa do zero, e o cadastro obrigatório de contato é uma fricção antes mesmo de ver o resultado.

A Idealink tem o fluxo mais engessado dos três: sete passos fixos, com uma única janela de chat no meio do caminho, e nenhum campo para descrever a composição do time além de um campo opcional no final.

Os três padrões que se repetiam confirmaram exatamente a direção que a pesquisa com a comunidade já tinha apontado: nenhum concorrente aceita documentos como contexto, só texto digitado; nenhum salva preferências entre estimativas; e nenhum trata a composição do time como parâmetro central desde o início. Isso validou que a Beavrly podia se diferenciar sendo não linear, aceitando múltiplos documentos de contexto e servindo como ponto de partida para gerar não apenas a estimativa, mas também um documento de requisitos e um fluxograma.

Do chat linear para uma plataforma adaptável

Com os insumos da pesquisa, mudei o paradigma do produto. O fluxo antigo era um caminho sem volta: você inseria dados no chat e recebia um documento no final.

Inspirado no funcionamento do NotebookLM, que opera em um contexto fechado com os arquivos do usuário, desenhei um novo conceito de interface em três colunas:

  • Coluna esquerda: contextos e critérios do projeto;

  • Coluna central: o chat com a IA;

  • Coluna direita: as ferramentas e materiais gerados (fluxograma, requisitos).

Essa estrutura quebrava a linearidade. O usuário poderia adicionar um documento, ver como isso impactava os critérios e acessar o fluxograma a qualquer momento, adaptando a ferramenta às mudanças do projeto.

Desenhando e testando a experiência

A nova interface materializou a estratégia. Abandonei o formato puramente conversacional e criei um espaço de trabalho onde a IA atua como copiloto, não como oráculo.

Para validar, configurei um teste de usabilidade não assistido utilizando a ferramenta Maze, integrada ao protótipo do Figma. O foco era testar o fluxo básico: onboarding, upload de arquivos e critérios, e a geração da dashboard de estimativas.

Resultados do teste:

  • Sucesso de conclusão: 100% dos participantes concluíram o fluxo, o que validou a estrutura principal da navegação;

  • Tempo médio: 7 minutos, um pouco acima da meta ideal de 5 minutos;

  • Taxa de erros de clique: 51,7%. Apesar de parecer alto, o número foi relativizado por se tratar de um protótipo com poucas áreas interativas;

  • Mapas de calor: mostraram que os erros de clique estavam concentrados nos botões de ação pouco destacados e na tentativa de interagir com áreas ainda não prototipadas.

Ajustes identificados no feedback:

  • Hierarquia: desativar ferramentas antes dos contextos serem adicionados e dar mais destaque ao botão de upload no primeiro acesso;

  • Nomenclatura: trocar a repetição da palavra "contexto" por "Seus Arquivos" para evitar confusão semântica;

  • Visualização de dados: exibir os três cenários da dashboard lado a lado, eliminando o slider e dando mais peso visual aos títulos.

O projeto está pausado nesse ponto atualmente. A intenção é seguir evoluindo a Beavrly como projeto de estudo, incorporando os ajustes identificados no teste nas próximas iterações.

O resultado

A Beavrly já nasceu validada: a primeira versão venceu o primeiro lugar no hackathon HackathOrion, com premiação de R$3 mil, uma validação externa e independente antes mesmo de eu assumir o redesenho.

A segunda validação veio do teste de usabilidade do novo fluxo: 100% dos participantes concluíram a tarefa proposta, confirmando que a estrutura de navegação em três colunas fazia sentido para quem nunca tinha visto a ferramenta antes. O tempo médio de 7 minutos ficou acima da meta de 5, e a taxa de erro de clique de 51,7% chama atenção à primeira vista, mas os mapas de calor mostraram que os erros se concentravam em botões pouco destacados e em áreas ainda não prototipadas, não em falhas de arquitetura da informação.

O projeto está pausado nesse ponto atualmente. A intenção é seguir evoluindo a Beavrly como projeto de estudo, incorporando os ajustes identificados no teste nas próximas iterações.

O que aprendi no processo

Esse projeto consolidou minha visão sobre design de produtos com IA. Um bom produto de IA não precisa parecer um chat para ser inteligente; muitas vezes, clareza e previsibilidade valem mais do que a complexidade do modelo.

Aprendi, na prática, a importância de relativizar métricas de usabilidade. Uma taxa de cliques errados alta em um protótipo de baixa fidelidade pode indicar falta de affordance (destaque visual), não necessariamente um problema de arquitetura. A leitura dos mapas de calor e o feedback qualitativo foram essenciais para separar ruído de insight.

Por fim, a experiência de conduzir um processo completo de design, da pesquisa à validação, reforçou que o sucesso de uma estimativa não está em acertar o prazo, mas em gerenciar a incerteza com transparência.