Context

The client builds AI-powered call centre software. Their agent-facing application had usability problems that were costing agents time during live calls, and they wanted four things: a better interface, a clearer information hierarchy, AI features that genuinely assist mid-call, and a navigation flow that lowers cognitive load rather than adding to it.

My users were call centre agents — people who need an interface that stays out of the way while they hold a conversation.

The problem

I audited the existing product and found five specific failures. Each one implied its own change, and that audit became the spine of the redesign.

Research

• Project owner interviews — to get at the real pain rather than the feature list. Delays in resolution and a complicated interface came up every time.
• Competitive analysis — reviewed call centre and AI-assisted tools across industries for patterns worth borrowing and traps worth avoiding.
• Persona development — built around a support agent whose entire measure of a good day is handling queries quickly without making mistakes.

The solution

I wireframed the call as a sequence rather than a screen, because that is how an agent experiences it — a beginning, a middle and an end, each needing different things visible.

• Start of call — qualifying questions and the interaction flow, so the agent is ready to greet the customer and open the conversation.
• Mid-call — the AI detects greetings and marks them complete; predefined questions sit in grey, qualifying answers turn green and become clickable, disqualifying ones turn red.
• End of call — eligibility visible at a glance, with options to transfer, set a disposition or convert the lead.
• Sentiment and rebuttals — a real-time emotional read for the agent, with AI-suggested rebuttals and their success rates.
• Keyword search — find a term across the transcript instead of scrolling.

Impact

What I took from it

Designing for a high-pressure environment taught me that AI should support a decision without taking it over — the moment the interface hides what the machine did, the human stops trusting it. And that sequencing a release well is a design decision, not a project-management one.

Context

The programme strengthens healthcare access in underserved communities by encouraging qualified professionals to practise where they are needed most. The digital experience had to increase awareness, simplify the application, improve discoverability, reduce confusion, and build trust — while staying compliant and transparent.

The problem

A clinician landing on that page had five questions and no patience: Am I eligible? What documents do I need? How do I apply? What are the requirements? What happens after I submit?

Every answer existed, several layers down, organised around the department that owned it rather than the person asking. Discovery — stakeholder workshops, a heuristic evaluation, government portal benchmarking, a content audit, an accessibility review and journey mapping — turned up five consistent problems:

• Information overload — applicants met large amounts of policy content before they could tell whether it applied to them.
• Complex navigation — the actions people came to perform sat beneath several layers of reading.
• Low confidence — with no clear guidance, people could not tell whether they were doing it right.
• Accessibility gaps — a public health service must work for a diverse audience on whatever device they have.
• Content organised around the org chart, not applicant goals, which added cognitive effort to every task.

The solution

Four principles governed every decision: make government services easy to understand without compromising policy accuracy; guide people step by step; build trust through clarity; and design for accessibility from the start.

• Applicant-centred architecture — eligibility, required documents, application steps, timelines and support resources, each findable in one step.
• Task-oriented navigation — structured around what people came to do, cutting unnecessary clicks.
• Progressive disclosure — typography, whitespace and visual grouping so complex information can be scanned before it is studied.
• Responsive across devices — a consistent experience on desktop, tablet and mobile, because applicants are rarely at a desk.
• Reusable design system — standardised components so future phases stay consistent and ship faster.

Accessibility

Accessibility was an input from the first wireframe rather than a compliance pass at the end: WCAG-compliant colour contrast, accessible typography and spacing, clear interactive states, consistent navigation patterns, a logical heading hierarchy, and responsive layouts throughout.

Impact

Context

The client — a subsidiary of a financial technology group, founded in 2014 — had expanded fast across Australia, acquiring more than a thousand venues under licences in multiple states. Role-based responsibility had outgrown the way it was being tracked.

They needed one centralised platform covering user management, central configuration, gaming host and cashier applications, where the SuperAdmin could create and manage roles, delete users and update details, and assign role-based access control that held up to an audit.

The problem

Managing roles across User Management, Auditing and Floor Management offline had stopped being viable at that scale. But the written requirement described features, not friction — and nobody who wrote it had stood behind a counter during a shift.

The solution

With those insights we brainstormed around simplifying the role management workflow, then worked through multiple low-fidelity wireframes, each iteration driven by client feedback and internal review, before anything became visual.

• A comprehensive design library — standardised UI elements, reusable components, typography and colour aligned to the client's brand. It is the reason six people could work in parallel without the product drifting, and it made future expansion straightforward.
• An interactive prototype simulating the core workflows, so stakeholders could experience the platform before it was built and we could validate choices with real feedback rather than opinion.

Impact

What I took from it

Field research is not a nice-to-have. Observing the work on site gave us a understanding of the system's shortcomings that no amount of requirement-gathering would have produced — and it is the reason the design solved the real job rather than the described one.