Workforce Display CMS

I designed a shared information system for manufacturing operations. The worksite displays help workers correct timekeeping issues. They also communicate assignments, attendance and production status.

Displaying operations information keeps teams in sync.

Improving workforce management and invoicing

About 1 in 10 workers missed at least one clock-in each day.

Catch unexpected workforce issues early, because time is money.

• Reduce missing timesheet data before the team checks invoices.
• Let each plant manage its own displays without support from design or engineering.
• Create a reusable platform for additional workforce information.

Every team had the same problem: they learned about errors too late.

I interviewed workers, supervisors, staffing managers, factory leaders, and security staff at several sites. Workers often did not know when a clock-in failed. Teams found the missing time about a week later while checking invoices, when it was harder to confirm what happened.

Two groups rely on clear information on the floor.

How can we enable workers to self-correct clock-ins and clock-outs?

Workers often discovered a missed clock-in or clock-out only after leaving the site, when correcting the record was harder. I focused this challenge on surfacing the issue during the shift, so workers could self-correct before they left.

I started with one dataset that had the biggest impact

Timesheet corrections were a small issue that compounded. Addressing this could save manufacturers and agencies time and money. Starting small with our pilot site would allow the testing and iteration required to scale up to broader issues.

How it looked on-site

The challenges that surfaced

I tested an early version with workers at the pilot site. Their reactions showed three problems that I needed to fix.

Validating the impact of the pilot without built-in analytics

Engineering could not add analytics during the pilot, so I tracked two things: open timekeeping problems at the start and end of each shift, and how long unassigned workers waited for work.

How can worksites monitor, update and manage their displays?

The pilot worked, but factories had different screens, locations, and audiences. I needed the system to be flexible enough to address the needs of different work sites. I designed three parts: a channel holds one type of content, a program groups channels into a playlist, and a device plays that playlist.

Planning how administrators manage content

Before designing screens, I mapped every task an administrator needed to complete. This included creating content, grouping it into a playlist, and choosing what a device shows by default.

Mapping opportunities for new displays through worker journeys

I mapped the worker journey from arrival to production to identify what information would be most useful at each stop.

Turning the flow into screens

I turned each task into a screen that local administrators could use without support. They could add hardware, see what each screen was showing, and choose its default content.

Designing channel configuration to support complex business requirements

Each type of content needed different data, filters, timing, and privacy rules. I put those choices into channel setup. Administrators would get the autonomy to make adjustments instead of waiting for the product team to build a new screen.

Final design: flexible channel setup

The finished flow adapts to each channel’s data and rules, helping administrators configure and publish useful content with confidence.

Designing bundles to group channels

A channel holds one type of content and controls how long it stays on screen. A bundle puts several channels into a repeating playlist. This gave each factory a simple way to manage the screens it already had.

Advocating and building a design system to scale

Each channel served a different need, but workers saw them on the same screens. I created shared rules for type, spacing, status, and privacy so every channel felt familiar. With a design system in place, I could scale to support new use cases and operational data quickly while maintaining consistency.

How pilot testing informed the design system

• Typography required for the viewing distance in larger worksites.
• Information density per channel to shorten wait while maintaining scanability.
• Site privacy requirements for identity meant supporting alternatives like worker ID.
• Tokens required for the various status and exception states.
• Flexible table structures, spacing, and hierarchy for supported data types.

Research uncovered what the product needed to support

Factories asked for schedules, safety notices, open positions, access updates, and attendance. Schedules were a clear test case. Every site posted paper assignments that became outdated as soon as staffing changed.

Why do information displays need scheduling?

The audience of these displays changes through each day. Every shift brings new workers, and different information is relevant to them before, during and after those shifts. Scheduling would also enable temporary messages for special events and safety information.

Defining the scheduling workflow

I interviewed operations teams to understand weekly routines, shift changeovers, and schedule exceptions and updates. I led workshops with the product team to define the information architecture, workflow, and feature support for the scheduling overhaul.

Leveraging the mental model of the calendar

Everyone has used a calendar before, so administrators could start scheduling content for their devices quickly and without assistance. I designed scheduling to support easy setup of repeating schedules that align with shifts and gave devices default programs as a catch-all, making scheduling optional.

Final Design: Scheduler

The final scheduler gives administrators one familiar view to coordinate programs across devices, review timing, and manage schedule changes.

What I learned

• The phased approach gave time to identify issues and iterate so I could anticipate the design needs of the management system and future channels.
• Scalability over speed of execution. Advocating for and developing a design system cut the design and development time of the new channels drastically.
• Owning a product means having the agency to decide how to approach, design and validate the solution. This responsibility made the value to acquiring new customers even more gratifying.

Opportunities to expand

Use the existing display network for more communication

The same screens could show urgent messages, onboarding instructions, wayfinding and digital signage for larger sites, and company announcements.