7 min read
App & Web2026 — Product Designer & Strategist

Swiftio: Age Care just got a lot more mobile

Role
Embedded Product designer & strategist
Team
Swiftio Engineering Team
Timeline
2026 — Present
Platform
Responsive Web + Android App

Executive summary

60-second read
Problem
Three portals, doctor, nurse, and facility manager, had each grown feature by feature on a shared generic template and an early platform vendor not built for scale.
Hypothesis
If the product were rebuilt around what each role actually does, on a codebase the team owned outright, it could serve all three properly and absorb future capability without doubling in size.
Solution
A full revamp across all three portals, paired with a move off the early platform vendor onto an in-house codebase.
What changed
All three portals now reflect their role's real working context. Post-launch numbers are still being collected, that gap is addressed honestly in the closing section.

01 — Context

Swiftio supports aged care teams across Australia: GPs moving between patients, and nurses and facility managers coordinating from a desk. I joined from Kaizer Studios as the embedded design partner, working directly with the founding and engineering team across all three portals.

02 — The problem

The doctor app, nurse portal, and facility manager portal had each grown one feature at a time, on a shared generic AI design and an early platform vendor chosen to move fast in the beginning. As the product needed to scale and prepare for larger partner capability, staying on that path risked slowing the team down just when speed mattered most.

Fig 01Before state.

03 — Constraints

  • Medicare billing is API-driven. The item numbers, IRN, and billing codes needed for a valid claim are fixed by the API itself, not something to simplify or redesign around.
  • The early platform vendor was chosen to move fast at the start, but wasn't built for a scaling startup, and staying on it risked slowing the team down right as two partner integrations approached.
  • Three roles, three working contexts: mobile bursts for doctors, desk sessions for nurses and facility managers.
  • The revamp had to ship without breaking a live, already installed product.
  • Two confidential partner integrations were in early conversation during this period and can't be named here.

04 — What we learned

Watching all three roles work made the gap obvious. Doctors move in short bursts, one ticket, one decision, moving on. Nurses and facility managers work in longer sessions, reconciling across a whole facility. A single generic template, on a platform not built for the team's pace, served none of them well.

Fig 02Generic AI design that lacks design principles.

05 — The move

I revamped the interface across all three portals, tailoring each to how that role actually works, and pushed as product manager to leave the early platform vendor for a codebase the team could own and control outright. Staying on the original platform would have cost the team speed at exactly the point they needed it most, right as two larger partner integrations were coming into view. My designs, originally built for the old platform, were structured cleanly enough to carry over without a redo.

06 — What shipped

  1. AA full UI revamp across all three portals, doctor, nurse, and facility manager, each tailored to its role.
  2. BThe decision to leave the early platform vendor for an in-house codebase, protecting the team's speed ahead of two upcoming integrations.
  3. CA QA process tied to documented user stories, using a screenshot based review tool to check flows against acceptance criteria.
  4. DOngoing refinements from live doctor feedback, cleaner layout, faster access to patient demographics mid-visit.
Fig 03Shipped UI.

07 — Tradeoffs

Leaving the early platform meant pausing feature work to migrate, at a point when the product surface was still small enough to move cleanly. Waiting until later, once more features and two partner integrations had landed on top of it, would have made the same migration far more expensive. The cost was paid early and on purpose, while it was still cheap to pay.

08 — What changed

3
distinct use case portals optimised for the respective user
2
large corporation partnerships lined up

09 — What's still open

Two confidential partner integrations were in early conversation during this work. I'm now the design lead on one of them. There's no outcome to share yet since it's pre-launch, and that gap is intentional rather than glossed over.