Making care budgets clear enough to act on
A compliance deadline asked for a clearer budget page. Customer evidence showed that clarity was not enough. I led the work from discovery through several releases, turning an opaque summary into a journey customers and staff could check, investigate and act on.
One connected financial journey across HomeMade's staff and customer portals: understand how someone is tracking, trace the expenses behind it and act before the position gets worse.
Customers were checking the portal against statements and government information. Staff had to reconstruct the same position when someone asked for help.
The interface was only one layer. Trust depended on traceable expenses, defensible definitions and calculations that matched the service reality.
I split one page into Expenses, Utilisation and Funding, set the build order, and replaced Funding with one explanation in context.
Expenses is live for staff and customers. Customer Utilisation is live for ongoing services, and fewer customers overspending is the measure from here.
One financial problem.Two connected experiences.
HomeMade helps older Australians use government-funded aged care at home. I led Budget & Expenses and the related staff tools from customer research through later releases.
See spending against the budget in the care plan.
Move from a service to the expenses behind it.
Understand the charge, ask for help or review the plan.
See where actual spending is moving beyond the plan.
Trace services, claims and funding in operational detail.
Explain the position and support a care-plan conversation.
The same financial model serves both journeys: plain language and confidence for customers; enough detail for staff to reconcile a position and explain it.
Customer portal
Two connected experiences.
Customers can check their budget, investigate the services behind it and trace the expenses that explain their position.
The brief asked for compliance.Customers needed something they could verify.
The request was to update the interface for Support at Home. I pushed for discovery because new terminology and layout would not solve distrust in the numbers.
I ran four customer testing sessions in 2025, and combined them with support-call transcripts, internal interviews and earlier research. Together they established what the experience needed to answer. Customers were reconciling the portal against statements and government information because they could not explain a balance, tell whether a transaction had been processed or understand why two sources differed.
A visible balance did not explain whether a transaction had been processed or why two sources differed.
The experience needed to expose how the financial position had been derived.
I changed the question from presenting the balance to helping someone verify it for themselves.
Clarity, derivation, accessibility and independence became the principles. A summary could not replace the transactions underneath it.
Ship the top summary, then return to the detail
The November 2025 deadline put a hard limit on the first release. The business chose to ship the top summary only. I agreed it was the right call for the deadline, but pushed for a commitment that the itemised detail would follow: a summary cannot explain a budget if customers cannot check what sits underneath it.
Customer evidence defined what the experience needed to answer.
A simpler summary met the regulatory deadline.
Support evidence kept the deferred detail visible.
Discovery & MVP
The full-page exploration established the direction. The first release met the deadline while keeping the deferred detail visible.
Support evidence still showed confusion after launch. When the work returned in 2026, I continued from the original research instead of starting another visual redesign.
The page was only one layer.The model underneath had to change.
By July 2026, overspend was growing and compounding. The business gave us one quarter, engineering included, to stop it, which left about six weeks for discovery and design. In roughly a day and a half, I revisited earlier research, support calls and customer feedback, reviewed the live product with Engineering and checked programme rules.
For the business, every undetected overspend was money it had to recover from customers, or absorb.
I turned the evidence into confidence-rated themes and hypotheses. The strongest need was traceability: customers needed to see which charges had changed their financial position. The visible page was only one layer of the problem.
How the information is shown.
What each number and status means.
How charges and funding produce the number.
Delays and gaps between care delivered and costs appearing.
The earlier redesign had concentrated on presentation. My reframe showed that another dashboard would not fix unclear definitions or calculations.
Two ways to overspend, and a safeguard nobody used
The evidence showed two routes into overspend: off-plan purchases, and planned services that cost more than the plan assumed. Both were hidden by invoice lag. Services appeared days or weeks after delivery, while an existing overspend banner had been switched off.
I found another safeguard nobody was using. Our operating procedure said to plan only 90% of a customer's funding and hold 10% as a buffer. The platform measured against the full amount, so an overspend left no room to catch it.
Two causes sat outside design: care needs beyond the funding level and internal delays in actioning a customer's request. I named them so the scope stayed honest.
Invoices arrived late, and the warning had been switched off.
They needed to see an overspend while there was still room to act.
Use the 10% buffer as the early warning.
One page could not answer three questions.So I split it into three jobs.
The old Budget & Expenses page tried to explain what customers had, what they had spent and how they were tracking, all at once. I proposed Expenses, Utilisation and Funding, then set the order to build them.
Recover first, prevent next
- Expenses: what has been charged, and was it planned?
- Utilisation: how am I tracking against my care-plan budget?
- Funding: what makes up my funding?
Expenses came first because it helps recover overspend that has already happened and gives every later view a number people can check. Utilisation came next, moving from recovery to prevention while there is still room to act. Funding came last, and only if it earned its place. Each page went to staff before customers, because the data starts with staff and they need to explain a number before customers see it.
I designed separate itemised views for staff and customers. Dates, providers, amounts and statuses let both groups investigate a charge. Staff needed to scan, filter and reconcile claims; customers needed plain service descriptions, visible processing states and financial detail only when it explained the charge.
Expenses
Itemised expenses give customers and staff a financial record they can check.
I built coded prototypes with production components and worked through edge cases with Engineering while finance specialists checked the rules. Reviews focused on behaviour: expanded rows, unfunded amounts and customer-facing statuses.
The staff ledger shipped first, followed by the customer ledger. The work turned the 2025 research into an operational journey: notice a problem, trace the transactions behind it and explain what happened.
The difficult work sat underneath the UI.Definitions, models and scope.
Once Expenses made spending traceable, three decisions set the reference point, model and scope.
Use the care-plan budget as the reference point
Total funding and the amount planned for care were different. An allocation could look reassuring while planned services were already running beyond budget. I argued that utilisation should measure actual spend against the care-plan budget because customers and staff could act on it.
I'd found the 90% rule in our own procedure. The pushback was that customers would be confused to see less than their funding. I used feedback-channel evidence to show that customers want to know what they can safely spend, not what they've been allocated. After two days of back and forth, the CEO agreed, and it became the utilisation model.
Total funding
What has been allocated to the customer.
Care-plan budget
What their planned care is measured against.
Each service got one of five statuses: not started, under spend, on track, close to limit or over plan, with a warning from 81% and an error above 100%. Staff spend about 90 minutes on a care-plan review, so the page lists every planned service, keeps unplanned spend separate and shows whose plan to review first. For items paid from several funding sources, I explored cards, a stacked table and a tree table. The table was built first, then replaced by cards that held several sources without breaking the layout.
Staff portal
Planned services, status signals and unplanned spend make the next action visible.
Move away from “committed funds”
The platform deducted “committed” funds before they were spent, creating numbers customers could not reconcile. Programme documentation showed it was a regulated term for funds held against items ordered but not yet delivered. The model, not the copy, could mislead people.
I pushed to move away from the concept and proposed alternatives. The first release that removed it was rolled back because the calculation errors remained underneath, proving the display and logic could not be fixed separately. The business chose the direction I had pushed for.
Question the separate Funding page
After the split, I questioned whether customers needed a third destination. Another number for the same money risked recreating the reconciliation problem.
I explored the page, then recommended dropping it after comparing customer value with the extra complexity. The team adopted the direction. The essential content became an explanation of the budget calculation, placed where customers were already using it.
Budget explanation
The calculation lives in context, without introducing another destination.
Shipped in stages.What the releases showed.
Expenses shipped for staff and customers. Budget Utilisation followed, with the customer experience starting on ongoing services. I stayed with the problem across releases rather than treating the first launch as the end.
The evidence also arrived in stages. Four customer sessions informed the 2025 direction. Support-call synthesis and the open feedback channel showed where confusion continued. I used coded prototypes for engineering and behaviour reviews. The first release went to customers who were already overspending, with the feedback channel open. After release, I drew on staff reconciliation feedback, the Customer Advisory Group and customer comments. Now I'm running six customer sessions through Askable, on the live pages and prototypes of what's next.
Expenses is live for staff and customers. Customer Utilisation is live for ongoing services.
A staff member completed three reconciliations and reported that the figures matched each time. Customer Advisory Group feedback described the same improvement.
That is the real measure, and what I am tracking now that customer Utilisation is live.
The work changed how I approach financial products. I now test a number's definition and calculation alongside its interface, bring directions to customers earlier and document consequential model changes while the rationale is fresh.