Improving the document upload experience in a government health app — reducing claim rejections through smarter error design.
Overview
The Medicare Online App lets Australians submit healthcare claims digitally — a high-stakes, high-volume service that millions of people rely on. When it works, it's seamless. When it doesn't, the consequences are real: delayed reimbursements, eroded trust, and people struggling to access healthcare services they're entitled to.
This project focused on one of the most common failure points in the app: claim rejections caused by document upload problems.
The Challenge
Users were getting their claims rejected — not because of eligibility issues, but because of avoidable documentation errors. Blurry photos. Missing receipts. Unpaid invoices uploaded instead of receipts. Each of these resulted in a rejection that felt sudden, confusing, and unfair.
The frustration was compounded by context: people submitting Medicare claims are often dealing with health issues, time pressure, or both. A poorly designed error experience here isn't just a UX problem — it's a trust problem.
The opportunity was to design around the introduction of Intelligent Document Processing (IDP) — technology that could automatically detect document issues before a claim was submitted. The design challenge was to use that capability to intervene earlier and more usefully in the user flow.
What IDP Changes
IDP automates the extraction and validation of information from uploaded documents and images. In this context, that meant the system could now detect whether a document was a paid receipt or unpaid invoice, whether an image was too blurry to process, and whether required documentation was missing.
The question wasn't whether to surface these errors — it was when and how to surface them in a way that actually helped users correct the issue.
Research & Testing
We tested three distinct scenarios to understand where the experience was breaking down.
Scenario A — Unpaid invoice, no receipt: IDP flags the document as an unpaid invoice. Findings: users were frustrated not by the message itself but by when it appeared — at the very end of the flow, after significant effort had been invested. Recommendation: introduce an earlier checkpoint before the upload flow that proactively confirms the user has a paid receipt ready.
Scenario B — Unpaid invoice uploaded alongside a receipt: IDP recognises the invoice but not the receipt. Findings: users were genuinely confused — they'd done what felt like the right thing and still hit an error. Help messaging was largely ignored. Recommendation: rewrite error copy to be specific about what was found and what's missing.
Scenario C — Blurry image uploaded: IDP detects insufficient image quality and prompts a retake. Findings: the screen was clear and well understood — users knew what to do. The problem was persistence: users would attempt 2–3 times before giving up, and the "Need help?" option offered no practical guidance. Recommendation: replace the generic help link with actionable photo tips, and limit sequential blurry-image roadblocks before offering an alternative path.
Key Design Principles
Intervene early, not at the end: Surface blockers before the user commits to a flow, not after effort has been invested.
Be specific in error states: "We can see an invoice but we need the receipt" is useful. "Something went wrong" is not.
Make the help actually helpful: If a help prompt doesn't provide actionable information, it erodes trust faster than having no help at all.
Respect the user's effort: The language and design of error states should feel supportive, not bureaucratic — especially in a health context.
Outcome
The IDP integration — with the UX improvements designed around it — reduced the likelihood of avoidable claim rejections and improved user confidence in the upload process. This was a project where the technology was already capable of solving the problem. The design work was about making sure that capability reached users in a way they could act on.
Due to NDA restrictions, screens are not shown.