The solution
To bring structure and clarity, the overview had clear, sequential tasks visualised in a linear progress bar, letting owners and reviewers instantly see whats done, whats next, and where things stand. This step-by-step view reduced cognitive load, supported faster decisions, and built a foundation that can flex as business needs grow.
The relevant asset stays visible on the left while workflow actions sit on the right, reducing context switching and improving task accuracy by keeping users in the same place.
Used predefined outcomes and clear instructions, to ensure consistency, reduce ambiguity, and make auditability straightforward by automatically capturing the user and action metadata.
Many of these workflows involved layers of hierarchical decision-making, and users still struggled to see how one decision affected the next. So the overview evolved into a single, centralised view of those decision layers and dependencies, letting users see the bigger picture at a glance, navigate complex flows with confidence, and act faster.
While the initial use case was straightforward, I designed the task segmentation and progress tracking with future complexity in mind—ensuring the structure could accommodate branching workflows, multiple assignees, and conditional logic as the product scales.
Semantic structure, keyboard navigation and screen-reader paths were mapped and documented, and QA treated accessibility as a condition of completion.
Impact
Structured steps, embedded documentation and clearer ownership meant a process could be audited as-is.
Stakeholders could update a workflow without deep technical knowledge, which reduced mistakes.
Process owners could see who was responsible for what, and when.
A simpler interface helped people complete complex processes with more confidence, and they favoured it over what they had.
The process
Problem
At its worst, three teams running the same formula in three spreadsheets produced three different numbers for the same data. That was serious enough that APRA raised Macquarie's liquidity coverage ratio and held back more than $6B in operational capital.
MARS was the response, and Workflows was the part that took the manual processes underneath it — from an analyst tracking a number to the scenario analysis behind buying an airport — and gave them segmented, auditable structure.
Process
Across the work I used AI to synthesise research and capture decisions in product sessions, so more of my time went to the design itself.
The business
I engaged product owners, senior managers, directors and business-team representatives, and reviewed process maps and standard operating procedures. I didn’t have access to broader strategy documents or OKRs, so I grounded the work in the process artefacts and compliance requirements I could actually see.
The platform
The tool was Unqork, with limited design flexibility. I explored its constraints and integration needs early so the MVP — the Analyse, Review, Publish flow for the Daily LCR Analysis — was feasible from the outset rather than a nice idea we couldn’t build.
The users
The personas I inherited were outdated — built through biased analyst research or diluted as they were retold. I ran a workshop with the first real users to map their routine and exceptional processes and undocumented workarounds. It surfaced what shaped everything after it: these users had been sold failed platforms before, so trust had to be earned with visible value early.
Iteration
With no existing interface to build from, I explored visual patterns from finance software, activity logs, and forms to inspire workflow concepts, ultimately shaping a single cohesive design in collaboration with developers.
To get past Unqork’s rigidity I co-developed a custom React wrapper with the engineers, and that uplift is what made the side-panel model possible.
MVP
Formalised as clear segmented tasks on a linear progress bar, so owners and reviewers could see at a glance where a task sat.
Release 1.1
Added the approval step, bringing review inside the workflow instead of alongside it.
Release 1.2
Introduced parent-child workflows for handling errors, so failures were contained and their downstream effects were visible.
What landed
Only possible because we engineered around the platform — which cut context-switching.
Interactive components to navigate between different aspects of the flow. Visibility of assignee teams, who complete tasks, their outcomes, and any back-and-forth all captured.
Printed screens, sticky-note feedback, refinements brought back the next day. We moved to these after Figma walkthroughs left stakeholders lost in the detail, and the physical format earned the buy-in and trust the workshop said we needed.
Configurable, audit-ready forms that captured user and action metadata automatically. No room for errors or not knowing what's next.
Semantic structure, keyboard navigation and screen-reader paths mapped and documented, with QA treating accessibility as a blocker to completion.
What needed work
The inherited user research was unusable and had to be rebuilt from scratch before real design could begin.
The richer experience existed only because we engineered around Unqork, not because the platform supported it — which was fragile and slow. Our engineering team were the first at Macquarie to build around these contraints.
Handover
The Dev Mode annotations covered visuals, interactions and edge cases. I stayed close through the build for real-time questions and iteration, and worked with QA to verify edge cases and error states — with accessibility treated as a blocker to completion, not a backlog item.
This thorough documentation ensured the development team had clear guidance on design intent, functionality and acceptance criteria. Beyond handing off designs, I maintained close collaboration with developers throughout the build process, addressing questions in real-time and iterating on designs as needed.
What I’d do differently
We lost time trying to walk stakeholders through Figma before switching to printed walk-the-wall sessions, which is what actually built understanding and trust. SSince then, I've made it a habit to meet stakeholders in the language they already speak, rather than the one I default to. If someone's technical and comfortable with screens, I'll lead with Figma—but that's never the assumption I start with. The starting point is always the person, not the tool.