App Redesign for Field Service Techs
Project Facts
Duration: 11 months
Industry: Telecom
Team: 4 designers
Roles & Responsibilities
UX Lead
Associate Product Manager
Deliverables
Personas
Low-fidelity wireframes
User testing prototypes
Skills Used
Agile UX
Workshop Facilitation
Product Management
Empowering technicians with customer insights to resolve service tickets
OneX Communications Inc. is a nation-wide provider of digital cable television, telecommunications and home automation services. It is amongst the largest cable television providers in the United States, serving approximately 6.5 million customers.
Field Service Technicians make up about 3,500 of OneX’s ~20,000 workforce. Every year field service techs are sent out to the field to resolve up to 6 Million work orders. Their 3k+ techs are spread out across 6 regions, and can be split into 2 major types of roles: On-Premise techs (serving residential and commercial customers) and Outside Plant Management techs (serving the overall network behind the scenes). Although both roles spend their days working on service tickets, the nature of their work varies drastically based on the area, time, and customer base that they serve.
This case study covers an 11-month long effort to unify 2 essential legacy systems into one responsive experience built on the Salesforce CRM platform.
Problem Statement
Modern Problems, Legacy Solutions
Has your Internet Service provider ever sent out a cable guy to resolve a wi-fi issue? Did you ever wonder how they knew where to go, when to show up, and what to do?
Field Techs rely on in-house legacy applications to get the information they need about their customers, but these solutions are outdated, disjointed, and slow. Not only does a tech need to know which tickets are assigned to them on a particular day; they also need to know:
What kind of customer is it? (Residential? Small business? Large Hotel?)
Where is the customer located?
What timeframe were they scheduled to receive service? Are they still available as expected?
What services are they paying for?
Exactly which device is the one that needs special attention? Where in the house/business is it located?
Do they have the equipment needed to get the job done?
Is this job near the next upcoming job? Or would it take them further and force them to re-do their route?
Unfortunately, most legacy systems provided for service technicians look something like this:
This view is meant to serve as a landing page for techs first thing in the morning as they are about to start their shift. In the moment, they' need to know which Work Order they’ll be starting with, and what kind of work they’ll be doing during that Service Appointment. Instead, the legacy landing page is laid out in a tab format, which forces the user to dig in at least 3 clicks to get to the valuable information.
User Research
Talk Aloud Sessions & Design Requirements
Although the client had an in-house UX team, the business side of the client had never worked with the Field Service workstream. That workstream was made up of about 800+ employees in across 6+ states.
We knew we had a goal of designing a unified experience on Salesforce Field Service CRM, but we still didn’t know exactly what we had to design for. At this point, 6 weeks had passed and the client was getting antsy. They were unhappy because they did not see alot of progress in designs. Although our Workstream had 1 UX Lead and 2 Junior UX designers (including me), we were struggling to understand what we had to design for and what Salesforce CRM would allow us to do Out-of-the-Box. I saw that my UX Lead was having trouble grasping core business concepts, so I put on my BA hat and began leading Requirements Gathering sessions on MURAL.
To begin gathering high level design requirements, I interviewed Field Service SMEs as they used the legacy systems. I asked them to share their thoughts as they performed their usual tasks, so that I could map their task and system flows. Since I was the first UX Designer to dive deep into the business and workflows of the Field Service workstream, I drafted high level Narrative Personas to share context about a day in the life of a OneX Technician:
Technical Challenges
Now that we knew who we were designing for and had an idea for what they needed, we were ready to begin sketching first draft screens. To ensure that we were in sync with what developers could accomplish with OOTB (out-of-the-box) Salesforce CRM, we attended bi-weekly design reviews with Salesforce SMEs. These SMEs were part of another agency (Accenture) who was in charge of leading the technical implementation of the project.
Unfortunately, even our first draft sketches were pretty unrealistic if we were to follow Accenture’s guidance of sticking to OOTB Salesforce components. Without any customization, the future-state experience might look something like this:
Barebones Salesforce Experience
This experience would be very similar to what they already had today, just in a slightly more modern format. I realized that this would not be enough for what the Business Stakeholders needed, so I had to communicate this gap in expectation between reality to my Project Leads.
Strategic Planning
Mindmapping to Lead by Example
After conducting User Research sessions with Field Network SMEs, I was able to draw a diagram that showed all the steps that a Work Order consisted of. Each job, according to expert Field Service Managers, had at least 5 phases:
Planning: Before starting their day or moving on to a new work order, Techs had to get a sense for which job made the most sense for them.
Investigating: Once they had an overall plan for their next job, they had to dig into the Work Order details a bit to prepare for the work required to complete the Service Appointment.
Execute & Validate: After they performed the job as expected, they then had to validate that the fix / installation worked as expected. They wanted to verify this to minimize return calls, which would only add more time later on.
Support: Whenever needed, techs could reach out to support and management teams back in OneX’s offices for guidance. In drastic cases, they could request that a nearby fellow tech meet them out in the field to provide another pair of hands
Close: After the work order was completed successfully, technicians had to go through a provisioning process to document all the work that was completed for the customer. This would impact if/how a customer would be billed for their time.
First, I mapped the happy path, the typical work order for a Service Appointment that went as expected. But of course, we had to account for errors and mishaps that can occur in real-world scenarios. To track all of the possible “Unhappy paths,” I put together an All Jobs-to-be-Done map. The mind map showed that although a simple work order goes through 5 phases and requires ~15 steps, more complex jobs could require up to 30+ interactions.
This diagram, paired with the personas, helped me educate the rest of the organization about the day-to-day flow of their techs. Effectively, this “All Jobs to Design For” map served as a product roadmap for the rest of the project. If we could design screens and components for each of the possible interactions, we could deliver the entire project successfully!
This helped me By explaining what was important to techs and when, I was able to build empathy and advocate for the needs of my end-users. Effectively, this justified some design decisions that would require customization to Out-of-the-Box Salesforce components. Though the customizations did add more time and budget requirements, leadership realized why investing in the experience for Field Service Technicians was so critical: Service Techs are usually the face of the brand, and are almost wholly responsible for installing and fixing critical equipment needed to provide digital services to their customers. In other words: keeping them happy meant keeping them efficient, which in turn let them take care of their end-customers.
Building Empathy
Scenario 1: Morning Coffee Routine
Whenever I spoke with Field Service stakeholders, they always stressed how important the landing page was for technicians. The goal of the landing page should be to set up techs for success by giving them context about their assigned work orders. The system should be robust enough to give them a suggested route, but it should also be flexible enough to make judgment calls about how to start their day.
The All Jobs to be Done map was great to give us an overview of everything that had to be designed, but it didn’t give us an actionable scope for MVP. To ease the client’s impatience, I had a plan to draw a path to a Quick Win. The following morning, I sent my Project UX Lead this email:
“From: Luis
To: Wally, Austin, & Magaly (Project Leads)
Dear Wally -
to land our first quick win in earning the client’s trust, we first have to understand that: All Scenarios will share a common anatomy of screen types . The “happy” path. Though they will have similar flows, the point of having these scenarios is to open our minds to the alternate flows that may happen. The “unhappy” paths.
If we can focus on defining what is needed for MVP (let’s call it Scenario 1), we can then deliver screens to illustrate it. Once we show the client we know what we’re doing and have begun making progress, we can then clarify HOW the screen flows will differ between scenarios.
To achieve that last point, I have made a much more detailed version of the Jobs to be Done map. This map aims to show the happy path, and every other alternate flow possible. To deliver the entire Field workstream, we just have to design for every use case mapped. To start delivering designs, we first have to finalize the core details of Scenario 1 & 2. This can be our MVP scope.”
At this point, I had proven to leadership and business decision makers that I had become a Subject Matter Expert in the Field Technician workstream. My previous UX Lead was rolled off the project (a mutual decision), and I remained as the de-facto UX Lead for the Field Workstream.
My first order of business was to draft a visual Scenario 1 that centered around how a Technician began their day. I called this Scenario 1:
After securing the client’s trust, we were then able to design the scope for Scenario 2. The client asked us to switch to a laptop format, to illustrate how an OSPM Network technician would request assistance during a job. The new form factor would reflect the fact that network technicians tend to work on more complex technical work orders, and therefore primarily their laptops.
High Fidelity Mockups
Actionable Context at a Glance
After achieving 2 quick wins with Scenarios 1 & 2, we were then given the time to go back and focus on redesigning screens based on new information from the Salesforce SMEs and business stakeholders.
Shown above is the pre-final version of the homepage which equips the user with valuable insights about their assigned jobs. By giving the technician all of this info in the moment, it empowers them to make a judgment call about how to tackle the assigned jobs as they see fit, in the order that is most efficient and convenient for them. Without clicking any other buttons, the user can see:
Navigation Tabs: On the Route tab by default, allows the technician to toggle between the main pages of their application.
Current Job Overview: Shows overall details about which job the tech is currently working on
Assigned Jobs list: Gives techs an overview of the upcoming jobs assigned to them on that day
Shift Start/Stop Toggle: Allows techs to toggle their work readiness status throughout the day. At the start of their day, their route (shift) is disabled. Techs turn the switch on when they are ready to signify to their dispatch teams that they are available to start working on jobs. The user can easily access this switch to signify they are either on break, or done with their route for hte day.
Weather Warning Widget: gives a quick overview of the expected weather conditions. This helps inform the techs whenever there are any weather warnings that might impact their ability to work throughout the day.
Inventory Stock Summary: To ensure that they have the tools and equipment in stock to perform their jobs, techs can see at a glance whether they have enough to get through the day, or if they’ll have to plan to make a stop at the local warehouse to replenish stock.
Live Agent Support Chat: whenever the tech has a question for dispatch and support teams, they can easily start a live chat with them at the click of a button.
Global Search: allows technicians to quickly pull up the Service Appointment Detail Page by searching for the Unique ID
In this manner, we were able to iterate through 3+ major design iterations. Below is a highlight of how our design proposals evolved from sketches to mockups as we learned more about the business’ needs as well as Salesforce CRM’s Out of the Box technical limitations.
Legacy: this screenshot illustrated the current experience. Field Techs used this as a landing home page to tell them about the jobs scheduled to them that day. It was hard to see anything useful at a glance, so my focus was to prioritize what was important to them.
Ideation: putting pen to paper to think about what is most important to technicians when they first start their day.
Sketching: began by drafting low fidelity sketches to validate initial design ideas.
Wireframing: pared back designs to show what a pure Out-of-the-Box Salesforce CRM experience would look like
Final: designed a homepage that was technically feasible, and easy to use by technicians. This screen was designed to be read as techs had their "Morning Coffee Routine"
Outcomes & Results
By using Agile UX approaches to collaborate with Salesforce CRM developers and in-house UX designers, I was able to lead the project through 4 major project phases consisting of 9 Sprints. In a span of 11 months, I was able to lead the design of 20+ screen templates in both desktop and mobile form-factors with both custom and Out-of-the-Box SF components.
I feel honored knowing that my work has influenced the way OneX performs their Field Service work orders for their end customers. Now, techs have a much easier time knowing how to fix that buggy Wi-Fi issue at home to keep us entertained.
Project Feedback
-
"Brigitte and Luis delivered the impossible. They learned an entirely new platform, SalesForce mobile, and wireframed the entire end-to-end user experience for a frontline technician that helps them quickly and efficiently solve customer issues... in FOUR DAYS. From start, through two reviews, to deliver final iterations for 25 mobile screens on Friday. Their speed and detail delivered the screens that will directly feed the team's work and usability testing in the next phase of the project."
Austin Govella, Original X Lead
-
"I've worked with Luis on two recent projects: ACS and OneX. On both, I've been impressed by Luis' ability to identify issues and guide clients and teams. Specifically on OneX, he's taken leadership of the PNM workstream and the client recognizes his expertise in that space. Both Accenture and the client have expressed how impressed they are with his insights and his leadership on the project, and we are looking for ways to give him more leadership opportunities on the project."
Wally Hitchcock, Project Lead
-
"Luis always advocated for the user experience and the processes to better understand our customers and their journeys. His dedication and consistency won the respect and admiration of his colleagues and working teams. He always communicated well, proved his ability to self-direct and provide additional insights and solutions."
Leeanna Lim, Client UX Directo
-
"I consistently hear great feedback about from our Product and Business partners: “We love Luis!” Luis demonstrates a great command of the Field knowledge space, is impressively proficient in Agile UX delivery."
Magaly Rivera, Client UX Lead