AMH · Property maintenance operations · 3 months · 2023
Enterprise scheduling tool
Reframed scheduling from calendar placement into operational decision support, helping maintenance dispatchers evaluate route impact, technician capacity, work-order priority, service constraints, and assignment risk before committing work to the field.
- Role
- Senior UX Designer — workflow definition, research synthesis, interaction model, wireframes, user flows, evaluative testing synthesis
- Users
- Maintenance dispatchers and schedulers assigning work orders to field technicians
- Scale
- 1,300 technicians · 55,000 properties · multi-market operation
- Outcome
- Route-aware dispatch workspace with clearer assignment context before commitment
01 The problem
This was not simply a scheduling UI problem. It was a workflow and decision-making problem.
Maintenance dispatchers were not just placing work into empty time slots. They were deciding whether a specific technician should take a specific work order at a specific time, often with incomplete visibility into the information that made that decision safe.
A technician could appear available on a schedule but still be the wrong fit because of route impact, non-work-order commitments, service windows, work-order priority, or technician qualification.
How do we help dispatchers decide whether an assignment is realistic, efficient, and safe to commit?
View the operational risk behind the problemExpandCollapse
- Dispatchers had to combine system data, manual scanning, and local market knowledge before committing assignments.
- Poor scheduling could create inefficient routes, overloaded technicians, missed service windows, resident frustration, and manual rework.
- Local geographic knowledge lived in a few veteran heads, creating key-person risk for a multi-market operation.
- The product needed to make more of the decision logic visible and repeatable before work was sent to the field.
02 Can this technician take this job?
The key user action was scheduling a work order, but the real decision was more complex: Should this technician take this work order at this time?
Before acting, dispatchers needed to understand whether the technician was available and aligned to the resident’s preferred service window, and qualified, within a certain distance to the residents property.
Find work
Which work order needs attention?
Select technician
Who could take this?
Check capacity
Does the technician have real room?
Check route
Does this fit geographically?
Check service constraints
Can the resident’s preferred time be met?
Commit or adjust
Is this safe to send to the field?
View decision risksExpandCollapse
- Availability versus capacity: an empty slot did not mean the technician could realistically take the work.
- Qualification mismatch: a technician could appear viable but be unqualified for the selected work order.
- Service-window risk: preferred service time was critical but not always visible at selection.
- Travel burden: the route could make a technically available slot unrealistic.
- Operational reversibility: drag-and-drop speed needed undo, review, and adjustment paths to stay safe.
03 My role
As the Senior UX Designer, I owned the workflow definition, research synthesis, interaction model, wireframes, user flows, and evaluative testing synthesis.
My role was to make the operational complexity visible enough for the team to understand what the product needed to support.
I worked through how dispatchers understood availability, how map and timeline context should work together, which work-order details needed to appear at the moment of decision, how to reduce map noise, and how to account for engineering constraints around route rendering.
04 Four iterations: from map controls to a dual-view workspace
I worked the concept through four rounds of hand sketches before committing to higher fidelity. Each round resolved a different layer of the problem — first which layers the map should carry and let you toggle, then a second view and capacity, then the core interactions, and finally the structure that shipped.
The first round put everything on the map at once: technicians, work orders and routes. That exposed the problem straight away — drawn together, the layers became noise. The first real decision wasn't a layout but a control. Each layer became something the scheduler could show or hide.
05 From placement to confidence
The research showed that scheduling failures were often visibility failures.
The issue was not that dispatchers lacked expertise. It was that the interface did not make the right signals visible at the right moment.
| Finding | Implication | Design action |
|---|---|---|
| Availability was not the same as capacity. | A technician could look free but still be a poor fit. | Show technician capacity and non-work-order time on the timeline. |
| The work was location-based, but scheduling was time-led. | A timeline alone could not support the real decision. | Pair map context with technician timeline context. |
| Priority work could be buried in flat queues. | Dispatchers needed a way to surface urgent or ageing work. | Add filters for priority, age, type, and status. |
| Map context became noisy at scale. | Showing everything at once reduced clarity. | Use layer control and selected-technician route focus. |
| Key service details were not visible at selection. | Dispatchers had to look elsewhere before deciding. | Bring service time and contact details onto the work-order card. |
| Risky assignments could be committed too quickly. | The workflow needed a review moment. | Add staged commitment with travel, start, duration, and finish before confirmation. |
06 The dispatch decision workspace
The final design direction was a dispatch decision workspace.
It brought map context, technician timeline, work-order priority, filters, work-order detail, and staged commitment into one workflow.
- Understand where work is happening. The map helped dispatchers judge proximity and route fit.
- Evaluate technician capacity. The timeline showed scheduled work and non-work-order commitments.
- Prioritise the right work. Filters surfaced work by priority, age, type, status, and qualification fit.
- Review work-order detail. The work-order card brought preferred service time and contact details into the decision moment.
- Commit with confidence. The staged commit flow showed travel, start, duration, and finish before confirmation.
The Technicians tab answers who can do the work. The roster shows each technician’s current load and last activity, while their position on the map gives proximity and route context before anyone is assigned.
Selected user flows
Beyond the primary scheduling walkthrough, three more flows carry the product logic.
Adjust a work order’s time ExpandCollapse
Moving a job on the timeline exposes its route consequences across the rest of the day.
The starting schedule — four jobs on the timeline with the route drawn on the map.
Undo schedule changes ExpandCollapse
Drag-and-drop speed is only safe when every change is reversible.
Work orders dragged onto Mike Thomson’s timeline; the route redraws as the day fills.
Create a custom schedule block with location ExpandCollapse
Non-work-order time placed on the map and timeline, keeping the day operationally real.
The dispatcher starts with selected work orders already staged against the technician’s map and timeline, then adds a custom schedule block from the selected panel.
07 What the scheduler broke
We tested the working build with an experienced scheduler in a moderated recorded session ahead of release.
The goal was to understand whether the workflow supported real scheduling decisions, not just whether the screens were understandable.
| Testing observation | What it revealed | Design response |
|---|---|---|
| Scheduler selected work the technician was not qualified for. | Availability was misleading without qualification. | Scope unscheduled work to selected technician’s qualifications. |
| Scheduler looked elsewhere for preferred service time. | Key service information was not visible at selection. | Move service time and contact details onto the card. |
| Travel time was not visible enough. | The schedule could hide travel burden. | Show travel, start, duration, and finish before commit. |
| Return visit could not be created. | Recovery path was missing. | Carry forward as the first improvement. |
| Scheduler wanted other technicians hidden after selection. | Focus mattered more than maximum visibility. | Preserve selected-technician route focus. |
Artefact — research synthesis board
Observations clustered into capacity visibility, route context, work-order priority, timeline clarity, and scheduling confirmation. Detail intentionally obscured to protect client research.
View testing synthesis detailExpandCollapse
- Tested: a working build ahead of release.
- Participant: an experienced scheduler in a moderated recorded session.
- Confirmed: map and timeline needed to work together, availability needed to become capacity, route context mattered at commitment, and selected-technician focus reduced noise.
- Challenged: side-panel detail was not enough, empty slots were not enough, and the module did not cover every operational recovery path.
- Unresolved: return-visit creation, live status, automated notifications, and broader recovery flows remained future improvements.
08 Outcome, and what I'd carry forward
The work shifted the product from a calendar-first scheduler into a route-aware dispatch workspace.
Assignment decisions became clearer because dispatchers could see capacity, location, route impact, priority, and service constraints before work was committed.
The workflow shifted from calendar-first scheduling to route-aware dispatch decision support.
Dispatchers had clearer capacity, route, priority, and service context before assigning work.
The workflow reduced ambiguity before high-consequence assignments and created a repeatable scheduling model across markets.
About the reported 51% service-complete metricExpandCollapse
A later operational readout reported a 51% reduction in time to service complete. I would not use this as a headline metric without confirming the reporting source, date, timeframe, baseline, rollout scope, definition of “service complete,” attribution context, and whether other operational changes contributed.
For now, this should be presented as a reported operational readout, not a direct design-impact claim.
What I would measure nextExpandCollapse
- Median time to schedule and creation-to-assignment time
- Reschedule, reassignment, missed-appointment, and double-booking rates
- Average travel time, mileage, route density, and technician utilisation
- Backlog age, priority counts, jobs per technician per day, and schedule gaps
- Filter usage, drag-and-drop completion, confirmation abandonment, map load time, and route rendering performance
What I would improve nextExpandCollapse
- Return-visit creation and recovery flows for rescheduling, cancellation, reassignment, and missed-appointment follow-up
- Service-window warnings, live status instead of manual refresh, and automated resident notification
- Better map legibility at scale, clearer technician clustering, and clearer work-order markers
- Keyboard-accessible scheduling actions and non-colour-only priority indicators
- Rule-based or AI-assisted recommendations that support dispatcher judgement without removing control
- Stronger production measurement around scheduling speed, route efficiency, utilisation, backlog health, and usability