HotSchedules / created for a fried chicken chain restaurant that you know and probably love
A report built with a table to view all employee punches - in, out, breaks, meals, late punches, etc.
Background on Punch Records Report - A Punch Records report is a tool that a company can use to view all punches of an employee: clocks in and out, meal breaks, late clock outs, forgotten punch ins etc.
About the project
This was a table created for a client who requested a new, updated, cleaner, easier to read at a glance, with more information. Tables are boring, but they are necessary. Our clients are mostly larger chains that view restaurant sales down to the third decimal point, something that I never even dreamed was a thing when I was working at smaller restaurants. Labor is always the biggest spend at a restaurant, and so this client wanted something more than we currently offered.
Secondary objective
This was our opportunity for us to start our “modernization” effort, updating the design system from Echo to BaseWeb. From this Feature forward all designs would be using BaseWeb.
Process
The objective was to update the Punch records report from a cluttered, hard to read export of an excel sheet to an in-browser, editable, glanceable table. I started with collecting the data of what we already had and what we could add - what was important to the user (who were generally managers or GMs), and took into consideration the size of the table horizontally. Scrolling is OK, but too much scrolling can disorient the user and make them lose sight of the task at hand.
Old Punch Table Records, left; redesigned table, right
Features
Building the table
There are two schools of thought on how to build tables - by columns, or by rows. There are benefits to each way, but I decided the best case in this scenario was by rows. The auto layout would make resizing easier for both me and the developers, and I could add or remove a field easily. Auto layout on top of auto layout on top of auto layout.
Filters on the report
I raised the question, based on other reports we offer, if the user should be able to filter and by what fields? When is too much freedom given to the user? I gathered all the possible fields the user would be able to filter by, created the filter dropdowns, and presented it to the Product Owners in our weekly meeting. In discussions with the POs and the rest of the UX team, it was ultimately decided to constrain the amount of filtering the users would be able to do. It came down to time and money spent on developing, and ease of use for the user.
Filter exploration, left; final design without filters, right
Problem statement
Solution:
Getting user feedback!
I had the amazing chance to sit on on a monthly Product Development meeting in which the Product Manager and Owner discuss product updates, concerns, and roadmaps with the customer. I was alloted 5 minutes at the end of the meeting to show off my design, run through the use cases, and get feedback. I recreated an entire shift at a specific store and ran through the current table and then my proposed design. The customer, in this case a regional manager for a number of stores in the NYC area, was thrilled. All of my assumptions were validated - she found it easier to read, to scan, and it had additional information that the current report didn’t include. After the meeting I got a thumbs up from the Product Owner and handed off the table to the developers. In handing off to the developers, I created a mock report with every single use case and edge case to try to minimize any confusion or questions.
Preview of the final design for handoff
Summary
Not everything UX designers do is sexy. This wasn’t the first or last table I’d created, but it was the most in-depth. I love creating tables - they can take on so many different forms and styles, but they are a key component in so many designs. And not every design process is linear. In fact, most aren’t. I designed this table on assumptions, which were validated after the fact in a conversation with the actual users. Having my decisions validated was incredibly satisfying. I felt great knowing that after the months long design process the user was getting a design that was going to be useful and make their lives easier.
Key contributions
