The Problem
"Utilisation" - we needed to help customers book the same worker more often and repeatedly. The dual goal: reduce the cost of onboarding new staff, and help high-performing workers secure more shifts.
The Approach
A key tension in this project: we started with a solution already in mind. We thought the answer was a scheduling feature. That assumption shaped how we began - looking at competitors, studying existing rostering tools, asking ourselves what manual processes could be replicated in software.
Lo-Fi Prototyping
Rather than jumping straight to high-fidelity designs, we used Balsamiq to rapidly explore options and stress-test the scheduling concept before committing any engineering time.
Outcome & Learnings
Stakeholders found that most of the scheduling solutions would require significant development effort without a clear enough return. Revisiting the problem, we needed something that balanced the scale of effort against the benefit delivered.
That's when the framing shifted. Our product already had a calendar. If we refreshed it and added targeted functionality, we could deliver real value to customers quickly - without building an entirely new scheduling system.
And that's exactly what we did.
The prototyping process was what made this possible. By exploring the big idea in low-fidelity before anyone had written a line of code, we were able to recognise - early and cheaply - that the solution we'd assumed was right wasn't actually the best path forward.
In retrospect: I'd now run prototyping workshops and build this skill into the team's development framework. The method worked; the real opportunity was making it repeatable and teachable across the whole team.