Designing comparison and calculator interfaces around unknown values

An empty input and a confirmed zero can look similar in a form, but they carry different meanings. A comparison interface needs to preserve that difference, especially when some of the information comes from documents a visitor has not finished checking.

VayThongMinh is my own in-house project: an independent informational website for a Vietnamese audience, not a lender. Its interface connects comparison content, explanatory articles and a cost calculator.

Make the comparison fields consistent

The homepage presents vehicle choices, amount and term selectors, and comparison cards. The cards organise information under recurring labels for vehicle type, documents and costs. Links lead from the overview to conditions and further detail.

Consistent labels give the reader a stable way to move across options. They also make a qualified value, such as a cost that depends on the individual documents, easier to recognise alongside a fixed piece of information.

The interface separates these comparison views from the calculator. Browsing an option and entering a calculation have different purposes, so their controls need different explanations.

Keep unknown distinct from zero

The cost calculator separates principal from the amount actually received. Its controls include interest-entry choices, rate units and periods, one-time fee handling, and recurring fee amounts and collection counts.

The form provides explicit choices for information that remains unknown. It distinguishes a fee confirmed as absent from a fee whose amount or collection method is unresolved. That is a useful interface decision: a missing answer remains visible instead of becoming an apparently complete result.

A small illustrative page model can express the distinction. This is an example for explaining the design, not production source:

{
  "oneTimeFee": {
    "status": "unknown",
    "amountVnd": null,
    "collectionMethod": null
  },
  "recurringFee": {
    "status": "confirmed_absent",
    "amountVnd": 0,
    "collectionCount": 0
  }
}

The separate fields show why knowing an amount does not automatically establish how it is collected. The calculator's interface treats fee amounts, collection timing and collection counts as separate pieces of information.

Put explanations beside the decision

The calculator groups related inputs under labelled sections. Nearby explanations describe the difference between principal and money received, the available interest-entry methods, and the handling of fees.

Its result area separates interest, fees and estimated total payment. Those labels continue the language used in the form, giving the reader a connection between input and output.

For developers designing similar interfaces, the useful pattern is to represent uncertainty explicitly and explain it where the decision happens. Clear labels, grouped controls and visible unknown states help the interface communicate what the visitor has supplied and what still needs clarification.