Workforce Display System
Real-time displays on the manufacturing floor that surfaced missing workforce data while it could still be fixed — cutting same-day timesheet gaps to nearly zero and growing into a multi-channel display platform.
The workforce display system that keeps people informed and operations on track
Results of improving visibility
of missing time resolved the same day
invoice cleanup per cycle
response time for unassigned workers
Fix workforce data earlier, before it slows down invoicing.
- Reduce missing timesheet data before invoice reconciliation.
- Let each plant manage its own displays without support from design or engineering.
- Create a reusable platform for additional workforce information.
About 1 in 10 workers had incomplete timesheet data each day.
Timekeeping was unreliable at the point of capture
Missed badges, failed punches, and system errors regularly left worker records incomplete in daily operations.
Workers had no feedback when something went wrong
Workers could not see their own timekeeping status, so they often left the site without knowing there was anything to correct.
Errors surfaced when they were hardest to verify
Most missing time appeared about a week later, during invoice reconciliation.
“If I have no proof you were there, why should I be willing to pay you?”
workers with partial timesheet data
allocation response time per shift
spent on invoice reconciliation
Missing or incorrect timesheet data compounded into delayed invoices across every pay cycle.
When staffing changed, it took half an hour to reassign workers — too slow for a production floor.
Agency managers spent hours calling supervisors to reconstruct worker shift information.
The same issue showed up in every role: problems were being discovered too late.
I interviewed temp workers, supervisors, agency on-site managers, manufacturing leadership, and plant security across multiple sites. Timekeeping failed at the point of capture, workers got no feedback, and errors surfaced a week later during invoice reconciliation — when they were hardest to verify.
How might we surface missing time while the worker can still act on it?
We had to pick a starting point, and missing clock-ins made the case for themselves.
How it looked on-site
The challenges that surfaced
I put an early version in front of workers at the pilot site, and watching them use it shaped everything that followed. Three problems drove the iteration.
Purpose
Workers misread the board, and some thought being listed was a good thing. I iterated on how the content communicated itself through labeling, framing, and state.
Recognition
Customers had varying policies about displaying personal info, so the identity block became a flexible unit using worker ID and initials.
Density
Everything had to survive a walk-by in a crowded hallway. Columns were consolidated and labels compressed into acronyms that stayed obvious.
Early design strategy
Start narrow and prove the behavior: one channel, one placement, one pilot site. Scope stayed on missing time, placement on the hallway workers already walked through, and the flow on understand → find → act.
Validation without product analytics
Engineering was focused on higher-priority work, so instrumenting the pilot wasn't practical. I used a lightweight measure instead: count unresolved timekeeping issues near the beginning and end of each shift, and track how long unassigned workers waited for a job.
How might we let each plant configure its own display network?
The pilot proved the concept, but every plant had a different physical setup. Devices sat in different locations, screens served different audiences, and each site needed control over what was shown where. I designed the CMS around composition: info channels are the units of content, channels are sequenced into a program, and a program is what a device plays.
Mapping the user flow for content management
I mapped the end-to-end flow for administrators before designing screens: creating and editing channels, assembling them into channel bundles, and setting a device's default program — including the delete confirmations, the no-data cases, and the open questions we still had to settle with operations.
Turning the flow into screens
Each branch of that flow became a screen local administrators could operate on their own: register hardware, see what every screen is playing right now, and set what a device falls back to.
Channels and bundles in the CMS
Channels hold the content and its page duration; bundles sequence channels into a loop a device can run. The goal was never to build every possible display inside the CMS — it was to give each plant a stable way to configure and operate the hardware already deployed.
Make every new channel feel like part of the same product.
Each channel served a different operational need, but workers encountered all of them through the same network of screens. Without shared rules, every new channel risked becoming its own visual language.
Turn the patterns from the pilot into a reusable system
- Typography scaled to viewing distance.
- Information density per channel and location.
- Identity treatments and privacy variants.
- Status and exception states.
- Table structures, spacing, and hierarchy.
Discovery surfaced use cases to test the design system
The channels plants asked for included upcoming schedules, safety notices, open positions, access control, and attendance for the production floor. Upcoming schedules is a representative one: every site we visited posted the next shift's line assignments as printed sheets on a board, stale the moment staffing changed.
Configuration had to keep pace with the channels
Every channel a plant asked for arrived with its own configuration — the data it reads, how that data is filtered, how long each page holds, which identity and privacy treatment applies. Rather than add a screen per channel type, the CMS absorbed that variety into channel setup itself, so a new customer requirement could be met by configuring a channel rather than building one.
Scheduling became necessary once plants were running multiple channels.
A screen might show one channel during shift change, another during production hours, and need a temporary override for a specific event. That introduced a layer of complexity beyond device configuration.
Design the scheduling model before the interface
I worked with operations stakeholders to map recurring schedules, shift-based rules, and one-time overrides. The hard part was conflict resolution: which rule wins, what gets replaced, and how an administrator knows what will actually appear on a device.
Use a model people already understand
The final scheduler used familiar calendar conventions for recurring programming, time blocks, and overrides. Administrators could see what each device would display throughout the week and make temporary changes without rebuilding its configuration.
Opportunities to expand
Use the existing display network for more communication
The same hardware could support urgent messages, onboarding, wayfinding, internal announcements, and other high-priority workforce information.
What I learned
The real design material was legibility of intent. The same list of names can read as praise, an accusation, or a prompt to act — and we only learned which by watching people misread it. The unglamorous middle mattered too: building the CMS and design system before more channels is the reason each new channel took days instead of months.