A formula can tell software how to calculate, but it does not tell a person what problem the interface is solving. That distinction matters when designing financial tools. An input screen assembled directly from symbols may be mathematically complete while still leaving users to decode which values belong there, which period each value covers and which assumptions shape the answer. A stronger approach begins with the financial question and treats the input experience as a task-specific contract. Viotus describes Calculator as starting from the question, grouping variables around the task and keeping inputs, assumptions and outputs connected for review. Those public principles support a practical design sequence that can be applied before any calculation runs.
Begin with the decision, not the equation
Write the user’s question in ordinary language before listing variables. ‘What will this balance become after a fixed period?’ establishes a different task from ‘What payment would repay this principal?’ even though both may involve rates and time. The question defines the result the user expects, the method that fits and the boundaries of relevant input. It also gives designers a test for every field: if a value does not help answer this question, it may belong in another calculation.
This boundary prevents a general-purpose form from accumulating unrelated fields. It also stops the interface from asking users to select a formula they may not recognise. Calculator’s public flow begins by choosing the calculation that matches the actual financial question. In implementation terms, that choice can select a versioned input contract rather than merely changing a label above one universal form.
Define a semantic contract for every variable
Each required value needs meaning beyond a data type. A useful contract records the field’s role, unit, time basis and whether it is required, optional or derived. A rate should say whether it is entered as a percentage, which period it represents and how often it is applied. A duration should identify its unit. A monetary amount should preserve its currency context without implying that the software has verified its external accuracy.
Names should follow the user’s task, while internal identifiers can remain stable for calculation logic. Help text should explain what belongs in a field, not repeat its label. Constraints can reject impossible formats or inconsistent combinations, but product copy should not suggest that validation proves a real-world figure is correct. The interface validates the contract it controls; the user remains responsible for the source values.
Group inputs in the order people reason
Task-specific grouping turns a list of variables into a readable path. Start with the object being examined, then establish timing, rates or growth conditions, followed by optional assumptions. For a comparison, repeat the same structure for each case instead of mixing values by mathematical symbol. The best order is not necessarily the order in which the formula consumes its operands; it is the order in which a person can confirm the scenario.
Progressive disclosure can keep secondary detail available without making it appear mandatory. Defaults need equal care: a prefilled assumption is still an assumption and should remain visible. If changing a unit or timing convention changes the meaning of another value, update the group as a coherent unit or ask for confirmation. Hidden transformations make fast entry possible at the cost of reviewability.
Calculator’s public catalogue makes the distinction concrete. A compound-interest task can group the starting balance with its currency, then the rate with its compounding interval, then the time horizon; a loan or mortgage task instead centres the amount borrowed and pairs its rate with a repayment schedule and term. Those are not two skins over a generic amount-rate-time form: the selected question determines what each value means and which values belong together. Preserve that selection, the entered units and assumptions, and the resulting calculation trace in the workspace so a later execution-history review can recover why the same-looking percentage was applied as a growth condition in one task and a borrowing condition in the other. This example is a design inference from Calculator’s publicly listed compound-interest, loan and mortgage tools, its task-grouped input flow, and its stated retention of workspaces, history and calculation traces—not a claim about a released interface.
Keep assumptions attached to execution
An input contract should produce more than a payload of numbers. Preserve the selected question, contract version, entered values, units, explicit defaults and calculation method together. That record lets a later review distinguish what the user supplied from what the interface derived. It also makes repeat execution safer because an old value cannot silently acquire a new meaning after a schema changes.
Show a compact confirmation before execution when the task carries several assumptions. Afterward, present the result beside the inputs and assumptions that produced it. This follows Calculator’s public principle that inputs and outputs remain connected enough to inspect. The aim is not to turn every simple calculation into a complex model, but to preserve the smallest complete explanation of the answer.
Review the contract before the formula
Test the design without calculating. Can a user identify the question, explain why every required field exists, recognise units and timing, and find every assumption? Can another reviewer reconstruct the intended scenario from the saved inputs? If not, numerical correctness will not repair the ambiguity. Fix the earliest unclear boundary before adding more warnings around the result.
A compact review checklist is: one explicit question, one suitable method, task-specific groups, semantic definitions for every value, visible assumptions and a retained connection between input and output. This approach does not verify external facts or replace professional judgement. It gives calculation software a clearer responsibility: ask for understandable data, apply a consistent method and leave enough context for the result to be reviewed.