Building a sticky product for restaurant employees to verify their punched hours

TL;DR 

Restaurant staff often forget to punch in for their shifts, leading to inaccurate timesheets and time-consuming back-and-forth between employees and employers to verify hours for payroll.

This issue creates multiple challenges:

• Transparency for employees: Ensuring workers understand their hours and pay.
• Compliance risks for restaurants: Preventing wage-theft accusations and legal issues.
• Payroll: Saving time spent on issuing or correcting timesheets for payroll managers.

Solution & key results:

Designed and developed end to end web & mobile experiences allowing employees to verify their time punches and request corrections, streamlining payroll processing and meeting solution requirements per labor laws. Within six months of launch, 65% of customers adopted the feature organically. Retention analysis shows that nearly 80% of users who verify their punches return weekly, making it a sticky product now integrated into workflows of thousands of restaurants.

PLATFORMS
iOS, Android, Web

TIMELINE
1 Quarter (Prioritization to release)

MY ROLE
Product Designer & Researcher

METHOD
Design Thinking ( Empathize, Define, Ideate, Prototype, Test, Implement)

Method

Project Background

7shifts web software was already equipped with a Time Clocking feature, which allowed restaurant admins to input worked hours or pull it from their integrated POS and edit punched hours (by employees on the Time Clocking device). On mobile, employees were able to view their punched hours, but were not able to edit them (in case they were wrong or forgotten) and were not able to see what was edited by managers. This problem caused distrust between restaurant employees and managers, and left restaurants open to wage-theft accusations, and employees vulnerable to inaccurate pay. 

I was brought to this project, after a few teams had explored it. Every time this project was dropped due to uncertainties, complexities, dependencies on multiple teams (web & mobile), old code (tech debt), and the layers of ambiguity added by compliance requirements. I was responsible in the Product Design role from initial research to supporting development for this project from 0 to 1 on iOS, Android & Web.
Some challenges in this project were: shaping the right scope & requirements, aligning stakeholders and collaborating early and often with developers.

Customer Research

We had over 150 customer requests in our insight tool that we synthesized for common themes. Different customers used different terminology mentioning various pain points and asks. when we got deep and interviewed with them, we realized they want a solution that verifies employee punches. For restaurant owners, the biggest challenge was keeping payroll accurate—ensuring employees were paid correctly and on time while protecting the business from wage-theft claims. Our challenge? Defining a solution that seamlessly fit their workflow without adding friction or slowing them down.

We Conducted +8 customer interviews to understand the customer needs and their pain points. We also consulted with workforce lawyers to understand US labor laws and requirements for reporting and verifying hours worked in accordance to employee rights.

Common Themes

By doing a thematic analysis of the collected insights from customer interviews and feature requests, I found some common themes that helped define the problem better, empathize with different user types, and their pain points. 

By this stage, I knew we are not solving this problem only from a compliance perspective, but we want to solve for workflow and ease of use. 

How might we create a transparent workflow between restaurant admins and employees to verify hours worked for accurate payroll?

User journey map

I laid out the existing journey map of common cases in restaurants where managers need to edit an employee punch, depending on different scenarios, as this was the most critical punch. This exercise helped us find areas of opportunity where our solution could meet the user's need most contextually ( on the punch device / after shift is punched for & ended / before pay period is finished and hours are sent to payroll, etc.). Each of these areas had pros or trade-offs.

Competitor Analysis

Competitor deep dive helped us understand how other tools in the market, enable restaurants against this problem and helped us scope our offerings according to market.

Labor laws research

With the team, we studied and compile different labor laws for different states in US, to gain a better understanding of solution requirements according to labor laws. This was a shared task between product managers, stakeholders and me in Design to understand how to shape our solution to be compliant as well as functional. However different state had very different restrictions and borders for labor laws. 

MVP ideation

We started the ideation of our MVP by mapping the potential user workflows, evaluating the risks in different solutions, pros and cons of different solutions to shape our product requirements for MVP.

This Mapping identified these requirements:

1. Where to review punches ( My timesheets, instead of punching device, email receipts, messaging feature)

2. When to review punches: when each individual punch is in the system, or all at once at a certain point in time, like after all punches are processed for payroll?

3. Employee action options: Approve, dispute, leave a note or make an edit?

Comparing 2 workflows for employee's response to punches: Should the employee only comment/leave a note on their punch or should they edit? When should the loop end?

This identified the requirement for: ending the feedback loop, which naturally would be when payroll is processed, but we needed to get users to solidify the date.

Evaluating the risks and potential solutions in individual time punch vs timesheet approval. We decided to go with getting approval on individual time punches, but have a button that accelerates time punch approval on the timesheet level [Approve all].

Applied the different workflow maps in a lo-fi concept to the existing product screens, to further evaluate pros, cons and risks of our 3 options.

Before designing, we gathered feedback from the team and peers on our three options. Using this input, we defined our MVP’s scope to balance functionality and feasibility. The complexities at discussion at this stage were:

1. Alignment on how much tracking we want to provide? ( e-signature, date, reporting an audit trail to employees/managers)
2. Clarifying that attesting to time punches is not attesting to earnings ( as we did show both in the same context in app historically).
3. Giving employees edit access for correction of their punches.
4. Closing the feedback loop.

Survey the users

In order to find answers to the questions in our heads (mentioned above), we conducted a short survey and asked restaurant employees and restaurant managers about their perspective and current habits. Our survey was incentivized, so we got a 42% response rate and we got help from our Marketing team member in writing and publishing it. This was how the response looked like:

Based on our answers, we made some decisions for our next phase of design:

Wireframing lo-fi designs

We created wireframe designs for both mobile and web, based on our decisions and requirements. We started with mobile screens since they involved more complexity, including multiple actions, triggers, and system-defined states. Once the mobile experience was structured, we determined what the web app needed to display for managers and admins based on employee-triggered actions.

Before involving the users and validating the concept with them, we completed the logic of our flows in discussion and apply the decided logic for app the system to different scenarios. This helped us reduce complexity and ambiguity before we test the concept with real users.
 

💡 Translating the design to existing system:
When working with a product that already is used by a group of users, and is mature, every new addition of interaction needs acquiring a deep understanding of the system. The new solution should consider surrounding experiences, to ensure the users will not confuse the new functionality with old.

For this, we evaluated the new design against our existing system and features and made decisions to ensure the design is not blocking other experiences. An important piece to this solution, was not blocking the user from processing payroll or cause friction in their existing workflow.

User testing: uncovering user needs for guardrails, speed bumps, notifications!

We tested our prototyped mocks with 10 users, in both moderated and unmoderated tests. The user feedback was positive and promising. users understood how the system worked and had no issues with the system logic. They asked for additional features to go with this experience, which highlighted the importance of creating friendly user experiences, by setting guardrails, reminders and permissions.

1. How do I enforce this to my employees? make sure they respond before the payroll pay period ends?

2. Can we make sure employees don't dispute without a note or don't send nonsense notes about their punches that needs follow-up?

3. An audit trail of all the punch edits, and employee inputs is critical! It should come in the form of a printable report.

4. Managers/admins want this to be behind a setting based on different locations.

5. FTUX or clear instructions for the employees to understand the triggers and states.

WIREFRAMES

Final flow map & screens

Measuring success - HEART framework

With the help of our analysts, I used the HEART framework by google to measure the success in Happiness, Engagement, Adoption, Retention and Task success. The feature was adopted organically by 65% of customers post-release, even though the usage was hidden behind a setting in a buried area of the app, which indicates huge success. Retention analysis shows that nearly 80% of users who verify their punches return weekly, making it a sticky product now integrated into workflows for over thousands of restaurants.

Remove the unnecessary

Simplify UI & states in iteration

Since there was a lot of tech debt and old code involved with this project's area of work (Timesheets, time punches) we were not able to prioritize updated UI from the beginning of the development. Additionally, the mobile design system and FE tech was under development that would prevent us from some optimizations. After we released the first version of the product and monitored user behavior, ensuring it is easy to understand and use, we iterated on UI, simplified and removed the unnecessary elements in a fast follow.