Turning a 12-message group chat into a two-tap shift swap

Crewline schedules shifts for about 1,200 restaurants. When someone couldn't make a shift, the app technically let them post it for a swap, but almost nobody did. Instead, swaps happened in group chats: a photo of the rota, a dozen replies and a manager trying to work out who had actually agreed to what.

That chaos had a cost. Managers told us they spent up to an hour a day untangling swaps, and missed shifts were the most common reason restaurants contacted support.

The brief from my PM was simple: make swapping inside Crewline easier than swapping in the group chat.

I started by spending three weekend shifts in two partner kitchens, watching how swaps actually happened. I followed that with 12 interviews with line cooks, servers and shift leads, and our researcher and I synthesized everything in Dovetail.

Three findings shaped the work:

• People trade with someone specific. Our flow posted a shift to everyone, but most swaps were between two colleagues who had already agreed in person.
• Managers need context, not notifications. They approved or rejected swaps based on skills and overtime, and our approval screen showed neither.
• The phone comes out between tickets. Every flow had to work one-handed, in under a minute, with busy hands.

I prototyped three directions in Figma and tested them with 18 workers through Maze. The direct request concept won clearly: it was completed fastest and needed no explanation.

Ask a person, not the whole team

Swaps now start from the shift itself. Tap a shift, choose a teammate who is qualified and available, and send the request. Crewline only suggests people who wouldn't go into overtime.

One card for the manager

Managers see both people, their roles and the hours impact on a single card, and can approve straight from the notification. No more scrolling back through a chat to check who agreed.

Clear status at every step

Every swap shows where it is: sent, accepted, approved. The original shift stays on your schedule until the swap is approved, so nobody is accidentally left uncovered.

This was my first feature from research to release, and it taught me to scope with engineers in the room. Our first design included in-app chat, and cutting it after a feasibility review made the feature better, not worse. People already had chat. What they lacked was a clear record.

I also learned to define success before kickoff. Because we agreed on approval time as the main metric up front, we could make trade-offs quickly and show the impact clearly after launch.