Voltar
TokenGO: da marca ao MVP,
com um onboarding que entrega valor antes da burocracia
Marca, onboarding e dashboard de uma plataforma de antecipação de recebíveis em blockchain, para pessoas que nunca ouviram falar de blockchain.
Configuração do projeto
Papel: Product Designer, da marca ao MVP
Time: 6 pessoas: design, produto e tecnologia
Ferramentas: Figma e Confluence
Categoria: Product Design, UX/UI, Branding, Fintech
Conteúdo confidencial. Telas e dados foram omitidos ou adaptados por acordo com a empresa. Fluxos completos disponíveis sob solicitação em contexto profissional.
Se você ler só uma parte
A TokenGO tokeniza recebíveis para que pequenos comércios antecipem crédito, e a maior parte do público nunca tinha ouvido falar de blockchain.
O onboarding original pedia o cadastro completo de pessoa física e jurídica antes de a pessoa ver qualquer valor.
A proposta foi inverter a ordem: identidade digital e conta ativa primeiro, burocracia depois.
O fluxo foi aprovado pelo Compliance sem retrabalho relevante.
O problema
“Blockchain” e “tokenizar” não diziam nada para a maioria dos entrevistados, e as dúvidas se repetiam.
O benchmark mostrou linguagem técnica, verificações longas e compliance acima da clareza.
O onboarding original juntava PF e PJ numa trilha única, antes de qualquer valor.
O Compliance pedia segurança máxima e o Negócio pedia conversão: cada documento a mais tendia a derrubar o cadastro, e cada flexibilização aumentava o risco jurídico.
Com um time de três pessoas, o desenho precisava atender às duas pressões ao mesmo tempo.
O que precisava ser respondido
01. Como explicar algo que o usuário nunca ouviu falar?
É seguro, quando recebo, quanto fica comigo.
02. Como cadastrar sem perder a pessoa antes de ela ver valor?
Compliance e conversão na mesma conta.
03. O que cabe num MVP de três pessoas, dentro das regras do Banco Central?
Cada tela tinha custo.
O que foi feito
A marca veio antes das telas
O projeto começou sem identidade, só com um nome de trabalho, Trustee. O primeiro mês foi de branding: tom de voz, o nome TokenGO, manual da marca e um KV, que serviu de referência para o desenho do produto.
As restrições definiram o escopo
Textos regulatórios obrigatórios do Banco Central
Dados sensíveis, com compliance desde o primeiro dia
Time de desenvolvimento pequeno
As entrevistas mostraram que clareza pesa mais do que o número de passos
Nas entrevistas com potenciais usuários, PF e PJ, a linguagem de blockchain não comunicava nada. Os termos repetidos eram segurança, prazo de recebimento e quanto fica com o cliente. O dashboard e a microcopy foram organizados em torno dessas perguntas.
O MVP focado foi a rota escolhida
Havia duas opções:
Plataforma completa: interface única para PF e PJ, todos os produtos visíveis e design system antes do lançamento.
MVP focado: fluxos separados para PF e PJ, linguagem adaptada a cada contexto, menos telas.
O MVP focado coube no prazo e nas restrições regulatórias.
O onboarding inverteu a ordem:
valor primeiro, burocracia depois
A reestruturação do fluxo de KYC/KYB ficou com o design. A proposta foi um onboarding progressivo, com a PF primeiro e a PJ depois. Em troca, a conta nasce incompleta, e a pendência precisa ficar clara na interface. Os casos de procuração seguem com validação humana, porque automatizar tudo expunha a empresa a risco jurídico.
Três frentes sustentam o fluxo:
Nascimento progressivo: conta de blockchain vinculada ao CPF, antes do CNPJ.
Validação com rede de segurança: acompanhamento por link seguro e troca de número sem perder o progresso.
Complexidade fora da vista: sem chaves ou hash para o usuário, e cadastro de empresa por API da Receita, com trilha manual de contingência.
O dashboard seguiu as perguntas das entrevistas
Recebíveis, histórico de antecipações e status em tempo real, com acessibilidade em contraste, tema claro e escuro, fonte ajustável e gráficos pensados para daltonismo. Os componentes foram construídos junto com o produto, com tokens, padrões de formulário e estados de erro documentados.
resultado
O onboarding foi aprovado pelo Compliance sem retrabalho relevante.
O fluxo anterior nunca foi ao ar, então não há métrica de abandono para comparar.
Os bloqueios de suporte por falha de SMS e validação diminuíram.
Nos testes qualitativos, separar PF e PJ reduziu a confusão no fluxo,
e a microcopy ajudou a progressão.
O produto estava em validação de mercado no encerramento, com as métricas de conversão ainda em construção.
Em retrospecto
Não houve teste de usabilidade formal. A validação foi mais com Compliance e Engenharia do que com o usuário final. Animações, microinterações e edge cases raros ficaram de fora, e o roadmap mudou no meio do projeto.
Com mais tempo, stakeholders de negócio entrariam mais cedo na segmentação PF/PJ, e as métricas de validação seriam definidas antes do desenho.
