WEB3 · PRODUCT DESIGN B2B

De 20 minutos cruzando dados a 30 segundos para decidir

CLIENTETransparent.space
MEU PAPELFounding Product Designer
PERÍODO~6 meses · 2025-2026
ProblemaInstituições tentavam avaliar Market Makers com ferramentas caras e dados espalhados. Quando uma penalidade está em jogo, informação parcial não basta.
AbordagemSLA binário, liquidity ao longo do tempo, barra lateral e filtros em um dashboard único, com detalhes sob demanda.
Resultado61→88% de conclusão de tarefas nas rodadas de teste. Segundo os clientes, a verificação caiu de ~20 minutos para menos de 30 segundos.

Avaliar um Market Maker era mais difícil do que deveria

Instituições Web3 dependem de Market Makers para manter liquidity e eficiência de mercado. Mesmo assim, entender se eles estão entregando o que foi contratado ainda exige muito trabalho manual.

Ferramentas como Dune e DeFiLlama são caras, deixam os dados espalhados e nem sempre indexam exatamente o que cada cliente institucional precisa.

Quando há dinheiro em risco, inclusive na decisão de aplicar uma penalidade contratual a um Market Maker, não dá para depender de dados incompletos.

Dois públicos. Necessidades opostas. Uma decisão.

Dois públicos usam os mesmos dados para objetivos diferentes: fundos institucionais, protocolos DeFi e exchanges precisam decidir rápido, mesmo sem domínio técnico; já os Market Makers precisam provar que cumpriram o SLA.

Quando um Market Maker sai dos limites do contrato, alguém precisa decidir, com dados confiáveis, se cabe uma penalidade.

Uma decisão errada custa dinheiro para os dois lados.

Conhecimento do mercado, depois referências de produto

A equipe já conhecia o problema por dentro. O Product Manager tinha anos de experiência como analista de dados, com contato direto com a dor que queríamos resolver.

O CEO também lidava com esse problema antes do projeto. Cruzamos esse conhecimento com referências como Dune, DeFiLlama, Bloomberg Terminal, Grafana e Datadog para entender como cada produto organiza dados financeiros densos.

O padrão era claro: ferramentas caras, dados fragmentados e pouca flexibilidade para indexar o que cada cliente precisava. A oportunidade era reunir tudo em uma única plataforma, com preço justo e contratos personalizados. Cada liquidity pool era configurado e indexado de acordo com o contrato, com clareza suficiente para reduzir perdas e evitar penalidades aplicadas com base em uma leitura errada.

Quatro decisões de UX que moldaram o produto

Quatro decisões de UX definiram o produto, cada uma comparada a uma alternativa. Todas respondiam ao mesmo objetivo: reduzir drasticamente o tempo entre consultar um dado e decidir se cabia uma penalidade.

01

SLA como contrato binário, não como percentual isolado

“98,7%” não responde ao que importa: o contrato foi cumprido ou não? A UI mostra o SLA como cumprido ou não cumprido.

02

Liquidez como comportamento ao longo do tempo, não como valor estático

Uma liquidity pool de US$ 200 mil pode ter caído 60% na última semana. Mostrar só o valor atual esconde o principal. Por isso, tendência e direção vêm primeiro.

03

Contexto e filtros na barra lateral, sempre ao alcance

Quem monitora várias liquidity pools com contratos diferentes precisa se orientar sem sair do dashboard. A barra lateral reúne dados do contrato, contexto da pool e referências; os filtros recortam por pool, período e status do SLA.

04

Um modelo mental de tela única

As informações foram organizadas em quatro camadas: status do SLA, comportamento da liquidity, comparação de mercado e metodologia. Os detalhes aparecem sob demanda, sem tirar o usuário do contexto.

Alertas automáticos avisam quando um dado passa do limite esperado e reduzem o monitoramento manual. Para entregar um produto dessa complexidade no prazo, usamos fluxos de trabalho assistidos por IA. Isso acelerou a execução e abriu espaço para testar mais variações de layout sem reconstruir cada opção do zero.

Rodadas com operadores, depois uso real em produção

Testamos com 4 operadores em várias rodadas ao longo do projeto, não em uma sessão isolada. Também fizemos testes A/B rápidos e enxutos para comparar alternativas sem comprometer o cronograma.

O principal atrito da v1 era direto: “métricas demais ao mesmo tempo”. Reduzimos o dashboard principal de 12 métricas para 4 essenciais e deixamos as demais nos níveis de detalhe.

Depois do lançamento, a validação mais forte veio do uso real pelos dois principais clientes B2B, Worldchain e Kraken. O projeto levou cerca de 6 meses do início ao handoff.

Resultados mensurados e adoção institucional

6188%

Conclusão de tarefas · 4 operadores, várias rodadas

20min<30s

Tempo para verificar um dado · relatado pelos clientes

120+

Componentes · handoff para desenvolvimento ~35% mais rápido

Nas rodadas com os 4 operadores, a conclusão de tarefas passou de 61% para 88%. É um sinal direcional, não um teste estatístico com amostra grande, mas o avanço se repetiu ao longo das rodadas.

  • Validação em produção: Worldchain e Kraken usam o produto com contratos personalizados e várias liquidity pools monitoradas 24/7
  • Velocidade relatada pelos clientes: cruzar dados entre plataformas levava ~20 minutos; no dashboard unificado, a verificação caiu para menos de 30 segundos (relato qualitativo, sem medição controlada com todos os usuários)
  • Entrega assistida por IA: os ciclos de design ficaram ~60% mais rápidos, o que permitiu testar mais variações de layout dentro dos mesmos 6 meses
  • Foco nas métricas: o dashboard principal passou de 12 métricas simultâneas para 4 essenciais, com as demais disponíveis sob demanda

Do monitoramento reativo às decisões preditivas

Hoje, a plataforma responde: “este Market Maker está dentro do contrato agora?” O próximo passo é responder: “ele continuará dentro do contrato amanhã?”

As prioridades são alertas preditivos antes que os limites sejam ultrapassados e comparação neutra de até três Market Makers na mesma visualização, sem reintroduzir o viés de ranking que removemos.

Em produtos institucionais, menos pode ser uma decisão estratégica. Simplificar a UI sem simplificar a arquitetura da informação só transfere a confusão para outra tela. Cada métrica removida do dashboard precisava justificar por que voltaria nos detalhes.