Designing a Revolution in the Shift Work Industry

StaffAny Design

Project Summary (TL;DR)

For further details, read the full case study on Medium.

Problem: Most shift-related businesses are still relying on labor-intensive methods like pen and paper or Excel/Google spreadsheets to plan rosters.

Opportunity: I was part of the early team of a startup where I co-led the product team to research and design solutions to enhance shift managers’ existing rostering methods.

Impact: We shipped a high-fidelity UI for implementation and is used by early users who loved the concept.

StaffAny is now released on both the App Store and Google Play.


StaffAny had an extraordinary idea of improving the shift work industry and I joined to design for rostering on-the-go. This writeup is about my process and contribution when I was researching and designing for rostering on-the-go.

*Being under a NDA, I will not be showing any finished work. Instead, I will be presenting my processes and overcoming challenges faced with illustrations as a creative work around. Part II (results and actual design) available on request.


  • Tools: Sketch, Principle, InVision
  • Timeline: Jan - May 2018
  • Project Type: Startup
  • Role: Product Designer
  • Skills: User Research, Product Design, Design Sprints

Enter the Problem: Rostering

Managing shift work requires tons of effort to schedule — numerous considerations such as wages, overtime, and a multitude of potential (and unexpected) last minute changes like crew swaps and no-shows, rostering can be a big pain. Furthermore, the time spent on scheduling scales up with the size of the team and complexity of other considerations such as budget, skillsets required, and full-timer:part-timer ratio.


"No schedule is set in stone, even during day of operation."

Initial market research showed that most shift-related businesses are still relying on methods like pen and paper or Excel/Google spreadsheets, coupled with messaging apps like WhatsApp for communication. Additionally, last-minute no-shows and dropping of shifts are concerns that managers shouldn’t have to care but reality is that it happens way too often and it disrupts operations.

The Team

It was a great joy working with an extremely motivated and talented bunch from diverse backgrounds — Engineering, Business Development, and Product — spearheaded by respected founders with great foresight and incredible grit.


I played the role of a Product Designer where I guided the Product team to

  • conduct user research and usability tests
  • design the information architecture and user flow for both managers & employees
  • create interactive prototypes for testing
  • and deliver a polished UI for implementation

Initial Research

We had to make sure that the problem was one worth solving. We kicked things off with a variation of a Design Sprint to first understand the managers’ rostering process, identify the pain points, and to determine if a mobile-first approach was something managers would use.


1. Navigating with a User Journey Map

We broke down the managers’ rostering process and their interaction with employees to identify gaps that caused the most ‘friction’. A team member with experience running a bar played the ‘expert’ as he understood the rostering process and members with shift work experience contributed to the employees’ interaction discussion. A journey map was created to visualize the entire flow. In doing so, we were able to zoom in on the problems that really matter.


2. “How Might We?”

Next, we identified key problems to solve through the ‘How Might We’ approach, transforming challenges into opportunities.

We each contributed ideas and voted for the best ones to work on:

How Might We…

  • …instantly generate a working schedule?
  • …display staff input succinctly while scheduling?
  • …automate collection of input from employees?
  • …fulfill an employer’s optimization needs?
  • …reduce the number of interactions between Employee and Manager?
  • …use a convenient channel to find mutual swaps?
  • …reduce the manager workload in finding replacements?
  • …notify last minute swaps/drop-outs?

3. Competitive Analysis / Lightning Demos

We conducted a competitive analysis of companies to better understand the needs of users fulfilled by their services, to find out what worked for them, and how we can apply the learnings when building our product.


4. Prototyping

We brainstormed concepts, sketched out ideas, and then pieced these to form a storyboard demonstrating our vision of mobile rostering. When brainstorming for UI ideas, I utilized conceptual models of existing schedules such that users would intuitively understand how the initial UI work, in an attempt to reduce friction when onboarding. We also gained inspiration from other apps totally irrelevant to our project, such as the floating heads on Instagram Stories.


I was left in charge to design an interactive prototype for user interviews while the rest of the team prepared for interviewing. A few challenges I faced designing for mobile is that screen real-estate is very limited and accessibility had to account for a range of users (from teenagers to elderly folk). The design also accounted for Miller’s Law (the average person can only keep 7 ± 2 pieces of information in their working memory) to prevent cognitive overload by chunking the UI components.


5. User Interviews and Usability Testing

With a finished prototype, we took it out to validate our assumptions with shift managers of F&B businesses. Our findings concluded that rostering was indeed a pain where managers can take hours to schedule and that more than half of our interviewees were excited to try our solution. On the product side, we learned that some UI components and copy were confusing to users and that the UX was not intuitive enough to get the job done.


This meant a lot more to work to be done to prevent building a product users won’t adopt and to build one that is intuitive and usable. Our sprint generated more questions than answers, leading to us conducting 5 more Design Sprints with 4 different versions of UI — with each sprint providing more actionable insights.

Design Journey and Roadblocks Faced

Design Sprints helped us develop empathy for our users and to prioritize problems our product should aim to solve. Through these week-long sprints, we figured out what was essential for our first iteration before allocating valuable engineering resources for development. However, a downside is that it usually only accounts for a single ‘Happy Flow’ we present to users (due to time constraints) and the entire user experience is not accounted for yet. There was also plenty of organizing and Design backlog to be done.

For instance, prior to the sprint there was no inherent information architecture in the app. The screens were designed but navigation through the app was not thought of yet. Hence, the Product team constructed one to improve accessibility of important functions like scheduling by placing on a main tab of a bottom navigation bar and other less-used functions such as updating your profile deeper within. We also had to include Employees in the flow by considering all possible scenarios/use cases.


From our numerous user interviews, we learned that there were specific features to develop blocking adoption and had to be solved given a chosen UI and engineering constraints. We would have regular discussions and exercises like Crazy 8’s to solve these problems. Once we had a rough idea, we seek feedback from the rest of the team before implementing a medium-fidelity prototype for testing with users again.

Some problems we had to solve include:

  • Including Non-user Staff
    Our design had to be inclusive, accounting for non-users such as elderly and foreign workers.

  • Post-publish Schedule Changes
    Most managers we interviewed told us that there were many abrupt changes like swaps or dropping of shifts even after a schedule has been published.

Final Results

We designed >100 hi-fidelity screens for both Manager and Employee versions of the app which we took out to test. Usability testing with at least 5 participants was also conducted to ensure that there was no confusion with the UI elements and copy was intuitive enough to guide them to get the job done.

Part II, showcasing the results, will be available in the future.

But here’s What Managers Thought

So while we can’t show the end product for now, we showed the latest version to several managers and they were really impressed with it — most resonated with our solution and expressed interest in trying out for their operations.

Here’s what some of them have to say:

“Let me know when your app is ready. We want to be the first to use it. It’s so intuitive and easy to use and can save me half the time for scheduling!” - Female, 30’s, Manager at a branch of a Patisserie.

“Most importantly, the app will able to help deploy manpower & save costings for the managers. This is helpful in the F&B sector in the most effective way.” - Male, 40’s, Manager at reputable Ice Cream chain

“Looking forward to the launch of StaffAny. It would really save time planning & management of my cafe crew.” - Male, 30’s, Manager at a cafe


I really enjoyed the challenge of designing rostering for mobile — something that is typically done on PC due to complexity. Such constraints encouraged creative problem-solving and plenty of thought work for a seamless and complete user experience.

Talking to stakeholders and understanding the process was actually the key ingredient to designing a solution for the f&b managers. The exercises we did during the sprints provided a bird’s eye view to the process and allowed us to prioritize the problems for solving given time and budget constraints.

For further details, read the full case study on Medium.