Creation & scheduling
Quick-create with sensible defaults; advanced setup adds unlock rules, due time (incl. "X after opening"), repeat (never / daily / weekly / monthly / yearly), auto-lock, and duplication.
Kept a customer who'd threatened to walk, by rebuilding the tool restaurant teams run their day on and merging two systems into one.
A restaurant runs its whole day through checklists. I rebuilt that core experience from the ground up, merging Operations and food-safety checks into one product for the first time. It shipped, kept the customer who'd threatened to walk, and helped bring new ones in.
At a glanceOperations and HACCP merged into a single checklist, with everything that defines a task visible on its card.
Read → 03 Never a reskinAnswer types went from one to a dozen, across a hierarchy built for 1,000+ locations.
Read → 04 Cascade, sync and enforcementEdits flowing from HQ down to every location, and rules strict enough to matter without ever blocking the floor.
Read →When I took it on, the tool did what it was built to do, but it hadn't grown with users' needs. Configuring a single task meant hopping between tabs in a small modal, and almost everything teams actually needed didn't yet exist. My first job was to map that gap honestly.
This is how I would usually start. Once I've pulled together input from stakeholders across the business, along with whatever metrics are available, I map the whole experience on paper and on a board, not in high fidelity: the landing page and every checklist state, the task and its answer types, setup and scheduling. That groundwork is what made the system hold together before it ever looked like anything.
I made two moves that defined the redesign. First, merge Operations and HACCP into a single system: I let permissions quietly decide which answer types appear, so the modules stay independently sellable but the team only ever learns one tool. Second, make the task card the centrepiece: I put every field that defines a task on the card, moved the answer input inline, and turned ambiguous icons into clearly labelled actions.
This was never a reskin. I rebuilt how checklists are created, scheduled, assigned, completed and governed; the answer types alone went from one to a dozen:
Quick-create with sensible defaults; advanced setup adds unlock rules, due time (incl. "X after opening"), repeat (never / daily / weekly / monthly / yearly), auto-lock, and duplication.
Assign by location, role or employee across HQ → franchise → location. A top-level checklist cascades to every location beneath; one edit can be Synced down, with local overrides. Built for 1,000+ locations.
Every state designed and given a behaviour: urgent (auto-resets), overdue, paused, locked, completed, signed off. Auto-lock stops checklists being ticked "done" without being done.
Enforced corrective actions: a check couldn't be marked done just by ticking it. If a reading failed, the fix had to happen and the temperature retaken first, whether captured by Bluetooth thermometer or entered manually, with PPM checks for sanitiser strength built in.
Three problems I had to hold at once.
Operations and HACCP stayed separate products underneath, sold and licensed on their own. The merge was on the surface: a customer with both now sees one checklist, with both kinds of tasks side by side.
A checklist is owned by whichever level created it, HQ, franchise or location, and edits cascade down. That cascade created conflicts everywhere, in scheduling, in overridden fields, in who a task was assigned to, whenever a checklist changed after its tasks already existed. I had to design for each one, flagging what broke and blocking further changes until it was resolved.
Rules had to be strict enough to matter, but never so rigid they stopped a busy kitchen. Checklists lock after their due time, with a grace period to still edit; a failed check can require a corrective action before it counts as done, but that's a toggle, not a default.
"We need to be strict enough that there's accountability, but never so many obstacles that the work doesn't get done."
Design rationale: designing for accountability
Once the core shipped, I kept pressure-testing decisions directly in customer advisory boards. From there, further work grew: Manager sign-off, with PIN sign-off on mobile, plus an Operations dashboard.
This is the project that taught me to design a system, not a screen: to think in states, behaviours and edge cases. I worked closely with a product manager throughout: research, spikes, and the decisions that shaped it, all done together. Merging two products into one without losing what either side needed is the part I'm proudest of. So is the scheduling: genuinely complex underneath, but something I made feel simple.
Delivered by a team across product, engineering and QA; product decisions and research were made together with a product manager, and I owned the design. Focuses on the design problem, process and decisions; outcomes are described qualitatively rather than as tracked metrics.