Para preservar a confidencialidade (NDA), a identidade e dados reais foram alterados ou omitidos.
Visão geral
O Meridian é a plataforma acadêmica onde alunos acompanham aulas, avaliações, TCC e os pagamentos do curso.
Na época, ele passava por uma refatoração completa. Todas as seções foram repensadas para o sistema novo, e o Financeiro era uma das mais sensíveis.
É onde o aluno consulta parcelas, atualiza boletos e entende sua situação com a instituição.
A seção legada tinha todas as funções. O problema é que não estavam bem organizadas. Ações secundárias tomavam destaque, informações críticas ficavam escondidas, e o aluno com uma dúvida básica acabava ligando pro suporte.
Meu papel e ações
Financeiro é a única seção onde um erro de leitura custa dinheiro de verdade.
Se o aluno não vê que tem uma parcela atrasada, ele atrasa mais. Se não percebe que já pagou, paga de novo.
Conduzi o projeto do diagnóstico à entrega em alta fidelidade. Comecei mapeando as oportunidades na versão legada e separando o que o aluno conseguia resolver sozinho do que dependia do suporte.
Comecei o processo pela própria nomenclatura da seção.
No legado essa seção chamava "Tesouraria". Minha hipótese é de que esse termo não é claro o suficiente. Testei num card sorting do sistema inteiro com 12 pessoas. Nesta seção, 10 reagruparam como "Financeiro", e foi isso que levei para a estrutura.
Depois decidi estressar a arquitetura antes de rabiscar.
Fiz userflows e mapeei as features disponíveis. Então testei quatro estruturas em lo-fi: por blocos, por tabs, por coluna e combinações. Documentei o ponto forte de cada uma. Comparar o que cada estrutura resolvia, e o que cada uma escondia, foi o que me levou a seguir com blocos e cards.
A decisão que ancorou o resto foi de prioridade.
Priorizei pendências no topo, sempre. Abri mão de um painel cronológico completo na entrada para garantir que quem tem algo em aberto chega direto no problema. O custo é que o aluno em dia não vê o panorama geral de cara. Aceitei isso porque o momento mais crítico de acesso é justamente quando existe algo pendente.
Aqui o projeto me corrigiu duas vezes.
A primeira: nas ideações iniciais, desenhei para um aluno com um plano de pagamento. Mas o aluno pode ter mais de um, e eu não tinha considerado isso. Quando há pendência num plano que não está na tela ativa, o risco é o aluno perder o vencimento sem nunca ver o alerta. Resolvi com um componente do Design System e apoiei a solução em outras partes do sistema: notificação, calendário, seção de informações e e-mail. A ideia era que a informação alcançasse o aluno mesmo fora da tela do Financeiro.
A segunda veio mais tarde e foi mais humilde. Eu tinha desenhado para o aluno pagante. O bolsista integral não paga, e mesmo assim a interface mostrava "pagamento em dia" e parcelas de "R$ 0,00". Tecnicamente correto, na prática sem sentido. A tela informava um pagamento que não existia. Esse cenário não estava mapeado, e parte do ajuste para os perfis de bolsa veio depois do lançamento.
Resultado
A seção entrou no ar final de 2025, dentro da plataforma Meridian. A validação com gestor e time do Relacionamento aconteceu antes do desenvolvimento, sem revisão estrutural depois da apresentação;
Defini três frentes de medição, cada uma ligada a uma decisão do projeto:
Tickets de Atendimento medem a hipótese central, a de autonomia. Se a seção ficou mais clara, os chamados sobre vencimento e segunda via caem, porque era essa categoria que o redesign mirava.
Relacionamento dá a leitura qualitativa. A pergunta é direta: mudou o tipo de dúvida que chega depois do lançamento?
Clarity valida a decisão de hierarquia. Se priorizar pendências no topo funcionou, o heatmap mostra a atenção concentrada ali, e o uso dos filtros revela se a entrada filtrada fez sentido.
Os ajustes para perfis de bolsa entraram depois do lançamento, corrigindo o cenário que eu não havia mapeado.
Aprendizados
Aprendi que:
Clareza de status financeiro não é detalhe de UI, mas sim uma decisão de produto. O que aparece primeiro, e com qual peso, muda o comportamento do aluno e o volume de suporte;
Desenhar para o usuário padrão é o erro mais fácil de cometer. Os outros tipos de perfis, como o bolsista integral, não deveriam ser incorporados depois. Funcionam também como teste de verdade da arquitetura;
Estressar quatro estruturas antes de decidir custou tempo, mas garantiu que a solução final não fosse a primeira ideia. Cada versão descartada deixou claro o que a próxima precisava fazer melhor.