Roster and scheduling, rebuilt around its constraints.

A scheduling tool that had outgrown its own interface.

HR Duo served organisations with shift-based teams — hospitality, healthcare, logistics, field services. Roster building worked well enough when it meant one team in one location. Under multi-site deployments it stopped scaling: several contract types with different entitlements, coverage floors that varied by role and site, and leave requests competing for the same dates.

What got the work prioritised wasn't a design complaint. The roster had a practical ceiling at around 100 employees on web — past that, the interface stopped being difficult and started being unusable. That made it a commercial problem rather than an aesthetic one: the product couldn't take on larger customers until the workflow could carry them.

Underneath that sat the daily cost. Managers were discovering critical errors after rosters had been published. Each one meant rework, an awkward message to someone whose shift had just changed, and a small withdrawal from how much the team trusted the tool. Enough of those and scheduling migrates to WhatsApp — which is where we found a good deal of it already living.

From a canvas that accepts input to a surface that presents constraints.

The finding that changed the shape of the project: managers weren't using the tool incorrectly. The tool was asking them to do work it should have been doing itself. Checking who was available, cross-referencing approved leave, tracking contracted hours against what had already been assigned — all of it manual, none of it visible in the interface where the decision was being made.

So the shift was conceptual before it was visual. A roster isn't a blank canvas that accepts whatever a manager types into it. It's a surface that should show what's possible before someone commits to what they want.

The interface should show you what's possible before you commit to what you want.

The dependency model

Each stage governs the one after it. An approved leave request changes coverage. An availability edit invalidates a draft roster. A sick call at 7am creates a gap that has to be resolved before the shift starts. Redesigning any single stage on its own produces a clean screen sitting inside a workflow that still breaks.

Consistency was the wrong goal.

I started from the opposite conclusion to the one I ended with. My early concepts pushed to bring more roster-management capability onto mobile — managers handling changes from the floor rather than at a desk.

Screen density is what ended that. At the scale we were designing for, a manager building a roster across multiple locations needs to hold a lot in view at once and compare across it. On a phone you can show enough to decide or enough to read, not both. Reproducing the desktop planning experience on mobile would have produced something worse than either.

So desktop stayed the primary planning environment, and mobile stopped trying to compete with it. That reads as a clean strategic decision now; at the time it was me conceding that the thing I'd been exploring wasn't going to work.

The data layer stayed shared — an approval on web appeared on mobile immediately, because the moment those two disagree the whole system loses credibility. What differed was what each surface was for. Mobile navigation came down to four tabs, with every common task within two taps.

One decision worth isolating: showing leave balance before date selection rather than after submission. The most common employee complaint wasn't being rejected — it was being rejected for a reason they had no way of knowing in advance. Balance-first turned a failure state into a constraint people could work with.

Where the design actually got tested.

Workforce products are judged on their exceptions. The happy path is a demo. The exceptions are the job.

An interaction that works at twenty employees can be unusable at two hundred. Scale isn't an edge case in the sense of being rare — it's the condition the product needed to survive, and it invalidated more of my early work than any other constraint.

It forced a rethink of hierarchy, density, and how much to expose at once. Every pattern had to be judged twice: once for whether it was clear, and again for whether it was still clear a hundred rows down. The redesigned web experience worked practically to around 250 employees. Mobile stayed deliberately narrower rather than pretending the same interaction would hold.

What shipped, and what it took.

Nobody was going to approve twelve months of foundational work with no visible output. So the system didn't begin as a proposal — it began as the main dashboard, which was already on the roadmap and already needed rebuilding.

That screen is where the primitives got decided: the colour palette, the typeface and the scale, the spacing, the first real buttons. Choosing them for a specific screen rather than in the abstract meant every decision had to survive contact with actual content on day one. And because the dashboard was the screen everyone saw first, the argument for the rest of the system had a working reference instead of a deck.