This case study details the design and build of Motorway Dispatch, also called Transport Management System (TMS) at times during its development, and in some of the images I've included.
It also touches on Motorway Collect, an iOS/Android Vehicle Inspection App. As well as Agent Dashboard, Motorway's internal tooling app. Motorway Pro, our dealer side of the market place; and Seller App, for consumer side of the marketplace.
Motorway's transport operation — branded Motorway Move — connected dealers who had won a car on the platform with a network of transport providers who would collect, inspect and deliver the vehicle.
In 2023, the entire process of creating a job, passing that to providers, them planning it and getting updates was manual:
Motorway had a work distribution and service transparency problem. The whole service was quite opaque and we wanted to get to as close as we could to a real-time transparent service for our customer, business partners and staff.
Job allocation wasn't straightforward. Decisions about which provider to use were shaped by contracts, driver network capacity, and geographic coverage. Some providers couldn't service Scotland; others couldn't send ten drivers to a single location in a day without stranding them, making jobs unfeasible.
Trying to plan movements for all their clients, in short time, with changing conditions and a high turnover driver workforce. They're basically trying to solve the travelling salesman problem — how to route hundreds of drivers efficiently across hundreds of jobs, across the UK and get everyone home each day, whilst not spending too much time or money on public transport between and delivery and the next collection point.
The ambition for the project was to move beyond simple job dispatch and become genuine planning software — enabling providers to manage their driver workforces, plan routes, and track jobs through to completion, all within a single product.
Lead Service Designer, working alongside an engineering lead and four devs. I led discovery and shaped the initial product direction from the ground up. Later I went on to Product Manage the team for 10 months, alongside my design role.
Using my Service Design blueprints a base (see casestudy), we did more research with our Brighton-based Transport Agents, to flesh out more of the specifics related to this new workflow.
There were several calls and visits with our transport provider network. I sat with their planning teams observing the work, the tools they used and problems they faced day-in day-out.
The driver workforce at each provider was made up entirely of essentially gig-economy contractors, with frequent driver turnover. Planners frequently had to reschedule drivers mid-shift — due to someone quitting, traffic, weather, or public transport strikes. It was a genuinely complex operational environment, and that complexity shaped everything we designed.
Throughout discovery, I tested several prototypes. Starting with sketches and workshops, and progressing to a higher-fidelity interaction prototype with a deliberately low-fidelity visual style.
I used Axure for this — it offered a more realistic prototyping experience than Figma for complex workflows, and allowed me to import real job data from CSV exports and embed live Google Maps iFrames to support planning scenarios.
A key finding from this stage was that planners needed far less information for each job than we’d anticipated, but that they wanted more jobs on the screen at any one time.
Delivery and collection postcodes were sufficient for most planners (full address details weren’t necessary). Automating communication between providers and the Brighton team also emerged as a top priority, given the considerable volume of manual updates the current process required.
Automation of a job through its lifecycle; and having clear, preferably automated, historical notes on the job were also well received in testing.
Alongside day-to-day workflow prototyping, we used this phase to test some longer-term product ambitions: AI-assisted job planning, interactive side-by-side planning views, and the less glamorous but essential parts of any system — user and driver workforce management, permissions, and configuration.
UI elements like a calendar/schedule view with drag and drop to move jobs between drivers was also a feature planners were vocal about. Though when it came to making a call on to try include this early on, we decided against it due to the complexity and that we needed other features to support such an interface.
These explorations were valuable in shaping a clear product direction, even where they sat beyond the immediate build scope.
User testing had clearly indicated Dispatch needed information-dense screens, that our users were accustomed to and needed to work effectively. I made the decision not to use Motorway's existing design system as a result.
The MVP was structured around five stages that mirrored the planning lifecycle: Allocation, where Motorway Agents selected which jobs to send to which provider, followed by Planning, Collection, Delivery, and Completed — all used by the Planner and Customer Support teams at Providers. Movement between stages was manual at this point, with jobs needing to meet specific criteria before progressing. A deliberate choice that kept planners in control while we learned how the system would be used in practice.
Each stage used the same two-pane layout: a table on the left, and a job panel on the right. For the table we used the MUI DataGrid component, which handled filtering, sorting, and advanced search out of the box, and mapped closely to tooling planners already used.The columns shown shifted slightly between stages to reflect what mattered at that point in the lifecycle — for example, collection data appeared during Planning and Collection but was hidden in later stages where it was no longer relevant.
Selecting a job surfaced its details in the panel on the right, giving planners everything they needed to take the job and assign a driver. This included vehicle details, collection and delivery status, contact information, preferred collection dates, a history log, and a notes tab for context that didn't fit the structured data. Status changes could be made from either the panel or the table.
We integrated Google Maps to plot each job's collection-to-delivery route directly in the panel. It was interactive from day one — partly to give planners a faster way to sanity-check distance and geography, and partly to set the foundation for the more ambitious planning capabilities we wanted to build into later iterations.
A parallel requirement was for Dispatch to support Motorway's brand new Collect app — an iOS and Android app used by drivers to photograph and inspect vehicles at collection and delivery points, generating a condition report for the purchasing dealer.
The Collect app team hadn't yet worked out how to get job details into the app, so we addressed this by making Dispatch the parent system. Dispatch owned the login and authentication for Collect. The task of adding a driver to a job in Dispatch, allowed the driver to view the vehicle details in the Collect App.
We tested a basic job pairing algorithm — a mechanism to suggest two jobs that might suit a single driver, simplifying the allocation process. Which made sense to our Agent allocating jobs, and they used and liked it.
However, the implementation had a significant gap. No planner ever assigned a single driver to our 'job pairs'. This was a problem we knew about from research, but we tested it anyway as a technical proof of concept.
The pairing couldn't account for the driver's home address when pairing jobs. Since most drivers complete around 1.6 - 2 deliveries per day and almost always take a car home overnight before delivering it the next morning. Proximity to home is a critical factor. Capturing driver home location and feeding it into the planning algorithm was something we planned to address in a future iteration of our algorithmic planning workstream.
We parked this feature, and used the technical learnings for later AI related work.
Now that we were getting better and more up to date information. We built a delivery details page on our Dealer product. This showed a dealer key information on their collection inspection and delivery timelines.
I supported a seller product team with showing a similar feature on the seller product.
The majority of vehicles going through Motorway Move were being booked by dealers with multiple delivery locations. The Motorway Pro platform had only been set up to handle a single address per business, which created a significant bottleneck: if a dealer needed to book 20 cars across multiple sites, there was an extensive back-and-forth over Google Sheets between the dealership and the Brighton team to confirm which car was going where — before an agent manually updated all the relevant systems, recalculated the job cost, and sent it on.
Fixing the booking process to allow for a multisite selection required significant effort across multiple systems. The outcome was a fully self-serve booking process for dealers, removing a significant manual process between them and our Brighton team.
We resolved this by building an additional address directory into the Pro platform, enabling dealers to self-serve directly after winning a car. The ideal solution would have been to fix how account management worked within Motorway’s core systems, but that was out of scope. Even so, the fix significantly reduced manual effort, delivered an estimated saving of one FTE, and led to a substantial reduction in manually created jobs.
One of the most impactful pieces of post-launch work was deepening the integration between the Collect app and Dispatch. When a driver started and completed inspections at both collection and delivery points, we used these events to trigger status changes in Dispatch — removing the need for manual updates entirely.
These automated updates were also pushed through to the Customer facing products and Motorway's Agent dashboard. Improving transparency and getting us closer to being a real time updated service. This significantly reduced manual chasing for updates.
We had an AI/ML Engineer join our team and I worked with him to test out some of our assumptions on automating parts of the planning process.
<I will point towards its own case study - as of May 2026 this is still in draft :) >
*Password protected* Testing an AI decision support system for transport planners and finding we were the wrong company to solve the problem.
In mid 2025, the business made the decision to put both Dispatch and Collect apps into maintence mode. I still support on any transport product related issues that come up. For the most part the apps are stable and require minimal engineering effort.
In 2026 Motorway partnered with large Lease company to sell their old stock, this has required changes to Dispatch and Collect App.
My role here has been to advise on and design for post sale changes needed in Agent Dashboard, Dispatch and the Collect iOS and Android apps. I've also supported the Transport Ops team and our Transport Provider partners in new workflows to support these unique stock movements.
Most of the changes in Dispatch is BE and workflow changes with some minor FE tweaks which i've used to address some longer term pain points for our Brighton team.
For the Collect app, its mostly been around accomodating far more complex damage categorisation, as well as using this oppotunity to implement new inspection modules that our customers have been asking for. We're taking this opportunity to make inspections more comprehensive for our customers.
