Energy-App Estimates: How Should Users See Assumptions?
An energy estimate is only useful when people can see its inputs, calculation date and uncertainty. Design the explanation before presenting a projected bill or saving.
When energy prices and usage rules are in focus, an app that compares possible bills may help users ask better questions. But a projected amount can easily be mistaken for a bill, a promise, or a guaranteed saving. The product challenge is not simply to put a number on a screen: it is to show what that number depends on, how current the inputs are, and what remains uncertain. Google Trends NL’s 24-hour signal included energy-pricing stories, providing timely context for this durable design question. The practical test is straightforward: can a user understand and change the assumptions before acting on an estimate?
Make the estimate’s inputs inspectable
Start by identifying the inputs that materially affect the result, rather than burying them in a generic disclaimer. Depending on the product’s available data, these might include the selected tariff, the period covered, expected consumption, standing charges, taxes or other included components. Label each input in language a customer can interpret, and distinguish user-entered values from imported or default values. If an input is unavailable, say so instead of quietly substituting a value that looks authoritative. The screen should make it possible to answer: what did the app use, where did it come from, and can I change it?
Show the assumptions next to the estimate, with a clear route to details. A compact summary might say “Based on your saved tariff and monthly usage estimate,” followed by expandable rows for the selected plan, usage amount and calculation period. Do not assume that users remember information entered in an earlier setup flow. If a value is inferred, label it as an estimate; if a user supplied it, identify it as user-provided. This distinction matters for both trust and support: when a figure seems wrong, the person should be able to find the input to review rather than treating the total as an unexplained system output.
Treat the input model as product scope, not just interface copy. Decide which values users may edit, which require an external source, and what happens when a source is missing or a tariff’s effective period is unclear. Preserve enough calculation context to reproduce the displayed result, including the relevant input values and calculation version. This gives product and engineering teams a consistent basis for explaining changes when an input is corrected. For an MVP, it may be more credible to support a small, explicit set of user-controlled assumptions than to suggest comprehensive coverage that the available integrations cannot support.
- Checklist: label each input, identify its source, show its period, and make editable values easy to review.
Show uncertainty, dates and scenario boundaries
A single precise-looking total can overstate what the app knows. Explain uncertainty in proportion to the estimate’s limitations: for example, show a range when usage is variable, or identify the specific missing input that prevents a reliable comparison. Avoid adding a broad “not guaranteed” warning while presenting an unsupported exact figure elsewhere on the screen. If the product cannot calculate a meaningful range, use plain language to describe what the estimate excludes or assumes. The goal is not to make every result look uncertain; it is to help users distinguish measured or supplied data from projections and incomplete information.
Put the calculation date and relevant data dates where users can see them without searching through settings. These dates answer different questions: when did the app calculate the figure, and how current are the inputs it used? Where relevant, also show the period the estimate covers and the effective date of the selected pricing information. If inputs have not refreshed, mark them as potentially out of date and explain what action is available, such as reviewing a saved value. A timestamp alone is not a freshness guarantee; describe its meaning and avoid implying that the estimate reflects a current bill unless the underlying data supports that claim.
Keep scenarios separate from forecasts and outcomes. A comparison might let a user change an assumed usage level or select a different pricing scenario, but it should identify the change and hold other inputs constant when that is what the calculation does. Label the result as a scenario, not a prediction of what the user will pay. Do not turn a hypothetical difference into a guaranteed saving: actual charges can depend on values the app does not control or know. Make the comparison reversible, show the baseline, and let the user see which assumptions changed between the two figures.
- Checklist: display calculated-on and input dates, identify excluded items, and label every comparison as a scenario.
Validate the explanation as part of the MVP
A useful first release can focus on one understandable question: how does this estimate change when a user changes one clearly defined assumption? Before building multiple integrations or a wide tariff catalogue, map the calculation inputs and agree which ones the product can substantiate. A hypothetical MVP could let users enter an expected usage figure, select from a limited set of explicitly dated pricing assumptions, and compare two labelled scenarios. This is a proposed example, not a description of an existing service. The scope is valuable only if the app can explain each included value, the calculation period, and the limitations of the result.
Test comprehension, not only arithmetic. Give representative users an estimate and ask them to identify the inputs, the calculation date, what the total includes, and whether the displayed difference is guaranteed. Include cases with missing data, changed assumptions, stale pricing information and a recalculated result. Verify that screen readers can reach the explanation and that important distinctions do not depend on colour alone. Engineering QA should also check that the detail view and summary use the same inputs and calculation version. If the number changes, the explanation must change with it; otherwise a technically correct calculation can still mislead.
Define release criteria around traceability and honest presentation. A scenario should be reproducible from its recorded inputs; a changed input should be visible; and unavailable or outdated information should produce a clear state rather than a confident-looking total. Product, design and engineering should agree who owns the source information, how updates are represented, and what support teams can inspect when users query a result. These requirements affect integrations, data storage, testing and ongoing operations, so include them in project estimates. They are not optional polish added after the headline number is built.
- MVP decision: ship only the scenarios whose inputs, dates, calculation and limitations the team can explain and test.
An energy-app estimate earns trust when users can inspect the inputs, understand the uncertainty and see when the calculation and its data were current. Treat those explanations as part of the calculation contract: define them alongside integrations, data handling and QA, not after the total is designed. Start with a narrow scenario that the team can reproduce and explain. If a user cannot tell an estimate from a bill or a hypothetical saving from a promise, the product needs clearer assumptions before it needs more features.