Product Design · UX Strategy

Aequus
Financial

Como transformei dados financeiros complexos em decisões intuitivas — redesenhando a lógica de transparência em gestão financeira compartilhada para casais, sócios e famílias.

Product Designer
Research · UX · UI · Estratégia
Mobile — iOS / Android
Conceito validado
Tela Metas Compartilhadas

Contexto

O problema não era financeiro.
Era epistêmico.

Casais e sócios que gerenciam finanças juntos raramente discutem por causa de dinheiro — discutem por causa de percepções divergentes sobre o que aconteceu com o dinheiro. A informação existe, mas está fragmentada, ambígua ou apresentada de um jeito que não resolve a pergunta real: "estamos indo bem? E cada um de nós está contribuindo de forma justa?"

Apliquei o framework de Jobs to Be Done para separar o que os usuários diziam que queriam ("ver o saldo") do que realmente precisavam: uma referência compartilhada de realidade financeira — objetiva, sem margem para reinterpretação, e consultável a qualquer momento sem precisar de uma conversa.

A hipótese central que guiou o projeto: a maioria dos conflitos financeiros em relações compartilhadas não decorre de escassez de recursos, mas de assimetria informacional — cada parte opera com dados diferentes sobre a mesma realidade.

Research

Três tensões que o mercado ignorava

Conduzi entrevistas e análise de reviews dos principais apps financeiros (Mobills, Organizze, Wallet) para mapear onde as soluções existentes falhavam sistematicamente.

Tensão 01

Visão agregada oculta responsabilidade individual

Saldo total não responde quem contribuiu quanto. Usuários construíam planilhas paralelas — evidência clara de que o app não resolvia a pergunta real.

Tensão 02

Automação sem transparência cria desconfiança

Regras automáticas de distribuição eram percebidas como caixas-pretas. Usuários desativavam recursos avançados por não entenderem a lógica.

Tensão 03

Planejamento futuro separado do contexto atual

Apps mostravam histórico ou projeções — raramente os dois conectados. A decisão de comprar um imóvel não podia ser simulada contra a realidade presente.


Princípios

Antes de qualquer tela,
três compromissos inegociáveis

Princípios de design não são slogans. São critérios de decisão — o que uso para julgar se uma solução serve ou não ao problema central.

"Transparência em primeiro lugar, não como feature."
Cada tela do Aequus deve responder, sem clique adicional, à pergunta "quem contribuiu quanto?". Isso eliminou toda solução que enterrava dados de contribuição em submenus ou relatórios secundários — mesmo que fossem tecnicamente mais elegantes.
"O usuário configura uma vez. O sistema garante para sempre."
Automação só tem valor se o usuário entende e confia na lógica. Optei por automação explicável: cada regra exibida com linguagem simples, editável a qualquer momento, e auditável no histórico. Abri mão de algoritmos mais sofisticados em favor de previsibilidade.
"Equidade não é igualdade — é clareza."
O nome Aequus deriva do latim aequitas. O design não força divisão 50/50 — ele torna qualquer divisão acordada completamente visível e rastreável. A justiça está na transparência do processo, não numa fórmula imposta.

Solução

Cinco pilares, uma
arquitetura coesa

Cada módulo que projetei responde a uma tensão específica identificada no research. Parti de uma pergunta central e não saí dela: como garantir que duas pessoas sempre operem com a mesma realidade financeira?

i
Transparência em Primeiro Lugar
Gráficos de Progresso Divididos

Projetei os Gráficos de Progresso Divididos para exibir simultaneamente o progresso total da meta e a contribuição individual de cada parceiro — sem clique adicional. O azul primário sinaliza destaque funcional, não estético: ele existe para eliminar a ambiguidade sobre quem contribuiu o quê.

Testei três variantes de visualização. A versão com donut duplo gerou confusão — usuários interpretavam como duas metas distintas. O modelo barra+percentual individual foi o único que passou em teste de compreensão sem instrução prévia.

Tela Metas Compartilhadas
ii
Planejando o Futuro
Simulador de Cenários Interativo

O simulador conecta decisões futuras à realidade presente. Sliders de tempo e valor atualizam o gráfico em tempo real — transformando incerteza em plano de ação visual e tangível. Escolhi sliders em vez de inputs manuais deliberadamente: o movimento contínuo cria exploração, não comprometimento.

Considerei limitar simulações a metas já criadas, mas o research mostrou que usuários queriam simular hipóteses antes de formalizar. A flexibilidade aqui reduz o atrito de entrada — o usuário experimenta antes de se comprometer.

Simulador de Cenários
iii
Automação Inteligente
Cards de Regras de Alta Clareza

Simplifiquei a lógica de distribuição para Se-Então legível: cada regra é um card editável com linguagem natural. A equidade é mantida de forma passiva — o sistema executa sem intervenção, mas cada decisão é auditável e revisável a qualquer momento.

Deliberadamente descartei um motor de regras baseado em condições compostas (AND/OR). Seria mais poderoso — e inacessível para 80% dos usuários-alvo. Optei por expressividade reduzida em favor de confiança elevada.

Automação Financeira
iv
Gerenciamento e Segurança
Conta Compartilhada com Controle Granular

A área de Conta Compartilhada centraliza permissões por parceiro, status de contribuição e configurações de segurança — tratada como ponto de controle, não de configuração técnica. O layout limpo e segmentado sinaliza profissionalismo, reduzindo ansiedade em decisões de permissão.

Testei separar "segurança" e "parceiro" em seções distintas. Usuários percebiam como duplicidade. A unificação sob "Conta Compartilhada" reflete o modelo mental real: parceiro e permissão são inseparáveis no contexto de finanças conjuntas.

Perfil e Conta Compartilhada
v
Arquitetura de Produto
Complexidade Acessível por Camadas

O Aequus transforma dados complexos em insights acionáveis via arquitetura em camadas: visão imediata no nível zero, profundidade disponível sob demanda. Cada tela responde à pergunta mais urgente sem exigir que o usuário entenda o sistema todo antes de extrair valor.

Fui tentada várias vezes a adicionar mais informação na home. Cada adição foi testada contra a pergunta: "isso responde algo que o usuário não conseguiria descobrir navegando?" Se não, fora. Densidade de informação não é sofisticação — é ruído.

Simulador landscape

Resultados observados
e projeções estimadas

Os dados abaixo combinam resultados diretos de testes de usabilidade com projeções baseadas em benchmarks de mercado — cada métrica está identificada pela sua origem.

100%
compreensão da contribuição individual em teste de usabilidade, sem instrução prévia
~30%
redução estimada de conflitos financeiros, com base em benchmarks de transparência em casais
mais exploração de cenários futuros comparado a telas equivalentes em apps concorrentes
0
usuários que desativaram a automação após entender a lógica dos Cards de Regras no teste

Retrospectiva

O que eu faria
diferente hoje

O que aprendi nesse projeto foi tão importante quanto o que entreguei. Abaixo, o que funcionou bem e o que eu faria diferente com o que sei hoje.

O que funcionou
  • Princípios definidos antes de telas — reduziu retrabalho significativamente
  • Separar métricas de validação de métricas de produto projetadas
  • Descartar variantes de visualização com critério documentado, não por estética
  • Arquitetura em camadas — profundidade sem sobrecarga cognitiva
  • Cards de Regras com linguagem natural — confiança alta mesmo com lógica complexa
O que evoluiria
  • Incluiria pesquisa quantitativa — a análise de reviews foi qualitativa por limitação de tempo
  • Testaria o simulador com cenários reais dos usuários, não hipotéticos
  • Mapearia edge cases da automação: o que acontece quando uma regra conflita com outra?
  • Conduziria teste de acessibilidade com contraste e leitura de tela
  • Documentaria o design system como entregável separado, não apenas aplicado