B2B
Schedule app
A scheduling app built with dispatcher workflows in mind—centralized job views, smart assignment tools, and quick actions to handle real-world complexity with speed and clarity.
Role
Lead product designer
Industry
Field Service
Company
Method CRM
My responsibilities
From concept to release 0->1
Outcomes:
+30%
Reduction in time-to-assign jobs
+20%
Increase in technician utilization
+15%
Improvement in on-time job completion rate
Qualitative Outcome
Enabled dispatchers to handle complex scheduling with less effort through conflict detection and quick actions.
Provided a unified calendar view with filters and maps, giving full visibility into jobs and team workload.
Improved confidence and accuracy in managing urgent or multi-tech assignments.
Challenge :
Only 25% of weekly users engaged with Method’s Field Service apps. Dispatchers faced no standardized way to manage jobs that required multiple visits, creating friction points such as:
Constantly jumping between multiple screens just to manage one job.
Re-entering the same details for each visit, increasing error risk.
Losing visibility into progress when work spanned multiple days or multiple technicians.
These gaps led to fragmented workflows, low adoption of core scheduling features, and a growing dependence on costly custom solutions.
Constraints :
No-code platform limitations
Core workflows had to fit within existing no-code components.
Component Gaps
The current calendar relies on the activities table and offers only basic functionality, which is prone to bugs.Some features are impossible to customize due to our no-code limitations and so we lack table stakes in comparison to competitors like jobber
Stock Workflow Gaps
Lacks native support for multiple work orders or visits, resulting in fragmented workflows.Essential features expected out-of-the-box are missing, forcing users to pay for what should be standard.
Onboarding
Users are lost during their initial experience with Method.Increase adoption and engagement with Field Service apps without requiring custom builds.
My approach
My approach combined dispatcher personas, competitive research, and user interviews for qualitative insights, while also analyzing existing usage metrics to ground design decisions in real data.
Personas
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Qualitative data gathering
Reviewed feature requests, churn feedback, and support cases to uncover scheduling pain points.
Found consistent themes:
Gaps in visit status management at a glance
Unscheduled jobs is an unclear journey
Hard to detect conflicts early
Limited filtering options
Insight: The schedule is only accurate at the start of the day
Churn: Lacked advanced scheduling
Churn: Rescheduling a work order to another day or technician takes too many steps it's inefficient
INITIAL BUY-IN
I began by using AI to prototype a clean scheduling app concept, securing early stakeholder buy-in. Lovable AI generated the first screens, which I refined through vibe coding in Cursor to produce a medium-fidelity output.
From there, I moved into Figma and applied our design system, ensuring developers could implement it with ease.
User testing
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Visit creation
0%
0%
Satisfaction completion Rate
Unscheduled -> scheduled
0%
0%
Satisfaction completion rate
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
Final Design
Mapped the end-to-end dispatcher workflow, from handling unscheduled visits and conflicts to applying filters and configurations. This flow clarified decision points (like reassigning vs. rescheduling) and informed how the scheduling app should support dispatchers in managing complexity with clarity.
Visit creation experience
Note:Zoom in to view details.
Creation of a visit within the scheduling app
Unscheduled -> Scheduled
Note:Zoom in to view details.
Dragging and dropping unscheduled -> scheduled
Conflict
Note:Zoom in to view details.
Error prevention from our component level exists. Identifying conflicts and prompting user to resolve them.
Filtering
Note:Zoom in to view details.
Utilizing our existing chip system to create and advanced filtering for the schedule app
Success Metrics
Proof of Life: measurable adoption within dispatcher teams (≥70% of dispatchers switching to new app within 3 months).
Engagement: ≥__% of visit edits/reschedules happen inside the Scheduling App (vs legacy).
Efficiency: average clicks per reschedule ≤2.
Release Plan
Next Steps
Define AI scheduling rules and success metrics – establish what the AI should automate (assignment, conflict resolution, routing) and how success will be measured (e.g., fewer conflicts, faster scheduling).
Integrate AI into dispatcher workflows – prototype how AI suggestions (assignments, reassignments, routes) appear in context, with clear options for dispatcher review or override.
Test and validate trust – run usability sessions to evaluate accuracy, dispatcher confidence, and how often AI suggestions are accepted or overridden.
© Copyright 2025 ELAINE CHOW
B2B
Schedule app
A scheduling app built with dispatcher workflows in mind—centralized job views, smart assignment tools, and quick actions to handle real-world complexity with speed and clarity.
Role
Lead product designer
Industry
Field Service
Company
Method CRM
My responsibilities
From concept to release 0->1
Outcomes:
+30%
Reduction in time-to-assign jobs
+20%
Increase in technician utilization
+15%
Improvement in on-time job completion rate
Qualitative Outcome
Enabled dispatchers to handle complex scheduling with less effort through conflict detection and quick actions.
Provided a unified calendar view with filters and maps, giving full visibility into jobs and team workload.
Improved confidence and accuracy in managing urgent or multi-tech assignments.
Challenge :
Only 25% of weekly users engaged with Method’s Field Service apps. Dispatchers faced no standardized way to manage jobs that required multiple visits, creating friction points such as:
Constantly jumping between multiple screens just to manage one job.
Re-entering the same details for each visit, increasing error risk.
Losing visibility into progress when work spanned multiple days or multiple technicians.
These gaps led to fragmented workflows, low adoption of core scheduling features, and a growing dependence on costly custom solutions.
Constraints :
No-code platform limitations
Core workflows had to fit within existing no-code components.
Component Gaps
The current calendar relies on the activities table and offers only basic functionality, which is prone to bugs.Some features are impossible to customize due to our no-code limitations and so we lack table stakes in comparison to competitors like jobber
Stock Workflow Gaps
Lacks native support for multiple work orders or visits, resulting in fragmented workflows.Essential features expected out-of-the-box are missing, forcing users to pay for what should be standard.
Onboarding
Users are lost during their initial experience with Method.Increase adoption and engagement with Field Service apps without requiring custom builds.
My approach
My approach combined dispatcher personas, competitive research, and user interviews for qualitative insights, while also analyzing existing usage metrics to ground design decisions in real data.
Personas
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Qualitative data gathering
Reviewed feature requests, churn feedback, and support cases to uncover scheduling pain points.
Found consistent themes:
Gaps in visit status management at a glance
Unscheduled jobs is an unclear journey
Hard to detect conflicts early
Limited filtering options
Insight: The schedule is only accurate at the start of the day
Churn: Lacked advanced scheduling
Churn: Rescheduling a work order to another day or technician takes too many steps it's inefficient
INITIAL BUY-IN
I began by using AI to prototype a clean scheduling app concept, securing early stakeholder buy-in. Lovable AI generated the first screens, which I refined through vibe coding in Cursor to produce a medium-fidelity output.
From there, I moved into Figma and applied our design system, ensuring developers could implement it with ease.
User testing
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Visit creation
0%
0%
Satisfaction completion Rate
Unscheduled -> scheduled
0%
0%
Satisfaction completion rate
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
Final Design
Mapped the end-to-end dispatcher workflow, from handling unscheduled visits and conflicts to applying filters and configurations. This flow clarified decision points (like reassigning vs. rescheduling) and informed how the scheduling app should support dispatchers in managing complexity with clarity.
Visit creation experience
Note:Zoom in to view details.
Creation of a visit within the scheduling app
Unscheduled -> Scheduled
Note:Zoom in to view details.
Dragging and dropping unscheduled -> scheduled
Conflict
Note:Zoom in to view details.
Error prevention from our component level exists. Identifying conflicts and prompting user to resolve them.
Filtering
Note:Zoom in to view details.
Utilizing our existing chip system to create and advanced filtering for the schedule app
Success Metrics
Proof of Life: measurable adoption within dispatcher teams (≥70% of dispatchers switching to new app within 3 months).
Engagement: ≥__% of visit edits/reschedules happen inside the Scheduling App (vs legacy).
Efficiency: average clicks per reschedule ≤2.
Release Plan
Next Steps
Define AI scheduling rules and success metrics – establish what the AI should automate (assignment, conflict resolution, routing) and how success will be measured (e.g., fewer conflicts, faster scheduling).
Integrate AI into dispatcher workflows – prototype how AI suggestions (assignments, reassignments, routes) appear in context, with clear options for dispatcher review or override.
Test and validate trust – run usability sessions to evaluate accuracy, dispatcher confidence, and how often AI suggestions are accepted or overridden.
© Copyright 2025 ELAINE CHOW
B2B
Schedule app
A scheduling app built with dispatcher workflows in mind—centralized job views, smart assignment tools, and quick actions to handle real-world complexity with speed and clarity.
Role
Lead product designer
Industry
Field Service
Company
Method CRM
My responsibilities
From concept to release 0->1
Outcomes:
+30%
Reduction in time-to-assign jobs
+20%
Increase in technician utilization
+15%
Improvement in on-time job completion rate
Qualitative Outcome
Enabled dispatchers to handle complex scheduling with less effort through conflict detection and quick actions.
Provided a unified calendar view with filters and maps, giving full visibility into jobs and team workload.
Improved confidence and accuracy in managing urgent or multi-tech assignments.
Challenge :
Only 25% of weekly users engaged with Method’s Field Service apps. Dispatchers faced no standardized way to manage jobs that required multiple visits, creating friction points such as:
Constantly jumping between multiple screens just to manage one job.
Re-entering the same details for each visit, increasing error risk.
Losing visibility into progress when work spanned multiple days or multiple technicians.
These gaps led to fragmented workflows, low adoption of core scheduling features, and a growing dependence on costly custom solutions.
Constraints :
No-code platform limitations
Core workflows had to fit within existing no-code components.
Component Gaps
The current calendar relies on the activities table and offers only basic functionality, which is prone to bugs.Some features are impossible to customize due to our no-code limitations and so we lack table stakes in comparison to competitors like jobber
Stock Workflow Gaps
Lacks native support for multiple work orders or visits, resulting in fragmented workflows.Essential features expected out-of-the-box are missing, forcing users to pay for what should be standard.
Onboarding
Users are lost during their initial experience with Method.Increase adoption and engagement with Field Service apps without requiring custom builds.
My approach
My approach combined dispatcher personas, competitive research, and user interviews for qualitative insights, while also analyzing existing usage metrics to ground design decisions in real data.
Personas
Primary Persona
Dispatcher Diane – Responsible for creating and updating job records. Needs speed, visibility, and minimal screen switching.
Field Crew Frank – Receives and executes job details provided by the dispatcher. Relies on accurate, up-to-date information to avoid delays and rework
Secondary Persona
Customer Chris – Interacts with the business and expects timely, professional service.
Qualitative data gathering
Reviewed feature requests, churn feedback, and support cases to uncover scheduling pain points.
Found consistent themes:
Gaps in visit status management at a glance
Unscheduled jobs is an unclear journey
Hard to detect conflicts early
Limited filtering options
Insight: The schedule is only accurate at the start of the day
Churn: Lacked advanced scheduling
Churn: Rescheduling a work order to another day or technician takes too many steps it's inefficient
INITIAL BUY-IN
I began by using AI to prototype a clean scheduling app concept, securing early stakeholder buy-in. Lovable AI generated the first screens, which I refined through vibe coding in Cursor to produce a medium-fidelity output.
From there, I moved into Figma and applied our design system, ensuring developers could implement it with ease.
User testing
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
how do I know that they’re the right person for this job… maybe it’s just the skills and maybe it’s just in text?
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Hard to understand the differences between the conflict types and what my next steps are
Visit creation
0%
0%
Satisfaction completion Rate
Unscheduled -> scheduled
0%
0%
Satisfaction completion rate
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
need for a map view to visualize scheduled and unscheduled calls, enabling better clustering and scheduling decisions
John sandy
Owner
Final Design
Mapped the end-to-end dispatcher workflow, from handling unscheduled visits and conflicts to applying filters and configurations. This flow clarified decision points (like reassigning vs. rescheduling) and informed how the scheduling app should support dispatchers in managing complexity with clarity.
Visit creation experience
Note:Zoom in to view details.
Creation of a visit within the scheduling app
Unscheduled -> Scheduled
Note:Zoom in to view details.
Dragging and dropping unscheduled -> scheduled
Conflict
Note:Zoom in to view details.
Error prevention from our component level exists. Identifying conflicts and prompting user to resolve them.
Filtering
Note:Zoom in to view details.
Utilizing our existing chip system to create and advanced filtering for the schedule app
Success Metrics
Proof of Life: measurable adoption within dispatcher teams (≥70% of dispatchers switching to new app within 3 months).
Engagement: ≥__% of visit edits/reschedules happen inside the Scheduling App (vs legacy).
Efficiency: average clicks per reschedule ≤2.
Release Plan
Next Steps
Define AI scheduling rules and success metrics – establish what the AI should automate (assignment, conflict resolution, routing) and how success will be measured (e.g., fewer conflicts, faster scheduling).
Integrate AI into dispatcher workflows – prototype how AI suggestions (assignments, reassignments, routes) appear in context, with clear options for dispatcher review or override.
Test and validate trust – run usability sessions to evaluate accuracy, dispatcher confidence, and how often AI suggestions are accepted or overridden.
© Copyright 2025 ELAINE CHOW