Credit Black 

O CreditBlack é uma proposta de plataforma financeira focada em transações com criptomoedas, construída fora do sistema financeiro tradicional. O projeto parte de um princípio simples: se o usuário não confia totalmente nas instituições centralizadas, então o produto precisa compensar isso com transparência, controle e segurança percebida.

O desafio não era apenas criar uma interface funcional, mas transformar um ambiente naturalmente complexo — cripto — em uma experiência compreensível, confiável e utilizável por diferentes níveis de usuários.

O ponto de partida do projeto não foi interface nem benchmark, mas uma propriedade do próprio sistema: em criptomoedas, transações são irreversíveis. Isso não é uma limitação técnica contornável, é uma regra estrutural.

A implicação direta é que o sistema não corrige erro. Se o usuário toma uma decisão incorreta, o resultado é executado integralmente. Isso desloca o problema de design de “facilitar interação” para algo mais fundamental: controlar o risco gerado pela própria interface.

Nesse contexto, fluidez não é necessariamente um objetivo. Reduzir fricção indiscriminadamente pode, inclusive, aumentar a taxa de erro. A interface precisa equilibrar velocidade com previsibilidade — e, em muitos momentos, desacelerar o usuário intencionalmente.

A arquitetura foi definida a partir de um problema recorrente em produtos financeiros: a sobreposição entre leitura de estado e execução de ação. Quando essas duas coisas acontecem no mesmo espaço sem hierarquia clara, o usuário tende a agir antes de compreender.

A decisão foi separar explicitamente três momentos: orientação (dashboard), organização (carteiras) e execução (ações como enviar/receber). Essa separação não elimina a complexidade, mas distribui o esforço cognitivo ao longo do fluxo.

O trade-off é direto: aumenta-se a quantidade de navegação e o tempo para executar determinadas ações. No entanto, isso reduz um comportamento mais crítico — ações tomadas sem entendimento suficiente do contexto.

O resultado prático é um sistema menos “imediato”, porém mais estável em termos de tomada de decisão.

Ao entrar no fluxo de recebimento, o problema deixa de ser estrutural e passa a ser físico. Endereços de carteira são strings extensas, não possuem semântica legível e qualquer erro de caractere invalida ou redireciona a transação.

Permitir digitação manual como caminho principal seria, essencialmente, aceitar erro como inevitável.

A decisão de centralizar o fluxo em QR code surge como uma forma de eliminar completamente a etapa de input manual. Não se trata de otimizar o fluxo, mas de remover um ponto de falha. O endereço textual continua presente, não como método principal, mas como mecanismo de verificação e interoperabilidade.

Esse desenho assume um trade-off inevitável: QR code depende de outro dispositivo ou contexto externo, enquanto o texto mantém autonomia, porém com maior risco. A solução não escolhe um único caminho, mas hierarquiza — prioriza o mais seguro sem eliminar o mais flexível.

O resultado é a redução direta do erro na origem, em vez de tentar mitigá-lo posteriormente.

No histórico de transações, o problema não é executar, mas interpretar. O usuário precisa reconstruir rapidamente o que aconteceu: entrada, saída, status e impacto.

Se cada item exige leitura detalhada, o custo cognitivo cresce linearmente com o número de transações. Em cenários reais, isso torna a interface inutilizável.

A decisão foi estruturar a informação em níveis de leitura. O primeiro nível resolve reconhecimento imediato — direção da transação e seu efeito. O segundo adiciona contexto suficiente para validação. O detalhe completo fica acessível, mas não obrigatório.

O trade-off aqui é a compressão da informação visível por item. Parte dos dados deixa de estar imediatamente exposta. No entanto, isso reduz o tempo de varredura visual e melhora a detecção de padrões.

O resultado é uma interface que funciona melhor em escala, onde o usuário não lê o histórico, mas o percorre.

Durante a criação de uma nova carteira, surge um problema de modelo mental. A distinção entre ativos não é óbvia para usuários menos experientes, e o sistema não oferece correção posterior simples.

Se o produto permitir a criação sem explicitar essa regra, o erro só se manifesta depois, já no uso, onde o custo é maior.

A decisão foi antecipar esse ponto e forçar a definição do ativo no momento da criação, reforçando explicitamente o que está sendo configurado. Isso introduz uma quebra no fluxo direto, obrigando o usuário a tomar uma decisão consciente.

O trade-off é a introdução de fricção em um momento que poderia ser mais rápido. No entanto, essa fricção não é arbitrária — ela existe para deslocar o erro de um ponto irreversível para um ponto controlado.

O resultado é a prevenção de inconsistências estruturais que comprometeriam o uso futuro.

Com múltiplas carteiras, o sistema deixa de ser linear e passa a exigir organização. Sem uma estrutura clara, o usuário perde a capacidade de formar um modelo mental consistente.

A decisão foi expor simultaneamente duas perspectivas: uma visão agregada, que permite entender distribuição de valor, e uma visão individual, que mostra comportamento específico de cada carteira.

Isso aumenta a densidade da interface e exige um esforço inicial maior de leitura. Esse é o trade-off explícito: menor simplicidade superficial em troca de maior capacidade de compreensão sistêmica.

O resultado é que o usuário não precisa navegar para construir contexto. Ele começa já com uma visão estruturada do sistema.

A tela da carteira interna concentra o ponto de maior risco do produto. É onde o usuário consulta saldo, decide e executa ações irreversíveis.

Uma abordagem comum seria separar essas funções em diferentes telas para reduzir complexidade visual. No entanto, isso introduz um problema mais grave: perda de contexto no momento da decisão.

A decisão foi manter todas as informações relevantes no mesmo espaço. O usuário não precisa lembrar seu saldo ao iniciar uma ação, nem reconstruir histórico ao validar uma decisão. Tudo está visível no momento crítico.

Avisos contextuais são inseridos exatamente onde a probabilidade de erro aumenta. Eles não funcionam como instruções gerais, mas como mecanismos de interrupção em pontos de risco.

O trade-off é uma interface mais densa e menos minimalista. A estética cede espaço para a função.

O resultado é uma redução na dependência de memória e, consequentemente, menor probabilidade de erro em ações críticas.

O projeto evoluiu de uma necessidade pontual para a construção de um ecossistema digital mais amplo. A partir de uma linguagem visual consistente, diferentes jornadas — da criação e gerenciamento de carteiras às experiências institucionais — passaram a fazer parte de uma mesma experiência.

Mais do que desenhar interfaces, o desafio foi criar uma base capaz de organizar diferentes produtos, fluxos e pontos de contato sem perder clareza ou consistência.