Building UX from the ground up inside Australia's leading ERP platform

Problem: designing UX in an engineering-first culture

No component library. No design language. No shared process between design and engineering. The challenge wasn't just to design a better interface — it was to make design matter inside a company that had never needed to. The users' reality was just as fragmented. Payroll officers were manually processing employee awards, tracking timesheet variances across spreadsheets, and relying on colleagues to verify data accuracy. The system gave them no proactive visibility — they had to log in to discover problems, rather than being told about them. Onboarding happened through email chains and paper forms. There was no single point of access for KPIs — staff paid, gross totals, pay run variances — and no automation where it was most needed. And the architecture was moving while I built. Transitioning from a monolith to microservices meant design decisions often had to precede engineering ones — not follow them. Regulatory constraints — superannuation validation, BSB account verification, GDPR/CCPA — added further complexity. Every flow had to be architecturally correct before it could be visually designed.

Research: the operating rhythm of the engagement

Research wasn't a phase — it was the operating rhythm of the entire engagement. The process was formalised in a DesOps framework I established from the outset: Empathise → Define → Ideate → Prototype → Test, with recursive feedback loops between discovery and delivery. Every sprint was grounded in documented evidence. No preferences, no assumptions.

Discovery: understanding the system from the inside out

The engagement began in September 2022 with a structured discovery phase. Before a single wireframe was drawn, I ran workshops with the ux team support, and the wider engineering team to map the current information architecture, walk through existing payroll officer and employee journeys, and identify where the legacy system's organisation structure was failing users. These sessions produced a Concept of Operations document that articulated the new system's characteristics and became the alignment tool between design, product, and engineering stakeholders. Requirements couldn't be written until the ConOps was validated; the ConOps couldn't be validated until users' mental models were understood.

Listening to users

Structured research sessions with payroll officers and HR teams surfaced a consistent and specific set of problems. Payroll officers had no proactive notification when something was wrong — they discovered missing timesheets, unapproved leave, and incomplete employee records only when they were already blocking a pay run. The system relied on them to manually chase up other people for data it could have tracked and escalated automatically. Their goals were equally clear: a single dashboard showing wages, leave trends, pay run progress, and HR actions in one view; automated reminders that escalated through the management chain when not resolved; and a pay run interface built for passive monitoring rather than constant manual intervention.

These sessions also produced a Payroll Storyboard — a multi-role, swimlane-style scenario document mapping the full payroll run preparation cycle across HR managers, connectors, employees, line managers, and payroll officers. This wasn't a deliverable for engineering. It was a shared vision of how the system should behave: proactive, automated, and human-centred — the standard every subsequent design decision was measured against.

Service blueprint and user journey mapping

For employee onboarding, the research translated directly into a service blueprint mapping the full Pre-hiring → Day-one → Post-onboarding lifecycle across five dimensions: user actions, frontstage experience, backstage system processes, support processes, and compliance requirements. Alongside it, I produced a swimlane flowchart with four parallel lanes — New Employee, System, Payroll Officer (Pronto Xi), Payroll Officer (NTS) — showing exactly where responsibilities transferred between roles, where the system needed to act autonomously, and where human decisions were unavoidable.

These artefacts weren't documentation for its own sake. They were the tool I used to define UX requirements and business logic simultaneously — frontstage screen flows for employees (invitation email, registration, task completion, profile), and backstage flows for payroll officers (create employee, assign tasks, manage SuperAPI compliance, track progress). The swimlane made it impossible to design one without understanding the other.

Benchmarking the competition

A structured competitor analysis reviewed four platforms — Workday, SAP SuccessFactors, Oracle, and Odoo — assessing information architecture, UI clarity, and feature completeness across payroll, workforce management, and employee self-service. Workday emerged as the benchmark: modern, clean, with intelligent automation and a people-first experience. SAP and Odoo were rated "good" — content-rich but requiring effort to navigate. Oracle fell short on seamlessness.

The gaps identified in this analysis directly informed the design direction for Pronto Xi's navigation, launchpad, and onboarding flows. Notably, the benchmarking reinforced what users had already said: the leading platforms didn't make users go looking for problems — they surfaced them proactively.

Testing navigation models before committing to one

Navigation was one of the highest-stakes decisions in the entire engagement. Getting it wrong would affect every user, every day. Before proposing a direction, I first conducted a heuristic evaluation of the existing system against 16 established usability principles — covering consistency, efficiency, learnability, error prevention, accessibility, role-based access, and contextual help — to document exactly where the current architecture failed.

I then designed and tested five distinct navigation models, each representing a different structural approach. Model 0 was the current state: a vertical side-tree with collapsible rail. Models 1 through 4 introduced progressive variations — top-shell navigation with dropdown menus, custom business-specific menus, contextual subshell navigation, breadcrumb backtracking, and LHS rail with module dropdown combinations. Each was prototyped and tested with real users through structured sessions with specific task scenarios and a Microsoft Forms survey capturing both qualitative and quantitative data.

The testing revealed something important: users consistently valued a clean, well-categorised landing page and clear module identification, but were confused by any split navigation where the entry point and second-level navigation lived in different places. The home button wasn't identifiable in models that buried it. "Overview" as a label meant nothing without context. The winning model combined consolidated top navigation, strong breadcrumbs, and a contextual dropdown redesigning "Overview" as a gateway to dashboard, working board, and manager view.

These findings weren't just useful — they were decisive. The final navigation system was built directly from what users rejected and what they endorsed.

Challenges