Assigning a Team, Not Just a Person
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Role
Lead Product Designer
Industry
Field Service
Company
Method CRM
↓ 20 hrs
Custom dev cost per customer to simulate what should have been standard
→ 30–40%
Target adoption within 4–6 months of launch
✓ 2
New platform capabilities built that had never existed in Method
User needs
Dispatchers couldn't represent work that wasn't yet staffed.
Method required certainty before a job could exist. One technician. One date. No flexibility. Real field service doesn't work that way.
A pool installation needs an estimator and two technicians. An HVAC job needs a senior tech and an apprentice. A time-sensitive repair needs whoever is available — often more than one person.
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
"I need the ability to assign a Work Order to multiple technicians."
"Inability to assign multiple technicians to a work order."
"Struggled with scheduling and assigning multiple technicians to a work order, as well as reassigning work orders easily."
Three data sources. One problem.
Today
This is how dispatchers were managing it.
Problem 1: You couldn't assign more than one person.
Problem 2: You couldn't save a job with no one assigned.
Workarounds: Multiple assignees
Creating duplicate work orders — one per technician
Building sub-work orders (child WOs) to represent each additional technician
Paying for custom development — up to 20 hours per customer — to simulate multi-select
Workarounds: Unassigned work
Assigning a placeholder or dummy technician just to save the record
Tracking unstaffed work outside the platform in spreadsheets or notes
Workarounds: Platform
Customizers building sub-work orders or duplicate fields to simulate multi-select anywhere in the system
Partners charging customers for what should have been standard out-of-the-box functionality
Constraints
What's right and what's buildable.
Existing "AssignedTo"
+
Legacy code
+
SyncFusion Calendar
+
No - code platform
Legacy no-code platform.
No native multi-select existed anywhere. Every interaction pattern had to work within existing component infrastructure or require a deliberate platform investment — which I had to make the case for explicitly.
Existing "AssignedTo" Component
Converting it would have required dropping database constraints and rewriting every query that touched it. The parallel approach kept existing workflows intact while the new model was proven.
Strategic release
shipping as Early Release to control scope before expanding it. Grid support, calendar filters, and custom multi-select fields on other tables were deliberately locked until the core was proven stable.
Turning point
Designing the feature revealed a gap nobody had anticipated.
Once the assignment interaction was defined, a new problem surfaced. Each technician needed their own notification — not one email to a group, but one action run per person.
The platform had no way to do that.
There was no Loop Through List in Method. It had never existed. Without it, multi-assignee was a visual change with no operational backbone. A dispatcher could assign a team — but the system couldn't act on each member individually.
I made the call to build it as a platform primitive rather than a one-off workaround. My dev built it from scratch — a brand new action type hardcoded into the no-code editor. Every future multi-value workflow in Method can now use it too.
Loop Through List — a platform action that didn't exist until this design required it
Actions nest inside the loop — each one runs once per technician,
Design
I pushed the platform forward. Then designed on top of it.
Assigning a team. I designed the assignment interaction to scale from one person to a crew without increasing cognitive load — each selection visible, removable, and immediately readable. On save, Loop Through List runs once per person. Each technician gets their own notification.
Unassigning entirely. I defined Unassigned as a first-class designed state rather than an empty field — visually distinct, immediately readable without a label, Notify Team hidden. A dispatcher can see at a glance that a job has no one attached without opening the record.
How I created this Interactive prototype:
Initial designs created in Figma, Vibe coded with Cursor, Connected to Lovable ai using GitHub & shared with customers & partners
Multi-select in action — Made using Loveable to send to customers and partners for user testing
Completion wasn't the signal. Behavior was.
"I have to keep reopening it every time I pick someone — can't it just stay open?"
→ one continuous interaction
"Can I just type their name? I know who I'm looking for."
→ type-ahead search
Multi-assignee
0%
0%
Satisfaction completion Rate
Number of attempts
0%
0%
Completed on the first try
"Why is it just blank? I'd expect it to say Unassigned so I know it's intentional."
→ The right instinct — an empty field reads as broken, not deliberate. I made the call that setting Unassigned as a true default required broader system changes not in scope for this release. Documented and queued for next iteration.
The hard calls
Decisions that defined what shipped.
Every feature has a version that exists in your head and a version that ships. I chose to be honest about the gap. Early Release framing meant listing limitations in the help centre — not burying them. Dispatchers and partners knew what was stable, what was coming, and that nothing was an oversight.
Sync fusion calendar — to display all users within the modal
The calendar wasn't built for teams.
Filtering by one technician would miss every job where that person was part of a crew
The challenge wasn't visual — it was behavioral
Dispatchers think in people, not crews
I designed the calendar to show the team on the job while keeping the individual findable
Validated the approach against the third-party component before committing
Designed overflow so the card never breaks regardless of crew size
Multiple assignee - Team -> AssignedTo
I deferred the "Team" label.
Originally named "Team" — anticipating a future Team Management feature
Infrastructure wasn't ready to support the concept behind the label
Shipping it would have told dispatchers the product understood teams — when it didn't yet
Pulled it back — the rename ships when Team Management ships
The outcome
The workaround is gone. The workflow remains.
The duplicate work order workaround — one record per technician, 20 hours of custom dev per customer — is replaced by a single work order that represents the team. Work that couldn't be logged without a name can now be created immediately and staffed over time.
Partner and PS team feedback confirms the Unassigned state removed the most common friction point in early dispatcher onboarding.
The feature is in Early Release. Target adoption is 30–40% within 4–6 months — a number that reflects the behavior change required, not just feature availability.
Assignee can now be customized onto any screen
What's Next
The component exists. The use cases are just beginning.
The immediate next step is integrating the multi-select component into the app builder — Method's new no-code designer — so customizers can use it across any screen, any table, without writing code or building workarounds.
Beyond that: real-time availability filtering, grid support, Team Management, and custom multi-select fields on any table. Each one extends the foundation without rebuilding it.
The next question — what do dispatchers who adopt multi-assignee do differently in their first two weeks compared to those who don't? Finding that moment is what accelerates the adoption curve.
What I learned
The design pushed the platform. That's the standard I'm holding myself to.
The most significant outcome wasn't the multi-assignee field — it was Loop Through List. I pushed for it as a platform primitive rather than a one-off solution. That decision gave engineering a clear target and expanded what Method could do for every future multi-value workflow.
Cutting real-time availability filtering was uncomfortable but right. An interaction that looks like it should work and doesn't erodes trust faster than a feature that hasn't shipped yet.
The "Team" label cost iteration cycles. Next time that kind of forward-looking exploration gets scoped and deferred explicitly from the start — not designed toward and pulled back.
© Copyright 2025 ELAINE CHOW
Assigning a Team, Not Just a Person
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Role
Lead Product Designer
Industry
Field Service
Company
Method CRM
↓ 20 hrs
Custom dev cost per customer to simulate what should have been standard
→ 30–40%
Target adoption within 4–6 months of launch
✓ 2
New platform capabilities built that had never existed in Method
User needs
Dispatchers couldn't represent work that wasn't yet staffed.
Method required certainty before a job could exist. One technician. One date. No flexibility. Real field service doesn't work that way.
A pool installation needs an estimator and two technicians. An HVAC job needs a senior tech and an apprentice. A time-sensitive repair needs whoever is available — often more than one person.
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
"I need the ability to assign a Work Order to multiple technicians."
"Inability to assign multiple technicians to a work order."
"Struggled with scheduling and assigning multiple technicians to a work order, as well as reassigning work orders easily."
Three data sources. One problem.
Today
This is how dispatchers were managing it.
Problem 1: You couldn't assign more than one person.
Problem 2: You couldn't save a job with no one assigned.
Workarounds: Multiple assignees
Creating duplicate work orders — one per technician
Building sub-work orders (child WOs) to represent each additional technician
Paying for custom development — up to 20 hours per customer — to simulate multi-select
Workarounds: Unassigned work
Assigning a placeholder or dummy technician just to save the record
Tracking unstaffed work outside the platform in spreadsheets or notes
Workarounds: Platform
Customizers building sub-work orders or duplicate fields to simulate multi-select anywhere in the system
Partners charging customers for what should have been standard out-of-the-box functionality
Constraints
What's right and what's buildable.
Existing "AssignedTo"
+
Legacy code
+
SyncFusion Calendar
+
No - code platform
Legacy no-code platform.
No native multi-select existed anywhere. Every interaction pattern had to work within existing component infrastructure or require a deliberate platform investment — which I had to make the case for explicitly.
Existing "AssignedTo" Component
Converting it would have required dropping database constraints and rewriting every query that touched it. The parallel approach kept existing workflows intact while the new model was proven.
Strategic release
shipping as Early Release to control scope before expanding it. Grid support, calendar filters, and custom multi-select fields on other tables were deliberately locked until the core was proven stable.
Turning point
Designing the feature revealed a gap nobody had anticipated.
Once the assignment interaction was defined, a new problem surfaced. Each technician needed their own notification — not one email to a group, but one action run per person.
The platform had no way to do that.
There was no Loop Through List in Method. It had never existed. Without it, multi-assignee was a visual change with no operational backbone. A dispatcher could assign a team — but the system couldn't act on each member individually.
I made the call to build it as a platform primitive rather than a one-off workaround. My dev built it from scratch — a brand new action type hardcoded into the no-code editor. Every future multi-value workflow in Method can now use it too.
Loop Through List — a platform action that didn't exist until this design required it
Actions nest inside the loop — each one runs once per technician,
Design
I pushed the platform forward. Then designed on top of it.
Assigning a team. I designed the assignment interaction to scale from one person to a crew without increasing cognitive load — each selection visible, removable, and immediately readable. On save, Loop Through List runs once per person. Each technician gets their own notification.
Unassigning entirely. I defined Unassigned as a first-class designed state rather than an empty field — visually distinct, immediately readable without a label, Notify Team hidden. A dispatcher can see at a glance that a job has no one attached without opening the record.
How I created this Interactive prototype:
Initial designs created in Figma, Vibe coded with Cursor, Connected to Lovable ai using GitHub & shared with customers & partners
Multi-select in action — Made using Loveable to send to customers and partners for user testing
Completion wasn't the signal. Behavior was.
"I have to keep reopening it every time I pick someone — can't it just stay open?"
→ one continuous interaction
"Can I just type their name? I know who I'm looking for."
→ type-ahead search
Multi-assignee
0%
0%
Satisfaction completion Rate
Number of attempts
0%
0%
Completed on the first try
"Why is it just blank? I'd expect it to say Unassigned so I know it's intentional."
→ The right instinct — an empty field reads as broken, not deliberate. I made the call that setting Unassigned as a true default required broader system changes not in scope for this release. Documented and queued for next iteration.
The hard calls
Decisions that defined what shipped.
Every feature has a version that exists in your head and a version that ships. I chose to be honest about the gap. Early Release framing meant listing limitations in the help centre — not burying them. Dispatchers and partners knew what was stable, what was coming, and that nothing was an oversight.
Sync fusion calendar — to display all users within the modal
The calendar wasn't built for teams.
Filtering by one technician would miss every job where that person was part of a crew
The challenge wasn't visual — it was behavioral
Dispatchers think in people, not crews
I designed the calendar to show the team on the job while keeping the individual findable
Validated the approach against the third-party component before committing
Designed overflow so the card never breaks regardless of crew size
Multiple assignee - Team -> AssignedTo
I deferred the "Team" label.
Originally named "Team" — anticipating a future Team Management feature
Infrastructure wasn't ready to support the concept behind the label
Shipping it would have told dispatchers the product understood teams — when it didn't yet
Pulled it back — the rename ships when Team Management ships
The outcome
The workaround is gone. The workflow remains.
The duplicate work order workaround — one record per technician, 20 hours of custom dev per customer — is replaced by a single work order that represents the team. Work that couldn't be logged without a name can now be created immediately and staffed over time.
Partner and PS team feedback confirms the Unassigned state removed the most common friction point in early dispatcher onboarding.
The feature is in Early Release. Target adoption is 30–40% within 4–6 months — a number that reflects the behavior change required, not just feature availability.
Assignee can now be customized onto any screen
What's Next
The component exists. The use cases are just beginning.
The immediate next step is integrating the multi-select component into the app builder — Method's new no-code designer — so customizers can use it across any screen, any table, without writing code or building workarounds.
Beyond that: real-time availability filtering, grid support, Team Management, and custom multi-select fields on any table. Each one extends the foundation without rebuilding it.
The next question — what do dispatchers who adopt multi-assignee do differently in their first two weeks compared to those who don't? Finding that moment is what accelerates the adoption curve.
What I learned
The design pushed the platform. That's the standard I'm holding myself to.
The most significant outcome wasn't the multi-assignee field — it was Loop Through List. I pushed for it as a platform primitive rather than a one-off solution. That decision gave engineering a clear target and expanded what Method could do for every future multi-value workflow.
Cutting real-time availability filtering was uncomfortable but right. An interaction that looks like it should work and doesn't erodes trust faster than a feature that hasn't shipped yet.
The "Team" label cost iteration cycles. Next time that kind of forward-looking exploration gets scoped and deferred explicitly from the start — not designed toward and pulled back.
© Copyright 2025 ELAINE CHOW
Assigning a Team, Not Just a Person
End-to-end
0→1
B2B
2025
My tech stack
Gemini ai, Claude code, Cursor, Lovable ai, Figma, ChatGPT
Role
Lead Product Designer
Industry
Field Service
Company
Method CRM
↓ 20 hrs
Custom dev cost per customer to simulate what should have been standard
→ 30–40%
Target adoption within 4–6 months of launch
✓ 2
New platform capabilities built that had never existed in Method
User needs
Dispatchers couldn't represent work that wasn't yet staffed.
Method required certainty before a job could exist. One technician. One date. No flexibility. Real field service doesn't work that way.
A pool installation needs an estimator and two technicians. An HVAC job needs a senior tech and an apprentice. A time-sensitive repair needs whoever is available — often more than one person.
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
"I need the ability to assign a Work Order to multiple technicians."
"Inability to assign multiple technicians to a work order."
"Struggled with scheduling and assigning multiple technicians to a work order, as well as reassigning work orders easily."
Three data sources. One problem.
Today
This is how dispatchers were managing it.
Problem 1: You couldn't assign more than one person.
Problem 2: You couldn't save a job with no one assigned.
Workarounds: Multiple assignees
Creating duplicate work orders — one per technician
Building sub-work orders (child WOs) to represent each additional technician
Paying for custom development — up to 20 hours per customer — to simulate multi-select
Workarounds: Unassigned work
Assigning a placeholder or dummy technician just to save the record
Tracking unstaffed work outside the platform in spreadsheets or notes
Workarounds: Platform
Customizers building sub-work orders or duplicate fields to simulate multi-select anywhere in the system
Partners charging customers for what should have been standard out-of-the-box functionality
Constraints
What's right and what's buildable.
Existing "AssignedTo"
+
Legacy code
+
SyncFusion Calendar
+
No - code platform
Legacy no-code platform.
No native multi-select existed anywhere. Every interaction pattern had to work within existing component infrastructure or require a deliberate platform investment — which I had to make the case for explicitly.
Existing "AssignedTo" Component
Converting it would have required dropping database constraints and rewriting every query that touched it. The parallel approach kept existing workflows intact while the new model was proven.
Strategic release
shipping as Early Release to control scope before expanding it. Grid support, calendar filters, and custom multi-select fields on other tables were deliberately locked until the core was proven stable.
Turning point
Designing the feature revealed a gap nobody had anticipated.
Once the assignment interaction was defined, a new problem surfaced. Each technician needed their own notification — not one email to a group, but one action run per person.
The platform had no way to do that.
There was no Loop Through List in Method. It had never existed. Without it, multi-assignee was a visual change with no operational backbone. A dispatcher could assign a team — but the system couldn't act on each member individually.
I made the call to build it as a platform primitive rather than a one-off workaround. My dev built it from scratch — a brand new action type hardcoded into the no-code editor. Every future multi-value workflow in Method can now use it too.
Loop Through List — a platform action that didn't exist until this design required it
Actions nest inside the loop — each one runs once per technician,
Design
I pushed the platform forward. Then designed on top of it.
Assigning a team. I designed the assignment interaction to scale from one person to a crew without increasing cognitive load — each selection visible, removable, and immediately readable. On save, Loop Through List runs once per person. Each technician gets their own notification.
Unassigning entirely. I defined Unassigned as a first-class designed state rather than an empty field — visually distinct, immediately readable without a label, Notify Team hidden. A dispatcher can see at a glance that a job has no one attached without opening the record.
How I created this Interactive prototype:
Initial designs created in Figma, Vibe coded with Cursor, Connected to Lovable ai using GitHub & shared with customers & partners
Multi-select in action — Made using Loveable to send to customers and partners for user testing
Completion wasn't the signal. Behavior was.
"I have to keep reopening it every time I pick someone — can't it just stay open?"
→ one continuous interaction
"Can I just type their name? I know who I'm looking for."
→ type-ahead search
Multi-assignee
0%
0%
Satisfaction completion Rate
Number of attempts
0%
0%
Completed on the first try
"Why is it just blank? I'd expect it to say Unassigned so I know it's intentional."
→ The right instinct — an empty field reads as broken, not deliberate. I made the call that setting Unassigned as a true default required broader system changes not in scope for this release. Documented and queued for next iteration.
The hard calls
Decisions that defined what shipped.
Every feature has a version that exists in your head and a version that ships. I chose to be honest about the gap. Early Release framing meant listing limitations in the help centre — not burying them. Dispatchers and partners knew what was stable, what was coming, and that nothing was an oversight.
Sync fusion calendar — to display all users within the modal
The calendar wasn't built for teams.
Filtering by one technician would miss every job where that person was part of a crew
The challenge wasn't visual — it was behavioral
Dispatchers think in people, not crews
I designed the calendar to show the team on the job while keeping the individual findable
Validated the approach against the third-party component before committing
Designed overflow so the card never breaks regardless of crew size
Multiple assignee - Team -> AssignedTo
I deferred the "Team" label.
Originally named "Team" — anticipating a future Team Management feature
Infrastructure wasn't ready to support the concept behind the label
Shipping it would have told dispatchers the product understood teams — when it didn't yet
Pulled it back — the rename ships when Team Management ships
The outcome
The workaround is gone. The workflow remains.
The duplicate work order workaround — one record per technician, 20 hours of custom dev per customer — is replaced by a single work order that represents the team. Work that couldn't be logged without a name can now be created immediately and staffed over time.
Partner and PS team feedback confirms the Unassigned state removed the most common friction point in early dispatcher onboarding.
The feature is in Early Release. Target adoption is 30–40% within 4–6 months — a number that reflects the behavior change required, not just feature availability.
Assignee can now be customized onto any screen
What's Next
The component exists. The use cases are just beginning.
The immediate next step is integrating the multi-select component into the app builder — Method's new no-code designer — so customizers can use it across any screen, any table, without writing code or building workarounds.
Beyond that: real-time availability filtering, grid support, Team Management, and custom multi-select fields on any table. Each one extends the foundation without rebuilding it.
The next question — what do dispatchers who adopt multi-assignee do differently in their first two weeks compared to those who don't? Finding that moment is what accelerates the adoption curve.
What I learned
The design pushed the platform. That's the standard I'm holding myself to.
The most significant outcome wasn't the multi-assignee field — it was Loop Through List. I pushed for it as a platform primitive rather than a one-off solution. That decision gave engineering a clear target and expanded what Method could do for every future multi-value workflow.
Cutting real-time availability filtering was uncomfortable but right. An interaction that looks like it should work and doesn't erodes trust faster than a feature that hasn't shipped yet.
The "Team" label cost iteration cycles. Next time that kind of forward-looking exploration gets scoped and deferred explicitly from the start — not designed toward and pulled back.
© Copyright 2025 ELAINE CHOW