Stop shipping UIs that hide the math. A recent post-mortem from the Bússola project, a proof-of-concept built during the Itaú, Google Cloud, and SantoDigital Agent Battle, highlights a critical failure in financial interface design: displaying a total monthly cost without breaking down its source. The team discovered that their 'Accelerated' plan scenario, showing R$ 1,660.85 per month for 19 months, misled users by implying the amount came solely from existing disposable income. In reality, the total was composed of R$ 1,383.20 from existing surplus (sobra) and R$ 277.65 that depended on future expense cuts (cortes).

The Hidden Cost of Ambiguous Labels

The original interface presented the 'Accelerated' scenario with a simple value and deadline, failing to distinguish between money already available and money that required behavioral change. This is a classic infrastructure failure in product logic: the calculation engine knew the difference between 'sobra' and 'cortes', but the front-end copy flattened these distinct conditions into a single misleading number. As the author notes, 'The value was visible. The condition needed to appear.' If a user believes they can pay R$ 1,660.85 from savings, but R$ 277.65 of that amount requires cutting their budget, the interface has lied about the effort required.

Decomposing the Decision Logic

The revised design explicitly splits the monthly commitment into two components: R$ 1,383.20 from existing surplus and R$ 277.65 dependent on cuts. This decomposition allows users to verify the relationship before committing. The button label was also updated from a generic 'Continue' to 'Choose 19-month plan,' forcing acknowledgment of the duration. This aligns with WCAG 2.2 criteria 3.3.2 and 2.4.6, which mandate that labels and instructions support the task by clarifying what is being selected. In dev terms, if your backend returns a composite object, your frontend must not render it as a scalar primitive without context.

Important Context on Data Validity

It is crucial to note that these figures are not live production data. The source explicitly states that the states presented are 'reconstitutions' based on code and scripts, not captures of executed versions. Furthermore, the values are 'examples from the simulation' and do not represent results obtained by a real person or aggregated data from the challenge. This distinction ensures that developers and designers understand they are reviewing a UX pattern and a hypothetical scenario, not a verified financial outcome.

Key Takeaways

  • Surface Dependencies: If a calculated value relies on future user action (like spending less), the UI must explicitly separate the current available amount from the contingent amount. In the example, R$ 1,383.20 was available, while R$ 277.65 was contingent.
  • Actionable Buttons: Replace generic CTAs like 'Continue' with specific commitment labels (e.g., 'Choose 19-month plan') to reduce cognitive load and improve informed consent.
  • Copy Equals Code: A clear text label cannot fix a flawed recommendation logic; the interface must accurately reflect the underlying data constraints and assumptions.
  • Prototype Caution: Remember that hackathon POCs, like Bússola, require rigorous post-event UX refinement. Always verify if displayed metrics are live data or simulated examples to avoid misrepresenting system performance.

The Bottom Line

If your UI hides the math, you are hiding the truth. Stop letting your interface lie by omission; break down the numbers so users know exactly what they are signing up for before they click.