Rebuilding the
Schedule
Taking ShopView's most data-dense screen from a single cramped day-grid to a modern, multi-view scheduling system, redesigned end to end, specced, and handed to the squad I now lead in build.
At a glance
One screen, two eras
The schedule is where foremen, advisors, owners, and technicians all meet. The old version made that meeting point the hardest screen in the app to use. Here's the shift in one look.
Context & role
The busiest screen in the product
ShopView runs the day-to-day of heavy-duty service shops, the businesses that keep trucks and trailers on the road. The Schedule is where the work actually gets distributed: who's doing what, on which bay, for how long.
It's also the screen with the most stakeholders looking at it at once, which is exactly why its problems hurt so much.
My role. I led this as both product designer and product manager, owning the research and redesign, then writing the PRD and success metrics, and now leading the feature squad building it. The dual role meant the design decisions and the delivery plan were never out of sync.
Everyone who touches a job passes through the schedule, each needing something different from the same grid:
Foreman
Oversees technicians and work orders, assigning and re-shuffling work as the day changes.
Service advisors
Promise realistic turnaround times to customers.
Technicians
See what they're on next and where their day stands.
Owners / managers
Read shop capacity and utilization at a glance.
The problem
A scheduling tool that fought its users
I ran a full audit of the existing schedule. Underneath the surface issues, five structural problems kept the screen from doing its one job: helping a shop see and plan its day.
A note on the screenshots. The audit ran against a staging environment, so some of what's visible (internal department names, repeated test technicians, "New Company" records) is seed/test data, not the shipping product. I've deliberately separated those data-quality artifacts from the genuine UX and structural problems below, which are what the redesign actually targets.
Day view was the only view
No week, month, or agenda view. "Today" only jumped back to the current day; it wasn't a view switch. Planning ahead meant clicking day-by-day with arrows.
Impact: forward planning was effectively impossible on the tool teams used all day.
Lost in a massive grid
24 columns × hundreds of technician rows, opening at 12:00 AM with no "now" line, no jump to working hours, and no sticky time header. You scrolled to find the present.
Impact: constant manual scrolling just to reach the part of the day that mattered.
The grid didn't read as time
Dropped work orders showed as flat text lines, not blocks proportional to their duration, so the calendar lost the one thing a calendar is for: showing how long things take and where the gaps are.
Impact: duration and availability were invisible at a glance.
No live search, no empty states, no confirmation
Search only filtered on Enter, with blank space instead of a "no results" state. After a drag-and-drop assignment, the order stayed in the Unassigned list with no toast, so you couldn't tell if it worked.
Impact: users doubted whether their actions landed.
It broke below desktop
Around 768px the sidebar and primary navigation vanished with no replacement menu; the panel opened as a half-transparent overlay across the grid. There was no real strategy for a dense grid on smaller screens.
Impact: unusable for anyone away from a wide monitor.
Long jobs became one unbroken shift
A work order with a long estimate couldn't be spread sensibly across days. The only option was a single continuous shift running start to finish, straight through evenings and weekends, as though the shop never closed. There was no model of business hours, technician hours or defaults, no way to edit a shift's hours afterwards, and no capacity view to show whether a shop was over-committed or someone was heading into overtime.
Impact: the schedule drew a bar across the calendar instead of representing how a shop actually works.
Death by a thousand cuts
Minimal modals with no descriptions or recurrence, a "Time Estimate" with no unit, color swatches with no meaning, unlabeled icon controls, and accessibility gaps in the mini-calendar all added friction on top of the structural gaps.
These informed the detailed design decisions later in the process.
The workaround that gave the game away
Shops were inventing fake technicians: adding a person who didn't exist, purely so unassigned shifts had somewhere to sit on the grid.
Research & discovery
Listening to a year of workarounds
I pulled together the customer requests and complaints the team had been collecting and clustered them. Five themes emerged, and underneath them, one pattern that reframed the whole project.
People couldn't see time the way they think about it
The single most common ask: day, week, and month views, plus technician and department views, and a schedule that opens at business hours, not midnight. Sticky day/time headers so a shift never loses its column on scroll.
Signal: the tool only offered one lens on time; every planning horizon beyond “today” was a fight.
Users were doing the scheduling math in their heads
Requests for working hours, scheduled-vs-available time calculations, and capacity planning. The big one was carryover: a job that won't finish today should roll its remaining time forward, and a month-long work order dropped on the schedule should lay itself across each day, working and non-working, automatically.
Signal: the schedule displayed data but didn't model time or capacity, so people compensated manually.
To do the work, you had to leave the schedule
To assign a technician, you clicked into the work order in a separate tab, assigned lines, and closed it back down. You couldn't schedule at the work-order-line level (only whole WOs), couldn't see WO status on the schedule, and couldn't reassign, add notes, or change colors in place. The left-pane cards even truncated dates, forcing another tab just to read them.
Signal: the one screen where all the work converges pushed people off it to get anything done.
No way to search or filter
On a grid with dozens of technicians and hundreds of work orders, there was no functional search and no filters; you scanned by eye.
Signal: the denser the shop, the less usable the screen became.
It looked washed-out and read as empty
Low contrast, flat styling, and thin information on each block meant the screen felt lifeless and gave little at a glance, even when it was full of work.
Signal: visual hierarchy wasn't carrying any of the operational weight it needed to.
The most telling detail. Shops were creating fake technicians (real-looking people who didn't exist) purely so unassigned shifts had a row to sit in. The old schedule forced you to name an assignee at the moment you created a shift, but that isn't how the work arrives: often you know a job needs doing and a rough duration long before you know who's free to take it. With no way to stage that, users manufactured one. When people build a workaround this elaborate, it's a map to something the product should have modelled. Here, that was the gap between scheduling work and assigning it.
Mental models
Borrow the familiar, build the hard part
For interaction patterns I looked at the tools people already know: Google Calendar, Calendly, and Notion. In a tool a shop lives in all day, familiarity is a feature: reusing established view-switching, time-block, and working-hours conventions means near-zero retraining.
Those are general-purpose calendars, though. The domain logic (carryover, capacity, work-order-line scheduling) had no off-the-shelf pattern to copy, so I designed it from the complaints themselves.
Familiar interaction (view toggles, proportional blocks, business-hours defaults) borrowed from consumer calendars.
Novel domain logic (capacity, carryover, line-level scheduling) designed for the heavy-duty shop world specifically.
The insight that reframed the project
The schedule was a dead end, not a workspace. Every real task (assigning a tech, checking status, reading a date) forced users off the one screen where all the work converged. The redesign's job wasn't to decorate the calendar; it was to make the work happen on it.
Definition
Reframing the brief
The requests asked for features: a week view, a search field, better colours. Taken literally, that's a patch list. The insight underneath them pointed somewhere more useful: the schedule needed to stop being a report of the shop's day and start being the surface the day is run from.
The brief I wrote for myself. Turn the schedule into the shop's operating surface: a screen that models time and capacity honestly, lets every scheduling task finish in place, and stays readable at real shop density.
The jobs to be done
Restated from the five research themes as jobs rather than requests. Each one is what a user is actually trying to accomplish when they open the screen.
- Plan a horizon
- “Let me see the shop's time the way I'm thinking about it.” Whether that's the next two hours, the week, or a month-long job, the view should follow the planning horizon, not force one.
- Commit with confidence
- “Tell me whether this work fits before I promise it.” Capacity, working hours, and carryover computed by the tool instead of estimated in someone's head.
- Act in place
- “Let me assign, move, and annotate without leaving the screen.” Down to the work-order line, the unit shops actually schedule against.
- Find one thing
- “Get me to a specific job in a grid of hundreds.” Live search and filters that narrow the grid, not a scan by eye.
- Read the room
- “Show me the state of the shop in one look.” Status, duration, and load legible from across a desk, with density carrying information rather than noise.
Principles I designed against
Four rules I used to settle the dozens of smaller decisions that follow, and to say no to features that didn't serve them.
The work happens here
If a task sends the user to another tab to finish, the design has failed. Every scheduling action resolves on the schedule.
Settled: drag-and-drop assignment and reassignment, line-level scheduling, editable blocks, status visible on the grid.
Model time, don't just draw it
A calendar that can't do arithmetic pushes the arithmetic onto people. Duration, capacity, working hours, and carryover are the product's job.
Settled: proportional blocks, capacity math, automatic carryover and multi-day spread.
Borrow the familiar, build only the domain
Interaction patterns come from calendars people already use. Invention is reserved for the heavy-duty logic that has no precedent.
Settled: conventional view switching and time blocks; original capacity and carryover behaviour.
Density is information
A full shop should look full. The answer to a dense grid isn't emptier styling; it's hierarchy that makes density readable.
Settled: contrast and typographic hierarchy doing operational work, not decoration.
What actually boxed us in
The old screen had no defenders, but it had users, and it had their data.
Nobody argued to preserve the old schedule's behaviour, which freed the redesign to start from the job rather than from the screen. But two things were non-negotiable.
- Don't break anyone
- Existing schedules had to survive the rollout. Plenty of shops don't use the schedule at all, but plenty do, and some have hundreds of shifts entered by hand. In a tool that made entry that laborious, those schedules represent real hours of work. A redesign that reset them would have destroyed more value than it created, so whatever shipped had to inherit that data intact.
- Ship it sooner
- Time was the other pressure, and we answered it with scope. Rather than delay a usable schedule to land every capability at once, we cut deliberately and set a v2 line. Every omission below buys speed; none of them were judged unimportant, only deferrable.
Cut from v1
Three deliberate omissions, each with a trigger for when it returns.
The vertical day timeline
Day, week and month all ship, but the hour-by-hour vertical layout for a single day didn't make v1. Week is the horizon most planning actually happens in, and it was the view the research kept pointing at.
Returns when shops tell us they're planning inside the day rather than across the week.
Reassignment from inside the modal
Reassignment itself ships: you move a shift to another technician by dragging it across the grid. What's deferred is doing the same thing from within the work order modal.
A redundant second path, not a missing capability. The direct-manipulation route was the one worth building first.
Full calendar awareness
Shifts generate against technician hours, business hours and default settings, and weekends drop out when no hours are set. Closing times, public holidays and individual time off aren't modelled yet.
Partial by design: the common case is automated, the exceptions still need a human.
Why draw the line there. Each cut removes work the tool could do for you, not work you can no longer do. Nothing on this list blocks a shop from scheduling its week; they make the tool less clever, not less usable. That was the test every candidate cut had to pass.
The reframe in one line
Not “add a week view.” Make the schedule the place the work happens.
Exploration
One decision, reconsidered
Most of this redesign moved in a straight line, because the research had already narrowed the options. One interaction didn't, and it's the one worth showing: what should happen the moment a work order lands on a technician.
first attempt
Ask first, act second. The drop opened a chooser: schedule the whole work order, or pick a line from the list underneath. Both paths were laid out as options to weigh, and neither produced a result until you committed to one.
what shipped
Assume, then offer the exception. The whole work order is now the default, resolved on arrival, with the resulting shifts already computed. Line-level scheduling moved to a second tab, one click away for the cases that need it.
Why it changed. The first version treated two unequal choices as though they were equal. Scheduling the entire work order is what happens most of the time; splitting it into lines is the exception, however important. A modal that opens with a question makes every user pay for the exception, and it delays the thing they actually came to do. Defaulting to the common case removed a decision and a click from the frequent path without taking anything away from the rare one.
The second version also does something the first couldn't: it shows its work. Thirteen shifts, Aug 19 to Sep 4, weekdays only, sized against that technician's hours. The old chooser could tell you a work order was 104 hours; it couldn't tell you what booking those 104 hours would actually do to the calendar.
The redesign
A schedule you can work in
Every capability below answers a specific problem from the audit. Nothing here is decoration; the visual change is a by-product of making the screen model the shop's day honestly.
Week view, technicians grouped by department. Blocks are proportional to estimated duration and colour-coded by customer; the header carries per-day capacity bars and overtime flags, with a live conflict count beside the date range.
Day, week and month, plus somewhere to park the unassigned
View switching sits where people expect it, top right. The left rail keeps a month calendar for orientation and, beneath it, a searchable queue of work orders that aren't assigned to anyone yet, and each department's header row can hold unassigned shifts inside the grid itself.
Between them, that's the fake technician made real: scheduling and assigning became separate steps, so nobody has to invent a person to hold the work.
The grid tells you where you are
Days carry their date and a capacity bar; today is highlighted; departments group technicians into collapsible bands so a large shop stays navigable.
Orientation is ambient rather than something you scroll to find.
Blocks that mean something
Each block is sized to its estimate and carries customer, work order number, line count and job description. Colour separates customers; the warning icon marks a conflict.
Duration, load and trouble are all legible at a glance.
Search and filters that narrow the grid
Live search over work orders, filters on the queue, and a conflict count that doubles as a filter: a way into the problems rather than just a warning about them.
Shop density stops being the thing that breaks the screen.
The tool does the time arithmetic
Shifts generate against business hours, technician hours and defaults, so a long job spreads across working days instead of running as one unbroken bar through the weekend. Scheduled-versus-available time is computed per day and shown as a bar, with overtime flagged rather than discovered later.
You can see whether work fits before promising it.
Drag to schedule, drag to reassign
Unassigned work orders drag from the left-hand queue straight onto a technician's row. A shift already on the grid can be picked up and dropped onto someone else to reassign it, or moved to a different day to reschedule it.
This is the capability that makes the screen a workspace rather than a report: the whole thesis in one interaction.
Schedule a line, not just a work order
The old schedule could only place a whole work order. The new one lets you schedule a single line, several lines, or the entire order, so a 104-hour job doesn't have to land on one technician on one day.
The unit of scheduling finally matches the unit shops actually plan against.
What happens after a drop. The modal assumes the common case: the whole work order, estimate already resolved. Underneath it shows the consequence rather than making you infer it, 13 shifts spread from Aug 19 to Sep 4, Monday to Friday, sized against each technician's hours. Weekends drop out on their own. Scheduling individual lines lives one tab across, for when the job needs splitting.
The interaction the stills can't carry. A work order is dragged out of the unassigned queue onto a technician, the modal opens with the estimate already resolved, and the shifts land on the grid spread across working days. Everything above is a consequence of this one gesture.
Validation
Reviewed by people who run shops
The redesign is in build and hasn't reached customers yet, so there's no usage data to report. What it has had is review from two groups with unusual standing to judge it, and it's worth being precise about what that does and doesn't establish.
- The CS team
- The people who take the call when the schedule fails. They hear the same complaints repeatedly and across many shops, which makes them a reliable read on which problems are widespread rather than local.
- The founders
- They run heavy-duty service shops, and those shops run on ShopView. They're operators before they're stakeholders: they schedule real technicians against real work, and they hit the product's limits during their own working day. That access is the reason the research could go as deep as it did.
What the review changed
Both changes were subtractions, and both made the product simpler than the version that went in.
Technician view and department view merged
The design carried separate views for technicians and departments. Review made it obvious they didn't need to be separate: whoever is scheduling almost always wants to know which department a technician sits in, so splitting that across two views forced a switch to answer one question.
Merging them removed a view, and the department header it produced turned out to be the natural home for that department's unassigned shifts, right inside the grid where the fake technician used to sit.
The five-technician cap came out
A work order line could take at most five technicians, a technical constraint from an earlier era of the product that nobody had revisited. It forced a whole interaction to exist: assign a sixth person and a modal had to ask which of the five you wanted to swap out.
Removing the constraint removed the entire reassignment flow with it. Assign as many technicians as the job needs; the question the modal existed to ask no longer comes up.
Beyond those two, the review confirmed rather than redirected. Every other gap it raised matched something already in the audit. Its value there was specificity: naming which absences hurt most in daily use, and producing the clearest single example of the old model failing: a long work order that could only be booked as one unbroken shift running straight through the weekend.
What this evidence covers, and what it doesn't
Being clear about the limits is what makes the rest of it worth anything.
Whether the model is right
Does the tool match how work actually arrives in a shop? Does it hold up at real density: hundreds of shifts, jobs spanning days, technicians across departments? Is the work-order line the right unit to schedule against? Those are questions only someone who runs a shop can answer, and they answered them.
Whether a new shop can learn it
These are the most expert possible users of both the domain and the product, and they want it to succeed. They navigate fluently because they already know what the screen is meant to do. A shop opening this cold in month one is a different test, and it hasn't happened yet.
What I'll measure at launch
Each metric is tied to a specific claim the redesign makes, so a flat result tells us which argument was wrong.
- Workarounds die
- Fake technician accounts, trending to zero. The cleanest signal available: a workaround users built by hand should disappear once the unassigned queue makes it unnecessary. If those accounts persist, the queue didn't solve what we thought it solved.
- Reach
- Shops and users on the schedule, and shifts created. Baseline adoption. Worth tracking, but it will rise simply because the feature shipped, so it can't carry the argument on its own.
- Depth, not just reach
- The share of shops using week and month view rather than staying in day view. The whole thesis is that planning horizons were missing. If shops still only ever look at today, the redesign changed the screen without changing the behaviour.
- The new units get used
- Shifts created from individual lines versus whole work orders, and how long jobs get scheduled now. Line-level granularity and multi-day spreading were the two most expensive things to build. Usage tells us whether they earned it.
- Trouble gets caught earlier
- Conflicts and overtime flags resolved rather than ignored, and schedule-related support tickets. Capacity signals only matter if they change what someone does before committing the work.
Handoff & delivery
Owning it through build
I was the designer and the product manager on this, so handoff wasn't a transfer of responsibility; it was the point where the job changed shape. The work below is what I'm doing now, while it's being built.
- The PRD
- A full specification for the schedule, written before a line of it was built. The demanding part wasn't describing the screens; it was pinning down the domain logic that had no precedent to copy: how carryover behaves, how capacity is calculated against business, technician and default hours, what happens when a work order's lines are scheduled separately. Ambiguity in a spec becomes someone's guess in a pull request.
- A demo, not a document drop
- I presented and demoed the whole feature to the team rather than sending a link. Everyone saw what it does and how it behaves, and I stayed on questions until the developers ran out of them. A spec nobody has been walked through doesn't get implemented; it gets interpreted.
- Engineering's technical plan
- The developers produced their implementation plan directly from the PRD. That's the real test of whether a spec is actionable: no second round of discovery, no reverse-engineering intent from mockups. The plan came out of the document.
- Daily delivery
- I run the daily standups and keep the build tracking against the plan. Decisions that would once have come back to a designer weeks later now get answered the morning they come up.
- Clearing the path
- Aligning with the other feature teams so nobody else's work blocks ours. The least visible part of the job and one of the most valuable: dependencies between squads surface as delays long after they could have been cheap to avoid.
- Next: QA
- A QA environment is being set up so the team can use the thing rather than read about it. That's also the first honest opportunity to test the question internal review couldn't answer: whether someone can pick this up without already knowing how it's meant to work.
Where it stands. The schedule is in active build, not shipped. I've deliberately not claimed outcomes it hasn't earned yet; the metrics in the previous section are the ones I'll be held to when it reaches shops, and this page will be worth updating when there are real numbers to put against them.