Product Designer
AutoYard is a fleet and yard operations platform designed to centralize vehicle tracking, scheduling, and logistics coordination. I led UX strategy and interface design to create clear operational workflows and dashboards that support multiple user roles in a high-activity environment.
YEAR
2025
SERVICES
End-to-end ownership across:
Dispatcher/Admin web dashboard
Driver mobile application
Supporting landing pages
Store graphics
ROLE
Led UX strategy and interface design for key AutoYard modules, including fleet tracking, scheduling dashboards, and operations workflows, ensuring clarity and consistency across complex user tasks.
This case study covers the design of a 0→1 B2B operations platform built for towing companies to manage dispatching, driver coordination, and job tracking.
Before this product existed, towing companies relied on paper registers, phone calls, and manual follow-ups to assign jobs and track drivers. The lack of real-time visibility led to missed pickups, delayed responses, and operational stress for dispatchers.
The goal of Autoyard was to replace those fragmented workflows with a single, reliable system that towing companies could trust for daily operations.
AutoYard’s design features centralized dashboards, real-time schedule views, and intuitive workflows that guide users through complex operational tasks. Interfaces reduce cognitive load with clear patterns, consistent layout, and predictable feedback, supporting scalable operations.
The standardized interface patterns and workflow logic improved clarity and usability across roles, enabling teams to navigate operational complexity with greater consistency and confidence.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The biggest operational issue before the product was launched was simple but critical:
Dispatchers could not reliably track which driver was where once a job was assigned.
This resulted in:
Constant phone calls to drivers for updates
Uncertainty about job progress
Delayed or missed pickups
High stress during time-sensitive operations
Job states were unclear after assignment
Records were maintained manually on paper
There was no single source of truth for job history
However, these were symptoms.
The root problem was lack of real-time visibility and control.
Towing jobs are time-sensitive and often urgent.
If a driver failed to reach a pickup location on time:
• The car owner became frustrated
• The towing company lost money
• Trust in the company was damaged
Even small coordination failures had direct financial and reputational impact.
This made reliability more important than feature richness.
The strategy was to stabilize the core operation first, before adding complexity.
Instead of trying to optimize everything at once, the focus was on:
Clear job ownership
Predictable job states
Minimal ambiguity for both dispatchers and drivers
The product was designed around one core journey:
Assign → Execute → Complete
Everything else supports this flow.
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
The mobile app was intentionally limited to essential actions only.
Reasoning
Drivers are executors, not decision-makers.
The app is used during active work, often under time pressure.
Reducing navigation and options ensured:
Faster comprehension
Fewer errors
Predictable behavior during execution
The app was designed to answer one question clearly at all times:
“What do I need to do right now?”
Decision
Advanced analytics and automation rules were intentionally excluded from the first version.
Reasoning
The immediate business need was to replace paper-based workflows with a dependable system.
Analytics would only be meaningful once:
Job data was consistent
The core lifecycle was stable
Teams trusted the system
Centralized job management
Clear job states and statuses
Real-time visibility into driver activity
Structured records instead of paper logs
Exportable reports to support operations
The dashboard replaced memory-based decision-making with visible system state.
Mobile-first
One active job at a time
Clear accept → execute → complete flow
Minimal UI distractions
Designed for predictability over flexibility
The goal was not to impress drivers, but to support execution without confusion.
After launch:
Adopted by 6+ towing companies across Australia
2,500+ towing jobs processed
Faster job handling reported by dispatchers
Reduced need for manual follow-ups
No reported onboarding drop-offs
The strongest validation came from how quickly teams adopted the system and relied on it for daily operations.
This project reinforced the importance of:
Designing for reliability before optimization
Making deliberate constraints early
Prioritizing operational clarity over feature density
If scaling further, the next focus areas would be:
Analytics once data quality is stable
Exception handling for missed or delayed pickups
Carefully introducing automation without reducing trust
Some projects are password-protected. If you’d like access or a walkthrough, feel free to contact me via email.
© 2026 Rameena Jalil
Product Designer
AutoYard is a fleet and yard operations platform designed to centralize vehicle tracking, scheduling, and logistics coordination. I led UX strategy and interface design to create clear operational workflows and dashboards that support multiple user roles in a high-activity environment.
YEAR
2025
SERVICES
End-to-end ownership across:
Dispatcher/Admin web dashboard
Driver mobile application
Supporting landing pages
Store graphics
ROLE
Led UX strategy and interface design for key AutoYard modules, including fleet tracking, scheduling dashboards, and operations workflows, ensuring clarity and consistency across complex user tasks.
This case study covers the design of a 0→1 B2B operations platform built for towing companies to manage dispatching, driver coordination, and job tracking.
Before this product existed, towing companies relied on paper registers, phone calls, and manual follow-ups to assign jobs and track drivers. The lack of real-time visibility led to missed pickups, delayed responses, and operational stress for dispatchers.
The goal of Autoyard was to replace those fragmented workflows with a single, reliable system that towing companies could trust for daily operations.
AutoYard’s design features centralized dashboards, real-time schedule views, and intuitive workflows that guide users through complex operational tasks. Interfaces reduce cognitive load with clear patterns, consistent layout, and predictable feedback, supporting scalable operations.
The standardized interface patterns and workflow logic improved clarity and usability across roles, enabling teams to navigate operational complexity with greater consistency and confidence.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The biggest operational issue before the product was launched was simple but critical:
Dispatchers could not reliably track which driver was where once a job was assigned.
This resulted in:
Constant phone calls to drivers for updates
Uncertainty about job progress
Delayed or missed pickups
High stress during time-sensitive operations
Job states were unclear after assignment
Records were maintained manually on paper
There was no single source of truth for job history
However, these were symptoms.
The root problem was lack of real-time visibility and control.
Based on the problem space, I defined four guiding principles:
Trust before speed, avoid false confirmations
Explicit system states, users should never guess
Predictability over flexibility, fewer disputes
MVP focus with scalable foundations
These principles directly shaped the booking experience.
The strategy was to stabilize the core operation first, before adding complexity.
Instead of trying to optimize everything at once, the focus was on:
Clear job ownership
Predictable job states
Minimal ambiguity for both dispatchers and drivers
The product was designed around one core journey:
Assign → Execute → Complete
Everything else supports this flow.
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
After launch:
Adopted by 6+ towing companies across Australia
2,500+ towing jobs processed
Faster job handling reported by dispatchers
Reduced need for manual follow-ups
No reported onboarding drop-offs
The strongest validation came from how quickly teams adopted the system and relied on it for daily operations.
This project reinforced the importance of:
Designing for reliability before optimization
Making deliberate constraints early
Prioritizing operational clarity over feature density
If scaling further, the next focus areas would be:
Analytics once data quality is stable
Exception handling for missed or delayed pickups
Carefully introducing automation without reducing trust
This project was successful because it transformed fragmented, manual towing operations into a clear and reliable job lifecycle that companies could trust for daily use.
hello.uxbyray@gmail.com
Some projects are password-protected. If you’d like access or a walkthrough, feel free to contact me via email.
© 2026 Rameena Jalil
Product Designer
AutoYard is a fleet and yard operations platform designed to centralize vehicle tracking, scheduling, and logistics coordination. I led UX strategy and interface design to create clear operational workflows and dashboards that support multiple user roles in a high-activity environment.
YEAR
2025
SERVICES
End-to-end ownership across:
Dispatcher/Admin web dashboard
Driver mobile application
Supporting landing pages
Store graphics
ROLE
Led UX strategy and interface design for key AutoYard modules, including fleet tracking, scheduling dashboards, and operations workflows, ensuring clarity and consistency across complex user tasks.
This case study covers the design of a 0→1 B2B operations platform built for towing companies to manage dispatching, driver coordination, and job tracking.
Before this product existed, towing companies relied on paper registers, phone calls, and manual follow-ups to assign jobs and track drivers. The lack of real-time visibility led to missed pickups, delayed responses, and operational stress for dispatchers.
The goal of Autoyard was to replace those fragmented workflows with a single, reliable system that towing companies could trust for daily operations.
AutoYard’s design features centralized dashboards, real-time schedule views, and intuitive workflows that guide users through complex operational tasks. Interfaces reduce cognitive load with clear patterns, consistent layout, and predictable feedback, supporting scalable operations.
The standardized interface patterns and workflow logic improved clarity and usability across roles, enabling teams to navigate operational complexity with greater consistency and confidence.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The platform serves towing companies, not individual drivers or car owners.
Companies register on the platform
Each company manages its own drivers and towing vehicles
Dispatchers assign jobs internally
Drivers execute pickups and return vehicles to the company yard
The product needed to work across multiple companies, each with different team sizes, workflows, and operational pressure.
The biggest operational issue before the product was launched was simple but critical:
Dispatchers could not reliably track which driver was where once a job was assigned.
This resulted in:
Constant phone calls to drivers for updates
Uncertainty about job progress
Delayed or missed pickups
High stress during time-sensitive operations
Job states were unclear after assignment
Records were maintained manually on paper
There was no single source of truth for job history
However, these were symptoms.
The root problem was lack of real-time visibility and control.
Based on the problem space, I defined four guiding principles:
Trust before speed, avoid false confirmations
Explicit system states, users should never guess
Predictability over flexibility, fewer disputes
MVP focus with scalable foundations
These principles directly shaped the booking experience.
The strategy was to stabilize the core operation first, before adding complexity.
Instead of trying to optimize everything at once, the focus was on:
Clear job ownership
Predictable job states
Minimal ambiguity for both dispatchers and drivers
The product was designed around one core journey:
Assign → Execute → Complete
Everything else supports this flow.
Decision
Drivers can only have one active job at a time.
Reasoning
Allowing multiple active jobs would increase flexibility, but it would also introduce:
State conflicts between dispatcher and driver
Missed pickups
Unclear responsibility during execution
For an MVP replacing manual workflows, clarity and reliability mattered more than optimization.
This constraint simplified:
Dispatcher confidence
Driver responsibility
System logic
Decision
The mobile app was intentionally limited to essential actions only.
Reasoning
Drivers are executors, not decision-makers.
The app is used during active work, often under time pressure.
Reducing navigation and options ensured:
Faster comprehension
Fewer errors
Predictable behavior during execution
The app was designed to answer one question clearly at all times:
“What do I need to do right now?”
Decision
Advanced analytics and automation rules were intentionally excluded from the first version.
Reasoning
The immediate business need was to replace paper-based workflows with a dependable system.
Analytics would only be meaningful once:
Job data was consistent
The core lifecycle was stable
Teams trusted the system
Decision
Advanced analytics and automation rules were intentionally excluded from the first version.
Reasoning
The immediate business need was to replace paper-based workflows with a dependable system.
Analytics would only be meaningful once:
Job data was consistent
The core lifecycle was stable
Teams trusted the system
Decision
Advanced analytics and automation rules were intentionally excluded from the first version.
Reasoning
The immediate business need was to replace paper-based workflows with a dependable system.
Analytics would only be meaningful once:
Job data was consistent
The core lifecycle was stable
Teams trusted the system
After launch:
Adopted by 6+ towing companies across Australia
2,500+ towing jobs processed
Faster job handling reported by dispatchers
Reduced need for manual follow-ups
No reported onboarding drop-offs
The strongest validation came from how quickly teams adopted the system and relied on it for daily operations.
This project reinforced that in real marketplace products, trust is a design responsibility, not a visual layer.
Designing with restraint, choosing clarity over feature volume; proved more effective in reducing hesitation.
If extended further, usability testing and behavioral analytics would be used to validate assumptions and refine trust mechanisms.
This project was successful because it transformed fragmented, manual towing operations into a clear and reliable job lifecycle that companies could trust for daily use.
Some projects are password-protected. If you’d like access or a walkthrough, feel free to contact me via email.
© 2026 Rameena Jalil