Uma simulação financeira precisa explicar o esforço

# ux# design# ai
Uma simulação financeira precisa explicar o esforçoKell da Cereja Flamejante

Um plano pode parecer atraente porque termina rápido. Mas o prazo, sozinho, não explica o compromisso...

Um plano pode parecer atraente porque termina rápido. Mas o prazo, sozinho, não explica o compromisso que a pessoa está assumindo.

Na Bússola, essa diferença apareceu durante a revisão de uma simulação financeira. A interface destacava um cenário chamado “Acelerado”, com valor mensal e prazo. Faltava deixar claro que parte daquele valor dependia de mudanças nos gastos.

A Bússola é uma prova de conceito criada por uma equipe de Produto, Design e Engenharia na Batalha de Agentes Itaú, Google Cloud e SantoDigital. Depois do evento, o projeto passou por refinamentos de UX e conteúdo. Este artigo trata de um desses refinamentos; não descreve um serviço bancário em operação.

O valor estava visível. A condição precisava aparecer.

O estado anterior reconstituído no case apresentava:

Acelerado — 80% da sobra — R$ 1.660,85 por mês — 19 meses.

O problema era a relação entre as informações. A menção à sobra não explicava os cortes adicionais que compunham o valor mensal.

Imagine ler esse resumo e concluir que basta reservar parte do que já sobra. Se o plano também exige reduzir despesas, essa condição precisa aparecer antes da escolha.

Não é uma questão de deixar o texto mais simpático. É uma questão de explicar o que o número exige.

Mostrar a composição antes de pedir a decisão

Antes e depois do cenário Acelerado: a versão posterior identifica a sobra, os cortes necessários e o compromisso de 19 meses.

Figura 1. Reconstituições baseadas no código e no roteiro. Não são capturas das versões executadas. Os valores são exemplos da simulação.

Na revisão, o cenário passou a apresentar:

  • Exige mudanças
  • R$ 1.660,85 por mês · 19 meses
  • Da sobra: R$ 1.383,20
  • Cortes: + R$ 277,65
  • Economias precisam acontecer.

O botão também passou a identificar o compromisso: “Escolher plano de 19 meses”.

Os valores são exemplos da simulação apresentada no projeto. Não representam resultados obtidos por uma pessoa real nem agregados da base do desafio.

A decomposição permite conferir uma relação simples:

R$ 1.383,20 disponíveis da sobra
+ R$ 277,65 dependentes de cortes
= R$ 1.660,85 de compromisso mensal
Enter fullscreen mode Exit fullscreen mode

Essa apresentação separa o dinheiro disponível da economia que ainda precisa acontecer. As duas parcelas somam o mesmo valor, mas têm condições diferentes.

Diagrama da composição mensal: R$ 1.383,20 da sobra mais R$ 277,65 dependentes de cortes somam R$ 1.660,85 por mês, durante 19 meses.

Figura 2. Diagrama editorial, não uma tela da Bússola. A barra representa as proporções das duas parcelas do exemplo; não representa uma distribuição de usuários ou um resultado financeiro observado.

Copy e cálculo precisam concordar

Se o cálculo inclui uma condição, a interface precisa comunicar essa condição. Se a interface apresenta um valor como disponível, o sistema precisa sustentar essa interpretação.

Uma revisão útil começa com perguntas concretas:

  1. De onde vem cada parcela do valor?
  2. O que depende de uma mudança futura?
  3. Essa condição está visível antes da escolha?
  4. O botão identifica o compromisso ou apenas diz “continuar”?

Esse trabalho envolve conteúdo, produto e engenharia. Um texto claro não corrige, sozinho, uma lógica de recomendação inadequada.

Referências que ajudam a revisar a decisão

A documentação do W3C para WCAG 2.2, critério 3.3.2: rótulos ou instruções orienta a fornecer informações para que a pessoa saiba o que está selecionando. Não se trata de explicar tudo: a instrução precisa apoiar a tarefa.

O critério 2.4.6: títulos e rótulos pede que descrevam o assunto ou a finalidade. É uma referência útil para revisar “Escolher plano” e perguntar se o rótulo identifica suficientemente o compromisso apresentado. Esse recorte de escrita não demonstra conformidade com WCAG; semântica, interação e testes assistivos também precisam ser verificados.

Para experiências com IA, a diretriz 11 do Microsoft HAX Toolkit recomenda permitir acesso a explicações sobre as saídas do sistema. Ela também alerta que uma explicação pode aumentar a confiança sem que o sistema mereça essa confiança. No nosso exemplo, mostrar a composição do valor explica uma conta; não valida a recomendação financeira nem o prazo.

Essas referências ajudam a definir critérios de revisão. Não são evidência de que a mudança da Bússola melhorou a compreensão das pessoas.

O que esta revisão permite afirmar

A versão revisada explicita a composição do compromisso mensal. Isso é observável na interface.

Ainda não permite afirmar que as pessoas entenderam melhor, escolheram planos mais adequados ou melhoraram sua saúde financeira. Essas conclusões exigem pesquisa com participantes e validação da lógica dos cenários.

As comparações do case são reconstituições visuais baseadas no código e no roteiro, não capturas das versões executadas. A revisão de escrita e interface aconteceu depois da entrega coletiva da hackathon.

Minha conclusão de trabalho é simples: antes de tornar um plano mais atraente, precisamos tornar suas condições mais visíveis.

Fontes

O projeto original é coletivo. Este recorte aborda o refinamento posterior de UX e conteúdo.