Overview

Context

At my previous company, I worked on a shift-scheduling app. I chose to focus on managers who still scheduled the old-fashioned way, using paper, whiteboards, or spreadsheets, then photographing the result and texting it to their team. It's a real, costly workflow (not hypothetical), AI has an obvious high-leverage entry point (a strong first draft), and it forces genuine trust design decisions, how much a manager should rely on a schedule they didn't build themselves.

Problem

Their process wasn't missing one feature, it was the whole workflow:

• Build the schedule by hand
• Re-enter it into the app
• Discover problems days later: understaffing, accidental overtime, mismatched shift times
• About 1 in 10 published schedules needed a republish within 48 hours

Key decisions and trade-offs

Manual headcount input over historical inference

Existing schedule data came from the broken manual process this feature is meant to fix. Learning from it risked reproducing the same mistakes. Trade-off: one new manual step for the manager in v1, in exchange for a draft built on sound logic rather than bad history.

Warnings don’t block saving

Both the direct edit and the chat edit preview surface conflicts, but never stop the manager from proceeding. Trade-off: a manager could ignore a real problem, but blocking outright assumes the AI is always right and the manager never has context it doesn’t. The system informs, the manager decides.

Two visually distinct signal types, one shared pattern

Rule violations and low-confidence guesses use the same interaction (a marker plus a popover), but different colors. Trade-off: slightly more design and engineering nuance, in exchange for managers correctly reading severity at a glance instead of treating every flag the same.

Chat edits require a preview, no exceptions

Natural language is powerful for bulk changes, but risky if it acts silently. Trade-off: an extra confirmation step slows the fastest possible edit down, in exchange for the one safeguard that keeps an ambiguous instruction from silently changing someone’s pay or hours.

Gaps shown, not hidden

An unfilled shift looks different from every other state, deliberately. Trade-off: the draft looks less “finished” at first glance, in exchange for managers trusting that what looks filled actually is.

Risks

Trust breaks faster than it builds

One bad early experience, an accepted shift that turns out wrong, a chat edit that misfires, could undo several good weeks of adoption. Worth watching qualitative feedback early, not just the metrics.

Automation bias

Once the tool earns trust, managers may stop scrutinizing the draft altogether. If acceptance rate climbs while republish rate doesn’t improve, that’s a sign of rubber-stamping, not real review.

A new manual step, in a feature meant to remove them

Headcount input didn’t exist before. It’s a defensible trade-off, but it works against the feature’s core promise, and needs to be accounted for in the time-to-publish metric, especially early on.

The chat-edit safeguard is load-bearing

The preview step isn’t a nice-to-have, it’s the only thing standing between an ambiguous instruction and a silent change to someone’s pay or hours. If it’s ever cut for speed, that risk comes back.

Final Design

The feature follows one flow: generate → review → edit → publish.

Generate

The AI builds a full draft using existing data, availability, role requirements, labor rules, and cost constraints, plus one new input: headcount needs per shift, set manually by the manager. Shifts it’s confident about get filled. Shifts it isn’t get left open, visibly, rather than forced.

Review

The manager sees the draft in the familiar schedule grid. Two signals live side by side:

• A small marker for low-confidence AI guesses
• The existing rule-violation warnings, reused rather than duplicated

Same visual system, different meaning, so managers learn one pattern instead of two. Clicking a marked shift opens a popover explaining the reasoning behind it.

Edit

Two paths, one validation system:

• Direct edit: click a shift, change it, get live feedback if it creates a conflict. Saving isn’t blocked, the manager decides.
• Chat edit: describe a bulk change in plain language, get a preview of every affected shift before anything applies.

Publish

The schedule goes out. Any unresolved violation the manager chose to keep stays visibly flagged, rather than disappearing once it’s live.