Break in/out
Build a feature that allows restaurant staff to quickly log breaks and enables managers to easily track break durations.
User interview, User Flow, Information architecture, Prototype, Usability test
Deliverables
Restaurant staff logging breaks during shifts and managers tracking break times to ensure accurate payroll processing.
Target User
Sole Product Designer
My Role
5 weeks
Duration
Overview
About Lightspeed
Lightspeed is a cloud-based platform for hospitality businesses, offering tools to streamline operations and drive growth. It features two core products:
BackOffice: Web app for managing menus, sales, and staff operations.
POS: Native app for handling sales and customer interactions, integrated with BackOffice
Problem statements
-
Breaks are communicated verbally between staff and managers, making the process time-consuming and prone to mistakes.
-
There’s no efficient way for managers to track staff breaks, leading to inaccurate labor reports and payroll errors.
Goals & Metrics
By integrating a new feature into both BackOffice (web app) and POS (native app), we hoped to:
-
Enable managers to easily configure break types and rules.
-
Provide staff with an intuitive way to log different types of breaks.
-
Improve the Hours report, and integrate break details.
Process
I led the end-to-end design of this feature, and worked closely with PMs, engineers, QAs and stakeholders from global teams to deliver user-centred and feasible design.
Outcomes
Quick glance
Empathise
User interview
I conducted user interviews with 8 restaurant managers who handled Hours report and worked closely with front-of-house staff, to better understand their needs and pain points.
Research objectives
-
Define break rules, types, and their implementation.
-
Understand how managers set up and manage breaks.
-
Analyse workflows where front-of-house staff take breaks.
-
Understand the purpose for tracking and analysing break data.
-
Uncover frustrations with current workarounds and identify real needs.
Findings synthesis
I collected all the data and key information from user interviews and organised them into a table to generate insights and prioritise tasks.
Define
Key insights
User interview findings were summarised into actionable insights. This ensured that all design decisions were human centred and based on real user data.
Priorities
I organised user needs on an affinity map, and facilitated meetings with the PM to determine our priorities moving forward in the process.
Ideate
Jobs-to-be-Done
Before starting ideation, I divided the design tasks into 3 parts, focusing on the key JTBDs.
Part 2 - Log breaks in the POS
Issues
The existing Clock in/out feature offered similar functionality but couldn’t be simply reused for Break in/out due to its confusing UX.
The Break in/out feature was built on top of the existing feature - Clock in/out, which allowed staff to log the start and end of their shifts. It couldn’t be simply reused for logging break in/oyt time, due to its confusing layout, overwhelming patterns, and inconsistent copy.
Approaches
Divergent: keeping an open mind for all creative ideas
I developed several design options, including ideal solutions that improved Clock In/Out and integrated Break In/Out, and simpler alternatives that were easier to implement.
Convergent: collaborate with PMs and engineers to narrow down to the best / most feasible solution
I presented the design options to the PMs, engineers and stakeholders from the POS squad. After weighing the pros and cons and considering development input, we decided to:
-
select Option 2: recycle the two-column layout for Break in/out to reduce learning curve
-
make small, strategic improvements to simplify the UI & UX
-
plan a future project to fully redesign Clock In/Out based on my most ideal solution
Validate
Usability tests
I developed clickable prototypes to test the new feature with 10 users. In the moderated tests, most users completed the tasks successfully.
Design iterations
At the same time, a couple of issues were revealed in the test. For example,
-
to hide the “Paid”/“Unpaid” label on break buttons, as it’s sensitive
-
to add an in-line Add button for users to quickly add sessions for a staff on a specific day.
I iterated on the design and then move on to the high-fidelity prototypes.
I wouldn’t surface the unpaid or paid information at all in the POS. It’s a sensitive topic for waiters in general
It’s strange that unpaid and paid are listed here. Employees should know about their breaks.
How can I add a new session then?...Oh, it’s at the top...It would be very handy if I can add new sessions directly here in the table.
Part 3 - Track & Edit breaks in the BackOffice
Issues
The legacy Hours report’s unclear structure made it difficult to add break details without improvements.
The existing Hours report was used to track and edit staff working hours, making it a natural place to add break details. However, its unclear structure would lead to repeated information and disjointed steps.
Approaches
Conducted a survey and analysed Heap data to understand how these report pages were used.
I conducted a quick survey via Intercom to understand how users engage with these report pages, and analysed data and session replays on Heap to identify common user journeys.
Optimised report pages using key research insights
Reasons:
-
The Overview page duplicates information from the Monthly Hours page.
-
Both pages serve the same primary purpose: retrieving payroll data.
-
An additional purpose for the Monthly hours page is adjusting the working hours.
-
Comparing different time periods on the Overview page is rarely needed.
-
Users primarily visit the Overview page for its more flexible time filter.
-
Many users navigate to Monthly Hours immediately after visiting Overview.
-
Reasons:
-
Its sole function, adding sessions, is also available on the Monthly Hours page.
-
More users add sessions directly on Monthly Hours.
-
Many users visit New Session after Monthly Hours, and then go back to Monthly hours.
-
Related functions like deleting and adjusting sessions are built on Monthly Hours.
-
Added break types and durations to the new report pages
After improving the Hours report, I added Break In/Out details (paid/unpaid break hours) and updated the page names with the Content Designer.
Design System
Issues & Approaches
Some components weren’t ready, so I collaborated with the Design System Designer on temporary workarounds.
I gathered feedback from the design system designer, product manager, and engineers before moving to hi-fi prototypes. Since some Phoenix components were still in development, we opted for temporary workarounds instead of waiting, due to timeline constraints.
Hi-Fi Prototype
Add icons and time to visually differentiate the two columns. Help users quickly find their names.
Remove unnecessary info (e.g. role tags) from the name card to keep users focused on the key job-to-be-done.
Include key info on buttons to help users identify breaks and remind them when to return to work.
Set up break rules in the BackOffice
Log breaks in the POS
Track & Edit breaks in the BackOffice
Going forward
Next steps
-
The feature has been handed over to engineers, and I’ve iterated on the design to address edge cases identified by QAs.
-
After releasing the feature, we would love to track:
Feature Adoption Rate – % of users using the feature.
Task Success Rate – % of users successfully logging and tracking breaks without assistance.
Time to Log a Break – Average time it takes for staff to log a break vs. the manual process.
Reduction in Payroll Discrepancies – % decrease in incorrect labor reports and payroll.
User Satisfaction Rate – % of users reporting that break tracking is intuitive and efficient.
-
In the next step, I will also work closely with the POS squad and adjust the design of breaking in/out after improving the whole clocking in/out flows.
Lessons learnt
-
The best design isn’t always the best option — we must consider feasibility, viability, and project timeline.
-
Testing the design early is very important. When a problem evolves, it is crucial to react timely and reiterate to come up with a solution that allows the project to move forward.
-
With the complex level and short time frame of this project, it is extremely important to stay focused on the most important areas without going too deep in details.