Turning schedule input into downtime data you can trust
Loopline’s Operations Monitor is a concept for recycling operations managers. An AI system watches the conveyor belts and detects two kinds of lost time: downtime, when the belts stop, and empty belt time, when they run with no material on them. To tell a real stoppage apart from a lunch break or the end of a shift, the AI needs the manager’s shifts and breaks. I designed how managers enter and edit them.
Operations managers need a quick way to set up their usual schedule and adjust it when real life gets in the way: holidays, repairs, overtime or longer breaks. If the schedule is wrong, the metrics are wrong. Planned breaks show up as downtime, and the manager stops trusting the product. The challenge was to make an admin task that feels like a chore fast, clear and hard to get wrong.
The brief set two design principles that guided every decision.
Use visuals that are easy to understand. Managers shouldn’t have to interpret or analyze anything to know what will happen.
Minimal interpretationFeatures, colors and patterns behave the same way across the whole app.
Same patterns everywhereMapping the manager’s situations side by side showed three patterns:
A proto-persona, built from the brief’s scenarios rather than interviews.
Daniel runs a recycling center with two shifts a day. He spends most of his day on the floor, not at a desk. He checks the dashboard in the morning and sometimes at night from home, and he’s the one who answers when the numbers look wrong.
Each scenario from the brief became something the design had to handle:
| Scenario | What the manager needs | How the design handles it |
|---|---|---|
| 1. Long-term planning | Enter shifts and breaks for the coming months | Edit schedule sets operating days, shifts and breaks once, as a standing schedule that repeats every week, with a live weekly preview. |
| 2. Holiday | Remove the shifts on the holiday and add them back the day after | Add exception → Holiday / closed day. The preview lists every shift that will be removed before anything is applied. |
| 3. Late start tomorrow | Start one hour later to make time for repairs | Day actions → Edit this day. Changing Shift 1 to 7:00 AM marks it as Modified, updates the day summary and saves as a Late start. |
| 4. Longer breaks, live | Give the crew more rest when the plant is ahead of schedule | Add exception → Break adjustment, or edit the exact break times for that day. |
| 5. Overtime | Run one extra hour | Add exception → Overtime, or move the shift’s end time. Either way it saves as Overtime. |
| 6. Retroactive fix | A break was logged as downtime; fix it from home | Open the past day → Edit this day → move the break, so the metrics can be recalculated. |
| 7. New operating days | Switch from Mon–Fri to Tue–Sat | Edit schedule → operating days. The weekly preview updates as days are toggled. |
Most scenarios are one-off changes, so I split scheduling into two layers. The standing schedule is the normal week: set once, repeated automatically. Exceptions change specific dates and override the standing schedule without touching it.
It works like a recurring meeting in a calendar: you can move one meeting without changing the whole series. Managers always know what’s normal and what’s special, and one click brings a day back to the standing schedule.
Add exception opens with the type of change: Holiday, Late start, Early end, Overtime, Break adjustment or Custom. The manager picks what happened in their own words, and the form only asks for what that change needs.
Every edit shows its result next to the form: the weekly preview in Edit schedule and “Impact on schedule” in Add exception. Removed shifts are crossed out, so nothing happens by surprise.
Edited shifts and breaks get a Modified or Unchanged label, the original time stays visible, and a day summary shows the final result. An “Unsaved changes” status sits next to Save.
Rules like “breaks must fall within their shift” are checked as the manager types. The field turns red, the message says exactly what’s wrong, and Save stays disabled until it’s fixed.
Editing a day by hand is classified automatically: moving a start later saves as Late start, ending earlier as Early end. The same names appear in the calendar, the day view and the alerts.
A short, dismissible banner connects the task to the outcome: accurate shifts and breaks let the AI tell downtime apart from planned breaks. It turns admin work into something with a purpose.
The brief asked for consistency, but the first version broke it: the same orange meant “empty belt” on the overview and “break” on the schedule. I moved every status to a named token, so each color means one thing on every screen.
status/running#81D307status/empty-belt#FBBF24status/downtime#E52525status/planned-break#E25E00schedule/exception#7C3AEDstatus/no-operation#A3A3A3Two flows built as clickable prototypes, recorded in action. Click a recording to watch it larger.
Pick Holiday / closed day, check which shifts will be removed, and apply. The week and day views update, with an Undo.
Open tomorrow, edit the day, move Shift 1 to 7:00 AM and save. Moving a break outside its shift shows the validation.