Feature Design Existing System Industrial UX B2B

Smart Factory — Staggered Shift
Scheduling

A net-new feature added to a 3-year-old industrial IoT product in one week. The key design decision wasn't the new screens — it was restructuring the existing flow to resolve a data dependency the new feature created.

My Role
UX Designer II
Timeline
1 week
Organisation
HashedIn by Deloitte
Output
Final screens for client delivery

Adding to a system that already works.

The Smart Factory product was a 3-year-old industrial IoT platform for managing factory operations — equipment, workers, and production schedules. It already had a shift scheduling feature. The client needed to extend it with a new concept: staggered shifts, where different groups of workers start at different times within the same shift window to manage equipment load, reduce congestion, and comply with post-pandemic spacing requirements.

I was brought in with one week to design the feature end-to-end: understand the requirement, audit the existing flow, identify design dependencies, and deliver final screens for the weekly PM review before client delivery.

The constraint wasn't the new feature — it was fitting it cleanly into a system users already knew. No breaking changes. No new mental models if avoidable.

Finding the dependency before designing a single screen.

The first thing I did was audit the existing shift scheduling flow. Staggered shifts required knowing which equipment workers would be assigned to before their start times could be staggered logically — you can't stagger by equipment load if you don't know the equipment first.

In the existing flow, equipment assignment came after shift time setup. That ordering worked fine for regular shifts. For staggered shifts, it created a hard dependency: you were being asked to define stagger rules before you had the data those rules depended on.

💡

The key design decision: Move the equipment intelligence file upload earlier in the flow — before shift time configuration — so stagger logic has the data it needs when it needs it.

Reordering, not rebuilding.

The change to the existing flow was surgical. Equipment setup moved forward in the sequence. Everything else stayed in place. For users who didn't use staggered shifts, the experience was essentially unchanged. For users who did, the new order was logical — you set up what you have, then decide how to distribute it.

Before
Shift name → Time window → Worker assignment → Equipment setup
Equipment came last — fine for regular shifts, but stagger logic had no data to work with at the point it was needed.
After
Shift name → Equipment setup → Time window → Worker assignment → Stagger config
Equipment moved earlier. Stagger configuration now has the context it needs. Everything downstream stays intact.
Smart Factory flow restructure — before and after
Flow restructure — the existing flow (top) vs the revised flow with equipment moved earlier (bottom)

Two new interactions. One familiar system.

With the flow restructured, I designed the two net-new interactions the staggered shift feature required: the sub-shift definition modal and the break configuration modal. Both were designed to feel consistent with the existing product — same component language, same interaction patterns, new functionality.

Sub-shift Modal

Allows managers to define multiple sub-shifts within a shift window — each with its own start time, worker count, and equipment zone. Built to handle 2–6 sub-shifts cleanly without the UI becoming unmanageable.

Break Configuration

Staggered shifts create staggered break needs. The break modal lets managers set break windows per sub-shift, ensuring breaks don't cluster at the same time and create equipment downtime spikes.

Sub-shift configuration modal
Sub-shift configuration modal — define multiple start times and worker allocations within a single shift
Break configuration modal
Break configuration modal — staggered breaks mapped to each sub-shift

Designing in a system with history.

Working on a 3-year-old product in a week means working with constraints you didn't create. The existing component library was my starting point, not a suggestion. The existing user mental model was a resource to protect, not rewrite. The client's weekly review cadence was the real deadline.

💡

The discipline here wasn't creativity — it was knowing what not to change. The best outcome was a feature that felt like it had always been there.


Delivered. Appreciated. Shipped.

Final screens were delivered for the weekly PM review before client handoff. The client appreciated both the speed and the quality of the work. The staggered shifts feature was accepted without significant revision — the flow restructure decision in particular was noted as the right call.

One week is enough time to do this well, but not enough time to do it perfectly. I would have liked more time with the factory managers who actually use the scheduling feature — even two or three short calls would have sharpened my understanding of how shift complexity varies across different factory contexts.

The flow restructure was the right decision, but it was made based on logic rather than validated with users. It held up — but in a different context, that same reasoning could have missed a workflow edge case that only an experienced factory manager would know about.

← Equitek Back to All work →