Health Business Services
Tobacco Reporting in the Department of Health, Disability & Ageing
4
User journeys prototyped
8
Months, from conception to launch
2
Components designed
8
Components documented with governance
Digitising how business partners interact with the department.
The Department of Health, Disability and Ageing (DoHDA) does business with many partners, including:
Internal business areas
Industry health partners
Australian Government departments
Regulatory agencies
Pharmaceutical companies
Medical device manufacturers
As you might imagine, there are many points of contact and many services that these partners would need access to.
It’s through the Health Business Services Portal (HBSP) - a transactional site which all these organisations interact with us. It serves as a secure, single-entry point for industry partners to access multiple services across the department.
The UX/UI team in our section designs all the services within the HBSP, including:
Hearing Services Online
Office of Drug Control
Therapeutic Goods Administration
Tobacco Reporting (TR) - designed by me
TR provides a collaborative reporting tool for the industry
scope & definition
Tobacco Reporting in the place where tobacco manufacturers meet their reporting obligations.
As part of the Public Health (Tobacco and Other Products) legislation, tobacco manufacturers and importers are required to report yearly on product ingredients, volumes and marketing spend.
I had ownership over designing TR, where I had the joy of:
creating all the wireframes
liaising with the client, business and a team of developers and business analysts.
designing and completing the governance for a number of components in the HBS design system.
The Tobacco Reporting service does the following:
Prevention & Early intervention: TR helps to keep the tobacco products supplied to Australians regulated and safe.
Creates a sustainable system: Delivering a platform for tobacco compliance that is flexible allows for future legislative changes and requirements.
Engages our people: TR platform engages and empowers the delivery team and stakeholders to deliver a robust and fit-for-purpose system in alignment with relevant legislation.
Data interoperability, sharing & exchange: Facilitating exchange of data between external entities and the department.
Uploading reports & viewing submissions
Information Architecture & Wireframes
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.
As part of the Public Health (Tobacco and Other Products) legislation, tobacco manufacturers and importers are required to report yearly on product ingredients, volumes and marketing spend.
Therefore, the TR service needs a function where users can submit reports.
My BA laid out the general requirements, and I worked with her to give shape to the following user journey:
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
Registering an organisation
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.
Reports are uploaded on behalf of an organisation. Therefore, there needs to be a process to register an organisation for the TR service, from which one can meet their reporting obligations. I worked with my BA to create a user flow meeting all the needs and requirements of the business.
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.
Manage organisation members & details
The TGA service already defined some patterns for organisation, contact and address management.
Naturally, I followed the same patterns for consistency and adjusted based on TR business’ specific needs and requirements.
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.