How Error Messages Can Reduce User Frustration

The question is how the system absorbs cognitive and operational burden

Japan's digital support policy explains that age-friendliness extends beyond interface design to include offline instruction, proxy assistance, trusted identity verification, and fault recovery. Good products allow users to learn at their own pace.

“Explain what happened and what the next step is” is a proposition that evidence may support or overturn, not a conclusion established because a Japanese case exists. For how the system absorbs cognitive and operational burden, the analysis also tests “Do not use technical jargon, and do not attribute failure to the user” while retaining population, setting, period, failed cases and the current non-technical alternative.

What each source can and cannot establish

Evidence for “Do not use technical jargon, and do not attribute failure to the user” starts with publisher, year, population and method, and corporate statements need independent material or local testing before becoming outcome claims.

1. 01
   Japan Ministry of Internal Affairs and Communications: Digital Use Support Programme ↗

   Supports examining how digital capability support enters offline service and real tasks rather than relying on interface changes alone.

2. 02
   World Health Organization: Global Network for Age-friendly Cities and Communities ↗

   Supports evaluating health, transport, housing, participation and public services as one community system.

3. 03
   Cabinet Office of Japan: Annual Report on the Ageing Society 2025 ↗

   Provides the demographic, living, employment, health and participation context for Japan’s ageing society.

4. 04
   Japan Ministry of Health, Labour and Welfare: Promotion of Care Technology ↗

   Supports analysis of how Japan links care-technology adoption, workflow improvement, productivity and care quality.

Move from a feature to a complete accountability chain

An error message explains what happened, consequence, next action and help. Preserving input, undo and a clear recovery path matter more than codes or “failed”; repeated errors should trigger design change rather than demands for greater user care. Digital inclusion covers discovery, identity, comprehension, action, confirmation, recovery, proxy use and help. Large type addresses only one visual component.

Place the argument inside one observable task

Ask users with different abilities to complete login, verification, payment or settings without prompting; record pause, backtrack, error, help, abandonment and recovery before voice or proxy support. For this analysis, also record “independent completion”, “error recovery” and the non-technical method so that “Do not use technical jargon, and do not attribute failure to the user” can be attributed to the intervention rather than hidden support.

Success is not a completed demonstration. “Explain what happened and what the next step is” must remain understandable, interruptible and closable across routine, exception and unavailable states.

Transfer operating method and evidence discipline

Japan’s digital-use support shows that offline teaching, trusted assistance and real-task practice matter as much as interface.

Redraw accountability before selecting product form

Chinese super-app, QR, identity, verification and payment risk controls require bounded proxy access, non-smartphone or human channels and fraud-aware confirmation. China's super-apps and QR code scenarios are highly concentrated; special attention must be given to boundaries regarding accounts, verification codes, payments, and family proxy operations.

Use consistent measures across routine, exception and unavailable conditions

1. 01
   independent completion

   “independent completion” helps answer how the system absorbs cognitive and operational burden. For “Explain what happened and what the next step is”, keep device output, human confirmation and completed action separate, and investigate when the three disagree.

2. 02
   error recovery

   Review the work and waiting time carried by older people, families, support, product and risk teams around “error recovery”. Improvement in “Do not use technical jargon, and do not attribute failure to the user” that depends on permanent extra labour cannot be attributed to the intervention alone.

3. 03
   help requests

   “help requests” must include exceptions, refusal and unavailable-system cases. While testing “Explain what happened and what the next step is”, treating large type as complete age-friendly design means an improved average still triggers pause or reframing.

4. 04
   fraud controls

   Compare “fraud controls” with the same task, population, version and response rule. A material version change in this analysis requires a new baseline.

5. 05
   abandonment

   For “abandonment”, state the population, baseline and time window in this analysis, and retain “independent completion” so one attractive metric cannot conceal deterioration elsewhere.

For “Explain what happened and what the next step is”, the period for “independent completion” and “error recovery” covers weekends, nights, visitors, shift or environmental change. If “Do not use technical jargon, and do not attribute failure to the user” has health, safety or cognitive implications, it also requires predefined human review, professional referral and exclusion criteria.

Keep the conditions behind the decision traceable

Topic record: For “Explain what happened and what the next step is”, treat “Do not use technical jargon, and do not attribute failure to the user” as a judgment that field evidence may support or overturn.

Baseline record: Testing “Explain what happened and what the next step is” retains population, task frequency, current method, elapsed time, help, near misses and non-completion; independent completion and error recovery use one denominator and period around “Do not use technical jargon, and do not attribute failure to the user”, including refusal and failed cases.

Ownership record: Around “Explain what happened and what the next step is”, older people, families, support, product and risk teams receive distinct duties for choice, operation, confirmation, maintenance, payment and stop authority; every action testing “Do not use technical jargon, and do not attribute failure to the user” names an owner, deadline and fallback.

Exception-closure record: “Explain what happened and what the next step is” predefines “treating large type as complete age-friendly design” as a failed case and retains preceding conditions, version, human takeover, recovery time and impact; closure requires recovery of the life task behind “Do not use technical jargon, and do not attribute failure to the user” and human confirmation.

Change and exit record: After a change in threshold, place, people, shift, connectivity or service resources affecting “Explain what happened and what the next step is”, retain the reason, approver, new baseline and grounds under “Do not use technical jargon, and do not attribute failure to the user” for continuation, downgrade or exit.

Decision rationale: Continue, modify or stop decisions around “Explain what happened and what the next step is” cite source records, show how help requests and fraud controls support “Do not use technical jargon, and do not attribute failure to the user”, and retain unresolved uncertainty.

Review cadence: At pilot entry, first exception, version change and before scale, reassess “Do not use technical jargon, and do not attribute failure to the user” and compare independent completion, error recovery, help requests, fraud controls, abandonment under unchanged definitions.

Know when not to adopt and when to stop

The flow fails when security blocks the target user, proxy access cannot be revoked, voice lacks visible confirmation, or only customer support can recover an error. Retain a lower-technology, lower-burden and reversible alternative.

Five checks before procurement, pilots or partnerships

Turn overseas experience into local methods

For BEIIU / 辈佑, “Do not use technical jargon, and do not attribute failure to the user” becomes useful when it leads to clearer requirements, evaluation methods, accountability and exit conditions in product and partnership practice.