Medical Costs Finder
Department of Health, Disability & Ageing
60
Participants
3000+
Data points
53
Unique research findings
2
Concepts
What is Medical Costs Finder?
Medical Costs Finder (MCF) is a tool for the Australian Public to find and understand costs for medical specialist services across Australia. It works because medical practioners would voluntarily report their prices online.
The purpose of MCF is to:
Increase specialist price transparency by displaying typical prices for specialist services and insurers.
Allow patients to make more informed decisions about their care.
Traffic to MCF is estimated to increase
background
Our client was expecting a large influx of people to begin visiting the site. This is because new legislation made the previously voluntary reporting of the cost for medical services, obligatory.
Historically, there had always been low levels of voluntary price disclosure from specialists and insurers but now there would be far more data available online.
There has been previous user research on the MCF website experience done by the Health Design Lab.
My team and I were assigned to inform a redesign of the MCF website. The future MCF website would support increased medical specialist price transparency and empower Australians to make more informed healthcare decisions.
Mobile usability testing was selected for this project as it reflects how most people access the site, with 59% of traffic coming from mobile or tablet devices.
Two mobile-based prototypes (Option A & B) were created and tested with 60 participants using task-based questions. Both qualitative and quantitative data collected during testing sessions have been presented in this findings report.
Overall, participants supported the purpose of the MCF website, indicating a strong public appetite for clearer information on medical costs. However, several friction points were identified:
Navigating the site and understanding how different service offerings connect.
Comprehension of information, with certain terminology requiring higher levels of health literacy to understand.
The utility of generic ‘typical’ information versus personalised information.
Following usability testing sessions, the MCF website prototype was refined to address key pain points and unmet user needs observed during these sessions.
Research objectives
Research
Based on this, I began creating a set of wireframes using the components made by fellow designers thus far, as well as the patterns and layouts they established in other services.
Goal 1: Explore how the MCF website can be redesigned to ensure a seamless user experience that aligns with upcoming policy changes by testing a proposed future state website with users.
Goal 2: Assessing the current MCF website and the Design Lan design proposals against best practice usability heurestics to inform the conceptual prototype to be used in testing.
Goal 3: Capture reccomendations to inform the delivery of future MCF website enhancements that would ultimately increase website traffic (especially to individual specialist fees).
Gathering real user feedback to make data-driven decisions align with whole-of-government standards such as the Digital Experience Policy and Digital Service Standard.
Signing into the portal
Viewing all linked and available services
TR Home
Record of all previous submissions and drafts, and option to create new
Report submitted
Methodology
50 consumers
Primary user cohort
For example:
A person seeking information about the expected out-of0pocket costs for a colonoscopy performed by a local private specialist
Option B
Larger changes to the website user interface.
Introduces a multi-funnel website model, creating shortcuts to particular information and allowing more flexible, less linear user journeys within the set paths. The funnels has been designed around the following user tasks.
Service funnel: User has not received a specialist referral and wants to find out the typical cost of a service.
Specialist funnel: User has received a specialist referral and wants to check what that specialist’s fees are.
10 general practitioners
Secondary user cohort
For example:
A GP informing a patient about the expected out-of-pocket costs for a medical procedure.
59% of traffic to the MCF website comes from mobile or tablet devices. We ran mobile usability tests due to this, and quoted the client for mobile prototypes only.
Two mobile-based prototypes (Option A & B) were created and tested with 60 participants using task-based questions. Both qualitative and quantitative data collected during testing sessions have been presented in this findings report.
Option A
Largely follows recommendations outlined in the Department’s Design Lab proposals and findings, with modifications based on heuristic review outcomes and business feasibility.
Sticks to the status quo, maintaining a similar look and feel to the current site as well as a similar progression through the site. This progression is described as a singular ‘funnel’, with users stepping uncovering more information related to a service as they progress.
50
Consumers
10
General Practitioners
2
Prototypes, as part of A/B test
3
Tasks
60
Participants
3000+
Data points
53
Unique research findings
2
Concepts
TR Home
User clicks 'create organisation account', to begin a multi-step form
User begins form
Platform connects to RAM to verify user's relationship to the organisation.
Details retrieved
User works their way through multi-step form.
User reaches end of form.
Request is sent to the administrator.
Analysis
A lengthy analysis left my team with almost 3000 data points. From this, we extracted over 50 unique findings relating to service costs, specialist fees, insurer costs and general content.
44+
Hours of interviews
1700+
Qualitative data points (and 1000+ Quant)
419
Observations
53
Unique research findings
User selects 'My organisation'
User can manage contacts and addresses (editing only for administrators) and view their details
Addresses
Contacts
Personal details
Components I designed - Blob storage
Problem
In the multi-step form when submitting a report, users need to upload files. Whilst all other services in HBSP use a Sharepoint storage component, TR alone uses Azure storage instead. This is because the service needs to support up to 3 files greater than 150mb, due to the hefty templates used for report submissions.
This brought about a new technical challenge however, as the Azure storage file plugin is made in a way where two discrete components are stacked directly on top of each other yet don’t communicate with each other in the Out-of-the-box design. This is represented below as ‘Uploaded files’ and ‘upload files’ in the image below.
Any files uploaded won’t appear under ‘uploaded' files’ until the page refreshes.
Design system and UI
Because these two sections don’t communicate with each other, it creates a usability issue where uploaded files won’t show under the ‘Upload files’ section unless the page gets refreshed.
This is problematic, because users wouldn’t get feedback that their files were uploading and secondly, the File upload component looks different in other parts of the platform which uses the standard Sharepoint storage system instead of Azure.
I needed to address this usability issue.
Solution
Because the blob storage component was used in a multi-step form, and the ‘uploaded files’ part of the component would take technical effort to remove or modify from its out-of-the-box state, the new design component I created would use a callout explaining to the user when they could expect the files they uploaded to appear - when they continued or saved the step they were in.
To provide immediate feedback to users that their files are uploading, they would show under the ‘Add file’ section, and change appearance once uploaded.
If the user refreshes the page, or continues to the next step and returns to the step, they can see their uploads under ‘Uploaded files’.
I was fortunate to join the team when the foundations for the HBS design system had more or less been established. Colours, fonts, buttons and most of the other atoms and molecules had already taken shape, and so my responsibilities fell more so in giving definition to the organisms, templates, pages and creating prototypes
Components I designed - Table v2
Problem
Solution
I liaised with our design lead and a fellow designer to explore some options for the action column inside table components
-
Each row contains a dedicated icon (e.g. kebab or ellipsis) that exposes actions.
Pros
Familiar interaction pattern
Keeps actions visually associated with the row
Cons
Increases maintenance overhead as action complexity grows
Leads to overloading a single control with too many responsibilities
No longer a common or recommended pattern for complex tables
Would require additional user testing to validate usability
Assessment: This approach does no scale well and introduces ongoing maintenance complexity.
-
Impose a strict upper limit on the number of actions to ensure the menu fits within the table boundary
Pros
Simplifies positioning logic
Avoids layout breakage in theory
Cons
Relies ton teams adhering to design rules - historically unreliable
High risk of rule violations over time
Does not account for legitimate use cases requiring more actions.
Assessment: This is brittle and unenforceable in practice
-
Allow rows or the table to grow vertically when menus are opened.
Pros
Keeps all menu items visible
Avoids overflow outside the table
Cons
Creates large amounts of unnecessary white space
Poor experience when menus are not in use
Unbounded growth if rows contain 10+ actions
Pages become excessively long and visually noisy
Assessment: Solves one problem but introduces significantly layout and usability issues.
-
Replace the OOTB Bootstrap table with a more flexible or custom table component.
Pros
Greater layout and interaction control
Could solve the problem more ‘cleanly’ from a technical standpoint
Cons
Teams strong prefer OOTB components
Higher implementation effort
Increased maintenance and support burden
Adoption resistance from project teams
Assessment: Not viable due to adoption and maintenance problems
-
Use JavaScript logic:
If menu items ≤ 3 → show overlay menu
If menu items >3 → switch to inline accordion
Pros
Optimises UX for small and large menus
Keeps compact interactions where possible
Cons
Heavy JavaScript complexity
Unrealistic for CRM and delivery teams to maintain
Difficult to test and debug
High implementation cost across all tables
Assessment Technically possible but operationally unrealistic.
-
Each table row can expand vertically (accordion-style) to reveal actions inline.
Pros
Scales to support 10+ menu items without layout issues
Keeps all interactions within the table boundary
Predictable, accessible interaction pattern
Only requires JavaScript from a frond-end perspective
Allows enhanced visual cues:
Icon changes (chevron up/down)
Colour or state variations for emphasis
Cons
Requires JavaScript (though limited and manageable)
Slightly different interaction from traditional tables
Assessment: THis approach is scalable, robust and aligns with modern UI patterns. It balances usability, technical feasibility and long term maintainability.
Once settled on converting rows in accordions, we came up with the following variations. After consulting with the rest of the designers in the UX/UI team, we settled for Option 4 (see below).
When one of my developers were enabling the tables in the TR platform, he noticed that the modal in the action column would hide in some screen sizes.
Action menu items triggered at the bittom of the table, hide within the frame of the table. This is especially the case in a mobile view.
I reached out to our Design Engineer to see if he could update the design system so that the modal functioned like an overlay, displaying over content instead of hiding within the frame of the table component.
There were technical restraints to this however - the Out-of-the-box (OOTB) Bootstrap tables render action menus using absolute positioning. As a result, menus must remain within the table boundary and cannot overflow beyond it. This in turn created usability, layout, and scalability challenges - especially when rows contain multiple actions.
Tables are widely used across the HBSP platform, not just the TR service and so any solution must be low-maintenance, scalable, and realistic for delivery teams to implement consistently.
Option 1: Chevrons, left aligned, and no icons (but we can have them). Hover indicated by a thicker line.
Option 2: Keeps ellipsis icon, left aligned, each action is a text button, hover state has an underline and background colour applied when cell opens.
Option 3: Similar to option 1, except action is a text button
Option 4: Similar to option 2, but with cell background in a hover state.