I joined my friends’ startup, StaffAny, after spending a year in the Bay Area. We were batch mates of an entrepreneurship program and spent a great deal of time going on trips and doing hackathons together. The team had an extraordinary idea of revolutionizing the shift work industry and I was pulled in to help out with design. This writeup is about my process and contribution when I was designing for rostering on-the-go — fitting for a 21st century pace of life.
*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. Pictures paint a thousand words, right? Part II (results and actual design) will be released in the near future or on request.
Enter the Problem: Rostering
Anyone who has managed shift work knows that it requires tons of effort to schedule. With 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 one big heck of a 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, full-timer:part-timer ratio… You get the idea. The list goes on and on. It is so complex that there are even research papers on the topic!
“No schedule is set in stone, even during day of operation.”
Our 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 even have to bat an eye about — but reality is that it happens way too often and it disrupts operation, big time.
Ubiquitous mobile computing allow for palm-sized supercomputers to fit into our pockets. “Shouldn’t there be a more efficient way to roster with such technology? and why are we not doing it yet?” Good question. Which is why the team at StaffAny intends to tackle these problems with an all-in-one manpower management solution that makes rostering much more efficient.
The Team and My Role
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 manager and employee versions of the app,
- create interactive prototypes for testing,
- and lastly deliver a polished UI for implementation.
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
‘Are there any existing products in the space with an approach to solve similar problems?’ 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.
After understanding the problems and choosing areas of focus for the sprint, it was solution-crafting time. We brainstormed concepts, sketched out ideas, and then pieced selected ones together to form a storyboard demonstrating our vision of mobile rostering to our potential users. 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.
With the storyboard and a rough visualization of the UI in my head, I was left in charge to design an interactive prototype for user interviews. I completed the prototype before midnight while the rest of the team prepared for user interviews. 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 through user interviews. 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. We had to do more testing. 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 for an improved iteration.
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 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 closed ‘the rostering loop’ by considering all possible scenarios/use cases and developing the flow for the Employee App.
From our numerous user interviews, we gained clarity on the needs of shift managers. There were specific features we had to develop that were blocking adoption and had to be solved given a chosen UI and engineering constraints. The Product team would have regularly discussions at the whiteboard to conduct exercises like brainstorming and 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 Product Team had to solve include:
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.
After countless jugs of coffee, 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.
… Well, this is a little embarrassing. I can’t show any more for now and here’s where the story will take a pause. The rest of the results will be presented in Part II.
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 to develop empathy was actually the key ingredient to designing a solution. The exercises we did during the sprint provided a bird’s eye view to the process and to prioritize problems for solving.
Lastly, a shoutout to the team at StaffAny for making my learning experience rich and really enjoyable! The team at StaffAny came a long way and is currently testing their close beta (drop a note if interested!).
Thanks for making it this far! If you enjoyed the read, destroy the clap button or check out my other works on my portfolio. Part II (Results and Actual Design) will be out in the near future or available upon request.