Designing the Clock In / Out Feature — Part 1
Hello there! We are DayOne, and our vision is to allow business owners to run their business anytime, anywhere, and for them to always have oversight of operations.
The big question we want to answer is: How can DayOne inform business owners about employee attendance, punctuality, and activities, without actually being present at the store?
The Problem
And so, here is the problem we set out to solve:
How might we facilitate business owners’ visibility of business operations, without imposing on or requiring too much effort from the different parties involved?
Today, one of the common processes employed by business owners to find out who is at the store or restaurant is to either access the roster, or send WhatsApp messages to the work chat group and await an acknowledgement. This usually happens at the start of the work day, when business owners want to find out if preparations have begun, or when an incident arises and requires resolution from specific persons at work.
This process is simply a headache for everyone! Business owners are busy people — they can’t be having to access the roster or to send out messages to ask about attendance every single time. Staff members on the ground are even busier- how can they find time out of busy operations to inform or respond?
Most crucial of all, the business owner has to sieve through a lot of irrelevant messages from multiple group chats in order to get to the information that they are seeking! This is especially so if they have more than one outlet under their belt.
With these problems laid out in front of us, we set out to design a feature that would ensure both parties can communicate crucial information with less effort on their parts!
Target Users
For an app to improve visibility of onsite manpower activities, there are two groups of crucial target users involved: staff and business owners. Staff would use the feature on the mobile app to log their activities, starting from when they first report to work, when they leave the premises for their break, and when their shift ends.
The data points logged on their end would then be visible to the business owner, who can view the synthesised information on both the mobile and desktop apps. With that, staff easily logs their activities, and business owners have easy access to it!
User Research — One-On-One Interviews with Business Owners
To get the ball rolling, we interviewed business owners to better understand how they kept sight of one of staff’s key processes at work: clocking in and out. The goal of the interview was to find out more about their current process, the problems they face today, as well as other possible uses of the data collected.
We asked the business owners a series of questions, ranging from how they would potentially utilise the activity log data (“to monitor attendance and tardiness”), to prioritisation of information (“to identify who is prepping the store for opening”).
Our initial hypothesis was that business owners wanted oversight of store activities without being physically present for a peace of mind that operations were running as per normal. However, we soon realised that instead of limiting ourselves to the initial scope, we could actually make the data work much harder for us!
One business owner shared that the business operated on a trust basis, and would only check in with staff when there was a deviation from normal operations. Still, they thought that being able to find out which staff members were on the premises at their fingertips was crucial, especially during retrospective incident handling, as this would streamline the resolution process. That meant less time on tedious work, and more time for things that matter!
Business owners we spoke to also mentioned that they chiefly utilise clocking in and out information to fill out digital timesheets, which then allows them to generate the monthly payroll more efficiently — another important part of the business, of course!
And this was a light bulb moment for us! This use case in turn inspired us to not only present the information for what it is (i.e. daily logs), but to synthesize it (i.e. monthly timesheets organised by staff and/or branch) so that the data can be put to better and multiple uses.
Now that we’ve established the use cases and data points to collect, we began designing the foundation piece for the feature — the mobile app piece for staff.
Mobile App Feature for Staff
The first iteration of the mobile app feature was born with a few key functions for staff in mind:
(i) key in rostered hours to log planned shift duration;
(ii) clock starting shift and ending shift timings to log actual hours worked; and
(iii) leave a message for the supervisor in the event that clocked hours deviated from the roster.
The first prototype was built in two days and tested out with individuals who work in F&B and retail. We were glad to observe that users had no issues clocking in and out for their shift — hurrah! Unfortunately, where math was involved (i.e. calculating rostered hours), users struggled and keying in the planned shift duration posed a huge challenge.
We realised that this was also unintuitive, and that there was a mismatch between the system and the real world. Clocking time at work has its genesis in analogue punch clock machines that merely require users to insert a time card into the machine when they report for and leave work.
The punch clock machine did not require users to key in their shift duration as it would be calculated based on the two timings recorded. The analogue punch clock machine provided a virtually frictionless process on the users’ end and this was something we sought to emulate in our feature.
We also noted that despite having the option to leave a message to clarify discrepancies, most users chose to leave the field blank. When queried, they said they were not sure what exactly to enter. The fatigue from thinking about how to fill the field led to most users giving up, and leaving it blank. After a long day at work, who wants to spend more time stressing over what message to leave?
Iterations and Improvements
Thus, in the second iteration of the prototype, we aimed to emulate the simplicity of the punch card machine’s design and include only the essentials. Instead of requiring users to calculate and key in their shift duration, the system does the heavy lifting by calculating the period lapsed from when users first clock in to when they finally clock out. The branch locator is also automatically selected by synching the field to the branch that users are logged in at, reducing one additional step in the process. And voila, that’s it!
In the clock out screen, we added a dropdown list of issues that users may want to highlight regarding their clocked hours. Users will now spend less time racking their brains on what exactly to write in the message box, and can simply communicate the issue with their supervisor by selecting an option from the list. Easy peasy!
We understand that users may sometimes forget to clock out after a hard day’s work, and we’ve got your back! We catered for such scenarios by auto-populating the “Forgot to clock out” issue in the clock out screen’s dropdown list, should the system detect that the staff has been clocked in for more than 16 hours. We also included prompts to encourage and advise users to leave a message, so that there is greater clarity on the discrepancy for the supervisor regarding clocked hours and actual hours worked.
Finally, there’s always space for a bit of fun! We added little touches that create moments of delight through visual feedback. We hope that the lighthearted, encouraging messages will brighten up our users’ day and spur them on at work.
Learnings, Challenges, and Next Steps
We kickstarted the process by gathering requirements from business owners on the information that they needed from the feature. While these requirements originated from one set of stakeholders i.e. the business owners, the fulfillment of the very same requirements are by another set of stakeholders, i.e. the staff. For the requirements to be implemented and fulfilled, it was crucial to test them out with the actual users of the feature, in this case, employees of the business, in order to uncover friction points in the process and eradicate them early on.
One of the challenges of building a functional minimum viable product quickly also meant prioritising the engineering effort required to build the feature. We weighed the impact of must-haves against the effort required, in order to shortlist what we will eventually build without compromising basic functionality. Nevertheless, we promise to revisit this feature in the near future to provide more value-added functionalities.
In our next post, we will be sharing more on the process of designing the mobile and web app feature for business owners, so do keep a lookout for that!
