Hedgehog · Prediction market

Visão geral

Uma aposta de cinco minutos, não uma mesa de operações.

A Hedgehog é um prediction market. As pessoas escolhem se um preço sobe ou desce.

A categoria já tinha demanda. Polymarket, Augur e uma leva de produtos DeFi já tinham provado isso. O que não tinha escalado era quem conseguia entrar.

O loop que foi para produção: escolher um lado, esperar a rodada, ver o resultado e ficar para a próxima.

Problema

O interesse morria na mecânica, não na ideia.

As plataformas existentes pediam familiaridade com orderbook, liquidez e mecânica de trade antes de uma única previsão.

Esse sistema foi feito para profissionais de mercado. Para todo o resto, o primeiro meio minuto bastava para sair.

Interfaces da categoria construídas em torno da mecânica de trade — O padrão da categoria: muita estrutura de mercado antes da decisão em si.

Oportunidade

Dois públicos, e desenhar só para um perderia o outro.

Quem chegava curioso já tinha ouvido falar de prediction markets e saía se a orientação passasse de uns 30 segundos.

Quem já usava DeFi queria ciclos curtos, não uma posição para administrar por dias, e saía quando o produto parecia raso.

A oportunidade era um modelo de participação legível para o primeiro grupo e rápido o bastante para o segundo.

Solução

Deposite num pool. Escolha UP ou DOWN.

Trocamos o orderbook por um pool compartilhado. A decisão é binária. Não há contraparte para encontrar nem uma aula de liquidez antes da primeira ação.

Desktop e mobile foram desenhados juntos. Cada estado foi feito para os dois.

Decisão UP ou DOWN na Hedgehog — A ideia principal, na tela em que ela importa.

Experiência central

Quatro momentos que tornam o loop compreensível.

Uma rodada com começo e fim.

Três minutos para escolher valor e direção. A sala trava. Dois minutos resolvem o resultado. O ciclo inteiro dura cerca de cinco minutos: curto o bastante para repetir, contido o bastante para reduzir a ansiedade da espera.

Timer da rodada e estados dos modais — Preparação, trava e resolução como estados distintos.

Uma ação mais alta que o resto.

UP ou DOWN é o elemento mais forte da tela. Valor e confirmação ficam secundários, então a interface responde uma pergunta no momento que importa.

UP e DOWN como ações dominantes — A decisão é visualmente mais alta do que a preparação ao redor.

As apostas das outras pessoas, à vista.

A distribuição do pool é pública, inclusive uma tabela do que cada participante escolheu. Quem chega novo ganha prova social. Quem já opera ganha um sinal contrário. Nos dois casos, a decisão fica dentro do produto.

Dados públicos de participação — A participação faz parte da interface, não de um campo escondido no backend.

O resultado te manda para a próxima rodada.

Vitória ou derrota aparece num modal. Você confirma e continua na mesma tela, pronto para a próxima rodada. O pico emocional alimenta a ação seguinte em vez de encerrar a sessão.

Estados de vitória e derrota — A resolução é um tempo do loop, não um beco sem saída.

Aprendizados

O orderbook já era a barreira antes de existir protótipo.

Fiz benchmark de seis produtos: Polymarket, Augur, Drift Protocol, Binance Predictions, Azuro e Limitless. O ponto era ver onde as pessoas travavam, não colecionar telas.

Mais dados no momento da decisão aumentavam a hesitação. Um retorno fraco deixava a pessoa sem saber o que a própria previsão tinha feito. Ciclos curtos criavam hábito. Ciclos longos, presos a eventos externos, não.

Por isso, evitar o orderbook foi uma restrição de partida, não um pivô depois de um protótipo que falhou.

Decisões

Três escolhas que mudaram o produto, não só os pixels.

Muda o modelo, depois desenha a tela.

Polir um orderbook deixaria a ferramenta de quem opera mais bonita. Não faria alguém novo entrar. Assumimos o pool como o produto, e a interface veio depois.

Mostrar a multidão, com cuidado.

Esconder o que os outros faziam ignorava como as pessoas de fato decidem. Publicar o pool deu uma pista para quem chega e algo para discordar para quem já opera, sem transformar a tela num ranking.

Adicionar conversa onde as pessoas ainda congelavam.

O chat ao vivo não estava no lançamento original. No beta fechado, algumas pessoas ainda hesitavam no lado mesmo depois de entender a mecânica. O chat abriu para quem tinha uma previsão ativa naquela rodada, e a escolha deixou de acontecer no vazio.

Como a mecânica é explicada no produto — O fluxo precisava se explicar. A landing page já tinha feito parte desse ensino.

Resultados

Um beta fechado, com gente que já queria entrar.

Não houve A/B de laboratório. Por cinco dias, cinco grupos de 20 pessoas da própria waitlist usaram o produto em produção. Cem pessoas, com intenção real.

Mais da metade já entendia o propósito antes de entrar, por causa da landing page. Com um fluxo que se explica, todo mundo entendeu a mecânica até a segunda rodada. Ganhos e perdas individuais variaram, e isso nunca foi o critério de sucesso.

100%Entenderam a mecânica até a segunda rodada

10s → 2–4sTempo até a primeira ação

120+Componentes no design system, com cerca de 35% a menos de tempo de handoff

Quem fundou o produto e acompanhou o beta descreveu o mesmo que as pessoas usuárias: intuitivo, claro e fiel à promessa. A conversão de 37,5% da waitlist pertence à página de pré-lançamento, não a este beta.

Hedgehog no mobile — O mesmo loop no celular, que estava no escopo desde o início.

Reflexão

Quando as pessoas estão confusas, conserta o modelo antes da interface.

A gente não saiu de um orderbook polindo tela. Trocamos o modelo e desenhamos o loop em volta dele.

A pergunta em aberto é a janela de três minutos de preparação, quando alguém escolhe valor e direção sozinho, antes da sala travar. É ali que quem chega tem mais chance de travar. O próximo passo útil é orientação na criação da sala, antes da trava, que é para onde o chat do beta já apontava.