Designing Error Reporting Instead of Forcing Users Into Support Work

While submitting a health insurance overpayment refund request through the Polish ZUS PUE portal, I encountered a blocking issue in the form flow.

The system required selecting a previously registered bank account from a dropdown list, but:

  • the expected account was missing,
  • the account input field was disabled,
  • manual input was impossible,
  • the system returned “No results found” without explanation,
  • the form could not be completed.

At first glance, this looks like a simple UI bug.

It is not.

The issue exposes a broader systemic problem common in large administrative platforms:
the burden of diagnosing errors is shifted entirely onto the user.

Instead of helping users report issues with context, the system forces them to become investigators, technical writers, and support agents simultaneously.

The Problem

The form flow created multiple layers of uncertainty:

  • Is the account missing because of synchronization?
  • Was the bank account removed from the system?
  • Does the user need to submit another official form first?
  • Is this a frontend issue?
  • Is the backend returning empty data?
  • Is there a temporary outage?
  • Is the account invalid?
  • Is the dropdown component broken?

The interface provided no contextual explanation.

error-zus-folmularz

Only this:

“No results found.”

The user is then expected to:

  • manually describe the issue,
  • explain where it occurred,
  • reproduce steps,
  • attach screenshots externally,
  • communicate with support asynchronously,
  • and hope the support team understands the context.

This creates friction for both sides:

  • users become frustrated,
  • support teams spend time reconstructing the issue,
  • developers receive incomplete bug reports,
  • organizations lose operational efficiency.

UX Observation

The core issue is not the dropdown itself.

The issue is the absence of integrated contextual reporting.

The platform contains no direct mechanism for:

  • reporting interface problems in-context,
  • attaching visual evidence,
  • automatically sending system metadata,
  • identifying the affected component or form state.

The user leaves the product flow and enters a separate support process.

This breaks continuity and increases cognitive load.

Proposed Solution

Global “Report a Problem” Entry Point

A persistent icon in the application header would allow users to report issues directly from the affected screen.

Instead of asking users to explain technical context manually, the system would collect it automatically.

Proposed Reporting Flow

1. Trigger Reporting Mode

The user clicks:

“Report a problem”

An overlay activates. 

UX concept showing a contextual “Report a Problem” overlay in the ZUS PUE government platform, allowing users to capture screenshots or select interface fragments directly from the form view.
UX concept screen showing contextual issue reporting in the ZUS PUE platform, where users can capture the full screen, select an interface fragment, or record a short interaction while the system automatically attaches technical metadata, frontend errors, API failures, and browser information.

2. Capture Context

The user can:

  • capture the full screen,
  • select a fragment,
  • optionally record a short interaction.

The system automatically attaches:

  • current URL/view,
  • form identifier,
  • component identifier,
  • session metadata,
  • frontend errors,
  • API failures,
  • browser/environment information.

No technical knowledge required from the user.

3. Lightweight Input

Instead of writing long descriptions, the user answers two simple prompts:

  • What were you trying to do?
  • What happened instead?

The barrier to reporting drops significantly.

UX concept screen showing a lightweight issue reporting form in the ZUS PUE platform, where users answer two simple prompts about what they tried to do and what happened instead, reducing the complexity of reporting system problems.
Support dashboard UX concept for the ZUS PUE platform showing structured issue reporting with screenshots, technical metadata, frontend errors, reproduction context, and user descriptions to reduce ticket handling time and improve issue diagnosis.

4. Support Receives Structured Context

The support team receives:

  • screenshot,
  • exact screen location,
  • technical metadata,
  • reproduction context,
  • user description.

This reduces:

  • back-and-forth clarification,
  • ticket handling time,
  • issue reproduction cost.

Why This Matters

This is not only a usability improvement.

It is an operational improvement.

Well-designed reporting systems:

  • reduce support workload,
  • improve debugging efficiency,
  • increase issue reproducibility,
  • shorten resolution times,
  • improve trust in the platform.

Most importantly:
they stop forcing users to perform diagnostic labor.

Design Principles

This case demonstrates an important shift in UX thinking:

From:

designing forms

To:

designing recovery systems

Good enterprise and government UX is not only about successful flows.

It is about what happens when systems fail.

The quality of error handling often defines the quality of the entire experience.

Key UX Themes

  • Error-state design
  • Recovery flows
  • Operational UX
  • Administrative systems
  • Support workflow optimization
  • Context-aware reporting
  • Cognitive load reduction
  • Enterprise UX thinking
  • Government digital services

Outcome

The experience became a strong example of how:

  • missing support tooling creates operational friction,
  • generic error states increase uncertainty,
  • and small UX interventions can significantly improve both user experience and organizational efficiency.

This case reframed a simple dropdown issue into a broader systems-thinking problem:

how public platforms unintentionally outsource troubleshooting to users.

© Zofia Szuca 2024
Brand and product designer