workforce operations
CMS
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.
We extended our core platform to the physical workplace, improving awareness, accountability, and team coordination. Designed for dynamic manufacturing spaces, it helps teams track workflow, respond to changes, and make informed decisions—driving efficiency and reducing costly errors.
Timeline
6 months, released Mar, 2025
Team
Me, 1 PM, 1 engineer
Role
UX Lead, Strategy & Design
Overview
A display platform that helps manufacturing sites catch workforce issues before they reach invoicing.
The system started with one display for missing timesheet data and grew into five channels used across break rooms, production floors, hallways, and plant entrances.
I led the product design from research and early pilots through the CMS, scheduling system, design system, and rollout.
Impact
Results of improving visibility
60%
of missing time resolved the same day
4 hr → 1 hr
invoice cleanup per cycle
1 hr → 20 min
response time for unassigned workers
~8 devices
per plant across 3 manufacturers
Business Goals
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.
Problem
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 couldn’t see their own timekeeping status, so they often left the site without knowing there was anything to correct.
Errors were discovered when they were hardest to verify
Most missing time surfaced about a week later during invoice reconciliation.
“
— representative partner concern
problem Impact
1/10
Missing or incorrect timesheet data compounded into delayed invoices across every pay cycle.
30+ min
When staffing changed, it took half an hour to reassign workers — too slow for a production floor.
2+ hours
Agency managers spent time reaching out to supervisors to find out worker shift information.
Research
The same issue showed up across every role: problems were being discovered too late.
I interviewed temp workers, supervisors, agency on-site managers, manufacturing leadership, and security at multiple plants.
STAGE 01: Learn
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
Early iteration of missing timesheet data on display in the hallways of the work-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.
So I iterated on how the content communicated itself through labeling, framing, and state.
Recognition.
Customers had varying policies regarding the display of personal info.
So the identity block was designed as a flexible unit, using worker ID and initials.
Density.
Everything had to survive a walk-by in a crowded hallway.
Columns had to be consolidated and labels compressed into acronyms that stayed obvious to workers and staff.
Validation without product analytics
To know whether any of it worked, I kept two metrics in view:
Timesheet corrections.
The portion of timesheet errors left unresolved.
Allocation response time.
How long are unassigned workers waiting for a job.
Engineering was focused on higher-priority product work, so adding analytics to the pilot wasn’t practical. I still needed to know whether the display was changing behavior without turning validation into its own project.
I used a lightweight measure instead: count unresolved timekeeping issues near the beginning and end of each shift.
The pilot solved one workflow. The next problem was making it repeatable across plants.
STAGE 02: COntent & Device Management
How might we let each plant configure its own display network?
The first pilot proved the display concept, but every plant had a different physical setup.
Devices were installed in different locations, screens served different audiences, and each site needed control over what was shown where.
I designed the CMS around a simple hierarchy:
Plant → Location → Device → Display
Mapping the user flow for content management
Local administrators could register hardware, assign screens to locations, choose what each screen displayed, and manage configuration without involving design or engineering.
Let's see the final design of the CMS
The goal was not to create every possible display inside the CMS. It was to give each plant a stable way to configure and operate the hardware already deployed.
STAGE 03: Design System
Make every new channel feel like part of the same product.
Once more display types were being added, the problem changed.
Each channel served a different operational need, but workers were encountering 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.
I defined common rules for:
typography and viewing distance
information density
identity treatments
status and exception states
table structures
spacing and hierarchy
privacy variants
The system gave new channels a consistent foundation while still allowing each one to handle different data and workflows.
STAGE 04: AutomatE
Scheduling became necessary once plants were running multiple channels.
As the number of devices and channels grew, administrators needed more control over when content appeared.
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 new 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 main challenge was resolving conflicts between them: which rule wins, what gets replaced, and how an administrator knows what is actually going to 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 underlying configuration.
Next Steps
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.