← Back to work

A new feature, a 3-year-old product, one week to ship.

The hard part wasn't the UI. It was rethinking the existing flow to make the new feature possible.

Role
UX Designer II
Type
Feature Design · Existing System
Timeline
1 week
Users
Factory Managers & Supervisors
Outcome

Staggered shift scheduling delivered end-to-end in one week, built, and deployed to the client. In the all-PMs review that followed, the project head called out the design work by name as meeting the delivery standard. The client CEO acknowledged the team's handling of tight deadlines and delivery speed. The structural decision to move the equipment intelligence upload to step one was what made the entire feature possible.

The brief

Smart Factory is an industrial IoT platform built at HashedIn by Deloitte, used by factory managers and supervisors to manage equipment, staffing, and shift scheduling across production facilities. One of the platform's early clients came in with an urgent request: staggered shift scheduling.

The requirement arrived as a structured Excel sheet, mapping each department and piece of equipment to multiple shifts, each with its own break windows and lunch slots. Motor, Gearbox, Bearing, Pump, each running two overlapping shifts, each shift with Break 1, Lunch, and Break 2 at different times depending on the department.

The existing system had none of this. Shifts were simple start-to-finish blocks. No sub-shifts. No breaks. No concept of multiple overlapping windows per production day.

Client Requirement: Shift Schedule by Department
Excel requirement showing departments mapped to shifts and break times

The challenge

Adding sub-shifts and breaks wasn't just a UI problem. The new structure required each shift, sub-shift, and break to be mapped against the equipment hierarchy. That mapping could only happen if the equipment data was already available when the user began configuring shifts.

In the original flow, the equipment intelligence file upload sat at step 6, at the very end. For simple shifts that was fine because equipment mapping wasn't needed during setup. But with sub-shifts and breaks now in the picture, the data had to exist at the start. The entire feature would break if the flow stayed as it was.

Old Flow vs. Revised Flow
Before and after user flow showing equipment upload moved from step 6 to step 1

The decision

When I mapped the existing flow against the new requirements, the dependency became clear. I brought it to the dev team, and they confirmed it: the upload needed to move to step 1. Their reasoning was also practical. The file took time to process, so uploading it first meant the equipment hierarchy would be ready by the time the user reached shift configuration, with no waiting and no dependency error mid-flow.

I restructured the flow with the upload at the front. The design system was already in place, so this was a flow change, not a visual rebuild from scratch. That freed up time to focus on the new components that actually needed designing.

What we redesigned

With the flow resolved, the remaining design work was concrete. The 24-hour timeline was extended to 26 hours, because staggered shifts can cross midnight and cutting the view at 24 hours would clip part of the production day. Tooltips were added to shifts and break blocks on the Gantt so supervisors could see details at a glance without opening a modal every time. The labels "Production Day 1" and "Production Day 2" were renamed to "Calendar Day 1" and "Calendar Day 2", which matched how factory staff actually talked about the schedule and removed the ambiguity. New modals were designed for creating sub-shifts, adding break windows within a shift, and mapping each to the equipment hierarchy that was now available from step 1.

Schedule Screen with Annotations
Annotated schedule UI showing 26-hour timeline, sub-shifts, and equipment hierarchy mapping
Break Configuration & Equipment Mapping Modal
Modal for adding breaks and mapping to equipment hierarchy

The result

The feature was handed to the dev team within the week, built, and deployed to the client. In the all-PMs review that followed, the project head called it out by name as design work done to standard. The client CEO specifically acknowledged how the team handled the tight deadline and met expectations on delivery speed.

For a platform still building its early client base, that recognition mattered. Getting the structural call right early meant the dev team had a clean handoff and there were no rework cycles in a week that had no room for them.

Explore other projects