Swift Rota

Why this project is in my portfolio

This project did not ship. The contract was lost. I am including it because the design work itself was strong, the client confirmed that in the room, and what went wrong taught me more about delivery, scope, and the gap between design and development than any project that went smoothly.

Hiring managers ask about projects that failed. This is mine. The failure was not in the design thinking. It was in the promise that surrounded it.

The problem

A UK healthcare facility was managing staff shift schedules using a spreadsheet. Rows of names, columns of dates, single-letter codes: D for Day, N for Night, LD for Long Day, SD for Short Day. No visibility into hours worked. No way to request leave digitally. No quick way to spot coverage gaps or overtime risks.

For a facility managing 60+ staff across rotating shift patterns, this spreadsheet was not just inefficient. It was a compliance and patient-safety risk. One misread cell, one forgotten swap, and a ward is understaffed.

A friend who runs a tech agency in the UK was approached by the facility to build a proper scheduling platform. He brought me in to design it. The catch: we had less than 3 weeks to present a working version to win a GBP 7,000 contract, as the facility had already burned time and budget on a previous agency that failed to deliver.

Research (in 3 weeks)

Three weeks meant no time for a full discovery phase. I had two sources and I worked them hard.

The spreadsheet itself

The spreadsheet was the research. Every design problem was visible in its structure: shift types encoded as single letters with no legend on screen, no hours displayed, no way to differentiate a normal day from a long day at a glance, no leave tracking, no concept of roles or departments. I mapped every limitation and turned each one into a design requirement.

Stakeholder conversations

Two calls with the facility's scheduling manager gave me the operational context the spreadsheet could not: how shifts were actually assigned (seniority, then preference, then coverage gaps), what the most common scheduling errors were (double-booking and missed night shifts), and what a dream system would do (auto-generate a draft schedule they could then adjust).

What I designed

Every design decision was a direct response to a spreadsheet limitation.

Colour-coded shift types

The spreadsheet used D, N, LD, SD with no visual differentiation. In Swift Rota, each shift type has a distinct colour: Day shifts in warm yellow, Night shifts in deep purple, Long Days in red, Short Days in amber. A scheduling manager can scan a full month and spot coverage gaps in seconds, not minutes.

Hours visible at a glance

The spreadsheet showed shift type but not duration. Swift Rota displays the hours per shift (8 hrs, 12.15 hrs, 14.15 hrs) inside every cell. No mental arithmetic, no cross-referencing a separate document to check if someone is approaching overtime.

Inline actions: leave, day off, shift changes

In the spreadsheet, adding leave meant deleting a cell and typing L, with no audit trail. Swift Rota surfaces a contextual menu on any cell: Add leave, Add day off, Add shift. Every change is logged. Every absence is tracked.

Day / Week / Month views

The spreadsheet only had one view: the entire month. Swift Rota gives three: Day (for real-time floor coverage), Week (for pattern planning), and Month (for the big picture). Each serves a different operational need.

AI-assisted schedule generation

The stakeholder's dream feature: a 'Generate Schedule' button that creates a draft rota based on staff availability, shift patterns, and coverage requirements. The manager reviews and adjusts rather than building from scratch. This was designed but not built in the prototype.

The presentation

By week 2, the design was complete. The developers were not ready. We were running out of time to present the working platform the agency had promised.

I pivoted. I built a full interactive walkthrough using Figma slides: every screen, every flow, every interaction state, presented as if the user were clicking through a live product. We presented it to the client in a video call.

The client was pleased. They could see their spreadsheet problems solved on screen. They understood the colour coding, the hours visibility, the leave management, the schedule views. The design had done its job.

But they wanted what they had been promised: a working, developed platform. And we did not have one.

What went wrong

The failure was not a design failure. It was a delivery failure with three root causes.

1. The promise was wrong from the start

The agency founder promised the client a fully developed platform in 3 weeks. That timeline was unrealistic for a scheduling system with the complexity we scoped: multiple shift types, role-based views, leave management, and a monthly calendar grid. The promise set the project up to fail before I was even brought in.

2. Design and development were not synchronised

I designed independently and synced with the developers for handoff. On a 3-week timeline, that gap was fatal. By the time the designs were ready for build, there was not enough runway left for the developers to implement even the minimum viable flow.

3. No MVP was defined

We never agreed on what the minimum shippable version was. Was it the monthly view only? Just the schedule grid without leave management? Onboarding plus one view? Without that agreement, the developers were trying to build everything, and finished nothing.

What I learned

1. Own the scope conversation, not just the design

I treated the scope as someone else's responsibility. On a team this small, with stakes this clear, I should have been the one saying: here is what we can build in 3 weeks, here is what we cannot, and here is the MVP that wins the contract. Scoping is a design skill. I did not use it.

2. On a 3-week timeline, design and dev run in parallel or not at all

Sequential handoff (design first, then build) works on a 10-week project. On a 3-week sprint, the developer should be building the shell while I am designing the first screens. I would structure the next compressed project as: Day 1-3, research + architecture + dev environment setup. Day 4-10, design and build running side by side. Day 11-15, integration, QA, polish.

3. A Figma prototype is not a product, no matter how good it looks

The client's reaction proved the design worked. But a healthcare facility does not need slides. They need software that runs on a screen, with real data, tomorrow. The gap between a polished prototype and a functioning product is the gap that lost us this contract.

What I would do differently today

This project happened before AI-assisted development became practical. Today, the landscape is different, and so is my approach.

With tools like Claude Code, Cursor, or similar AI-assisted development environments, a designer who understands product architecture can bridge the gap between prototype and functional product. I could take my own Figma designs, generate a working front-end with real scheduling logic, and present a functional product, not a slide deck.

That does not mean designers should replace developers. It means that on a 3-week sprint with a tiny team and a binary outcome (win the contract or lose it), the ability to produce a working prototype, not just a visual one, changes the odds. Swift Rota taught me that. The tools to act on that lesson exist now.

Beyond tooling, I would also challenge the timeline and the promise before accepting the brief. If a client is told they will see a fully built platform in 3 weeks and that is not achievable, the project has already failed. The professional move is to renegotiate the deliverable, not race toward a deadline that cannot be met.

The design still stands

The contract was lost, but the design work holds up. Every decision mapped to a real problem surfaced from the spreadsheet and stakeholder conversations. The client validated the thinking in the room. The colour system, the hours visibility, the inline actions, the multi-view architecture: these are sound product decisions that would work in any healthcare scheduling tool.

If I rebuilt Swift Rota tomorrow, the design would be the same. The delivery would be different.