PRODUCT DESIGN · 2022
Field Service Management
Field Service Management
Field Service Management
What is this about
What is this about
Simplifying complex field operations through a scalable scheduling experience.
Simplifying complex field operations through a scalable scheduling experience.
Services
Product Design
Product Design
Employer
Fingent Global
Fingent Global
Platform
Web
Web
Type
B2B SaaS
B2B SaaS
This case study is based on design challenges I worked on professionally. Due to a confidentiality agreement, the client's branding, and UI have been redesigned, and certain details have been modified while preserving the design thinking and process.
This case study is based on design challenges I worked on professionally. Due to a confidentiality agreement, the client's branding, and UI have been redesigned, and certain details have been modified while preserving the design thinking and process.
Overview
Overview
Field Service Management is an enterprise B2B SaaS platform used by organisations to manage field operations, work orders, technicians, and service activities. As the platform evolved, new business requirements continuously introduced additional features and workflows. While these additions expanded the product's capabilities, they also increased the complexity of the existing experience. I worked as a Product Designer on the continuous evolution of the platform, designing new features and improving existing workflows across the product.
Field Service Management is an enterprise B2B SaaS platform used by organisations to manage field operations, work orders, technicians, and service activities. As the platform evolved, new business requirements continuously introduced additional features and workflows. While these additions expanded the product's capabilities, they also increased the complexity of the existing experience. I worked as a Product Designer on the continuous evolution of the platform, designing new features and improving existing workflows across the product.
Work Order Scheduler: One of the key areas I worked on was the scheduler a critical tool used by operations administrators and dispatchers to plan jobs, assign technicians, and monitor field activity.
Work Order Scheduler: One of the key areas I worked on was the scheduler a critical tool used by operations administrators and dispatchers to plan jobs, assign technicians, and monitor field activity.
Design Process
The Challenge
The Challenge
The scheduler had originally been designed around a simpler workflow.As the product evolved, new capabilities, requirements, and business rules were introduced. More information had to be displayed, more actions became available, and more edge cases had to be supported.Over time, this created a familiar enterprise-product problem:
The scheduler had originally been designed around a simpler workflow.As the product evolved, new capabilities, requirements, and business rules were introduced. More information had to be displayed, more actions became available, and more edge cases had to be supported.Over time, this created a familiar enterprise-product problem:
More capability was making the core workflow harder to understand.
More capability was making the core workflow harder to understand.
Dispatchers needed to quickly answer questions such as:
Who is available?
Which technician should handle this job?
What is already scheduled?
Where are conflicts?
What needs attention?
How can a job be reassigned or rescheduled?
Dispatchers needed to quickly answer questions such as:
Who is available?
Which technician should handle this job?
What is already scheduled?
Where are conflicts?
What needs attention?
How can a job be reassigned or rescheduled?
Understanding the users
Understanding the users
The primary users of the scheduling experience were operations teams responsible for coordinating field work. Their day wasn't limited to creating schedules, they were continuously reacting to changes, moving jobs, balancing workloads, and making sure the right technician was available at the right time.
The primary users of the scheduling experience were operations teams responsible for coordinating field work. Their day wasn't limited to creating schedules, they were continuously reacting to changes, moving jobs, balancing workloads, and making sure the right technician was available at the right time.
Operations administrators
They plan schedules, assign technicians, manage work orders, and respond to changes throughout the day. Their Priority is Understand the state of operations quickly and take action with minimal friction.
They plan schedules, assign technicians, manage work orders, and respond to changes throughout the day. Their Priority is Understand the state of operations quickly and take action with minimal friction.
Field technicians
Technicians receive assigned work, understand their schedules, travel to locations, and complete jobs in the field. Their Priority is
Know what they need to do, where they need to go, and when the work needs to happen.
Technicians receive assigned work, understand their schedules, travel to locations, and complete jobs in the field. Their Priority is
Know what they need to do, where they need to go, and when the work needs to happen.
Technicians receive assigned work, understand their schedules, travel to locations, and complete jobs in the field. Their Priority is Know what they need to do, where they need to go, and when the work needs to happen.
The Workflow
The Workflow
I mapped the scheduling journey to understand where the interface was creating unnecessary friction. A typical workflow moved from reviewing incoming work, checking technician availability, selecting an appropriate time, assigning the job, and then monitoring the schedule as the day progressed. The complexity appeared when these steps weren't isolated. Users often needed to move back and forth between them, especially when a technician became unavailable or a job needed to be rescheduled. This reinforced the need for a scheduler that could support decisions and changes without constantly taking users away from the main context.
I mapped the scheduling journey to understand where the interface was creating unnecessary friction. A typical workflow moved from reviewing incoming work, checking technician availability, selecting an appropriate time, assigning the job, and then monitoring the schedule as the day progressed. The complexity appeared when these steps weren't isolated. Users often needed to move back and forth between them, especially when a technician became unavailable or a job needed to be rescheduled. This reinforced the need for a scheduler that could support decisions and changes without constantly taking users away from the main context.
Key Insights
Key Insights
These areas stood out during the exploration.
These areas stood out during the exploration.
Information hierarchy
Information hierarchy
Too many pieces of information competed for attention, making important scheduling details harder to scan.
Too many pieces of information competed for attention, making important scheduling details harder to scan.
Too many pieces of information competed for attention, making important scheduling details harder to scan.
Availability
Availability
Understanding whether a technician could take on additional work required interpreting several parts of the schedule.
Understanding whether a technician could take on additional work required interpreting several parts of the schedule.
Interaction friction
Interaction friction
common actions such as assigning and rescheduling work could require unnecessary navigation and context switching.
common actions such as assigning and rescheduling work could require unnecessary navigation and context switching.
Interaction friction
Interaction friction
common actions such as assigning and rescheduling work could require unnecessary navigation and context switching.
common actions such as assigning and rescheduling work could require unnecessary navigation and context switching.
Solutions
Solutions
I explored different approaches to organizing technicians, time, jobs, and supporting information before committing to the final direction. The early concepts focused on increasing visibility, but they quickly exposed a trade off: showing more information made some scenarios easier to understand, while simultaneously making the overall interface harder to scan. The loading problem introduced another important question:
I explored different approaches to organizing technicians, time, jobs, and supporting information before committing to the final direction. The early concepts focused on increasing visibility, but they quickly exposed a trade off: showing more information made some scenarios easier to understand, while simultaneously making the overall interface harder to scan. The loading problem introduced another important question:
did the scheduler really need to load every agent and all of their work before users could start working?
did the scheduler really need to load every agent and all of their work before users could start working?
I discussed the problem with the developers and explored a more progressive approach. Instead of loading the schedules of every agent upfront, the scheduler would initially load 15 agents who were currently active and on duty. Users could then load additional agents when they needed to see more of the workforce. This reduced the amount of data required during the initial load while keeping the most relevant information immediately available. It also created a more scalable approach as the number of agents and work orders increased.
I discussed the problem with the developers and explored a more progressive approach. Instead of loading the schedules of every agent upfront, the scheduler would initially load 15 agents who were currently active and on duty. Users could then load additional agents when they needed to see more of the workforce. This reduced the amount of data required during the initial load while keeping the most relevant information immediately available. It also created a more scalable approach as the number of agents and work orders increased.
Technical Foundation
Technical Foundation
The scheduling experience also depended heavily on the underlying scheduler component. We evaluated different Angular scheduler plugins to understand which could support the interactions and visual structure we were aiming for.
Rather than choosing a plugin based only on its default appearance, I worked with developers to compare how customizable each option was, how well it could support our scheduling interactions, and how much effort would be required to adapt it to the existing product. This discussion helped shape the final layout as well. Some design directions were explored and adjusted based on what the chosen scheduler could realistically support, creating a balance between design flexibility and implementation feasibility.
The scheduling experience also depended heavily on the underlying scheduler component. We evaluated different Angular scheduler plugins to understand which could support the interactions and visual structure we were aiming for.
Rather than choosing a plugin based only on its default appearance, I worked with developers to compare how customizable each option was, how well it could support our scheduling interactions, and how much effort would be required to adapt it to the existing product. This discussion helped shape the final layout as well. Some design directions were explored and adjusted based on what the chosen scheduler could realistically support, creating a balance between design flexibility and implementation feasibility.
Visual Design
Visual Design
After exploring different layouts and validating the wireframes, I worked closely with developers to select an Angular scheduler plugin that offered the flexibility needed for the required layouts and interactions. Once the technical direction was confirmed, I moved into visual design, following the existing brand system to keep the scheduler consistent with the rest of the product. The experience was structured around technician schedules, with jobs placed directly within the timeline so users could quickly understand workloads, availability, and conflicts, while keeping actions like assigning and rescheduling within contex
After exploring different layouts and validating the wireframes, I worked closely with developers to select an Angular scheduler plugin that offered the flexibility needed for the required layouts and interactions. Once the technical direction was confirmed, I moved into visual design, following the existing brand system to keep the scheduler consistent with the rest of the product. The experience was structured around technician schedules, with jobs placed directly within the timeline so users could quickly understand workloads, availability, and conflicts, while keeping actions like assigning and rescheduling within contex
Unscheduled jobs were kept in a dedicated section, allowing dispatchers to simply drag and drop a job onto the appropriate technician and time slot, making assignment faster and more intuitive.
Unscheduled jobs were kept in a dedicated section, allowing dispatchers to simply drag and drop a job onto the appropriate technician and time slot, making assignment faster and more intuitive.
From Design to Delivery
From Design to Delivery
Once the designs were ready for implementation, I stayed involved throughout development rather than treating the handoff as the end of the design process. I worked closely with developers to clarify interactions, discuss edge cases, and ensure behaviours such as drag-and-drop assignment, loading additional agents, scheduling changes, and different job states matched the intended experience. I also collaborated with QA during testing to review the implementation against the designs and expected workflows, identifying issues, refining solutions, and communicating changes back to the development team to maintain the intended interaction, visual consistency, and usability.
Once the designs were ready for implementation, I stayed involved throughout development rather than treating the handoff as the end of the design process. I worked closely with developers to clarify interactions, discuss edge cases, and ensure behaviours such as drag-and-drop assignment, loading additional agents, scheduling changes, and different job states matched the intended experience. I also collaborated with QA during testing to review the implementation against the designs and expected workflows, identifying issues, refining solutions, and communicating changes back to the development team to maintain the intended interaction, visual consistency, and usability.
Outcome
Outcome
The redesigned scheduler made workloads easier to scan and introduced a dedicated space for unscheduled jobs, allowing dispatchers to quickly assign work through drag-and-drop. By initially loading only 15 active agents, the experience also reduced initial load times while keeping the wider workforce accessible when needed. This created a faster, clearer scheduling workflow without sacrificing access to the full workforce.
The redesigned scheduler made workloads easier to scan and introduced a dedicated space for unscheduled jobs, allowing dispatchers to quickly assign work through drag-and-drop. By initially loading only 15 active agents, the experience also reduced initial load times while keeping the wider workforce accessible when needed. This created a faster, clearer scheduling workflow without sacrificing access to the full workforce.
Key outcomes included:
Faster scheduler load times by initially loading only active agents
Clearer communication and scheduling workflows across operations teams
Improved scheduler usability through drag-and-drop job assignment
Stronger customer adoption, with an enterprise customer retaining the product and adopting our scheduler instead of relying on a third-party scheduling plugin
Faster scheduler load times by initially loading only active agents
Clearer communication and scheduling workflows across operations teams
Improved scheduler usability through drag-and-drop job assignment
Stronger customer adoption, with an enterprise customer retaining the product and adopting our scheduler instead of relying on a third-party scheduling plugin
Reflections
Reflections
Working on an enterprise product taught me that complexity is part of the process as a product grows. This project helped me look beyond individual screens and consider the wider product experience, from information hierarchy and interactions to performance, technical constraints, and implementation.
Working on an enterprise product taught me that complexity is part of the process as a product grows. This project helped me look beyond individual screens and consider the wider product experience, from information hierarchy and interactions to performance, technical constraints, and implementation.
The project reinforced one of my core design beliefs:
The project reinforced one of my core design beliefs:
Performance is part of UX
Performance is part of UX