Mobile App for Field Service Workers
-Digitizing Field Service Workflows
Mobile App for Field Service Workers
-Digitizing Field Service Workflows
During my internship at Brilltek, a B2B SaaS startup for machinery manufacturers, I designed a mobile app enabling field service workers to complete on-site workflows. The goal of the app is to integrate with the Service Management System, enabling technicians to record service data on-site, eliminating the need to manually transfer paperwork after their shift.
My Role
My Role
Map data flow between Service Management System and the app
User flow & touchpoints mapping
Create wireframes & high-fidelity prototypes
Document components and style guide
Map data flow between Service Management System and the app
User flow & touchpoints mapping
Create wireframes & high-fidelity prototypes
Document components and style guide
Impact
Designed a MVP approved by the internal team, ready for implementation in future development.
Achievements
Designed a MVP approved by the internal team, ready for implementation in future development.
TEAM
TEAM
1 Product Manager
1 Front-end Developer
1 Product Manager
1 Front-end Developer
COMPANY
CLIENT
Brilltelk
Client: FCS
FCS(Machinery Manufacture)
DURATION
DURATION
3 weeks, 2023 June
3 weeks, 2023 June
TOOLS
TOOLS
Figma
Figma
Backtracking Data Flow to Define the Project Scope
Backtracking Data Flow to Define the Project Scope
I analyzed the existing service management system to identify data relevant to workers' tasks, then backtracked how this data should be recorded in their workflow. This process helped define the necessary tasks and features for the workers' app.
I analyzed the existing service management system to identify data relevant to workers' tasks, then backtracked how this data should be recorded in their workflow. This process helped define the necessary tasks and features for the workers' app.
I started off from understanding the current system, including the information structure and the functions. To help me understand it efficiently, I sketched a rough sitemap.
At this point, I identified the pages that relate to worker-side. For each page, I looked into the functions, focussing on the input and output of the data that relates to workers’ work flow. After understanding the system, I was able to define the scope and the goal of the project.
Project Goal
Project Goal
Design an app for the workers to complete the required tasks during service delivery process, including punch in/out, create work log, log service detail and checkout.
Workers' data entries must match the fields in the desktop service management system for seamless cross-platform integration.
Definie Workflow
Understanding Workflow
I created a flow diagram illustrating workers' service delivery workflows, ensuring that my future designs accurately align with their real-world workflows.
I created a flow diagram illustrating workers' service delivery workflows, ensuring that my future designs accurately align with their real-world workflows.
I created a flow diagram illustrating workers' service delivery workflows, ensuring that my future designs accurately align with their real-world workflows.
First draft of work flow diagram, made with Figjam
CHALLENGE
Not able to reach end users -
Reach out to relevant stakeholder
Not able to reach end users - Reach out to relevant stakeholder
CHALLENGE
Since it's B2B products with end users located internationally, I reached out to the key stakeholder - Product Manager, who designed and managed the desktop Service Management System for feedbacks.
Since it's B2B products with end users located internationally, I reached out to the key stakeholder - Product Manager, who designed and managed the desktop Service Management System for feedbacks.
Since it's B2B products with end users located internationally, I reached out to the key stakeholder - Product Manager, who designed and managed the desktop Service Management System for feedbacks.
Main things I learned -
Whether the customer makes payment depends on if the case has been completed or not.
Workers mostly do not need to create work on their own.
Whether the customer makes payment depends on if the case has been completed or not.
Workers mostly do not need to create work on their own.
Whether the customer makes payment depends on if the case has been completed or not.
Workers mostly do not need to create work on their own.
Iterated work flow diagram, made with Figjam
Next, which steps in the workflow needs the app involved?
Find Touchpoints!
Next, which steps in the workflow needs the app involved?
Find Touchpoints!
With the work flow defined, I identified the touch points in each step, allowing me to define the user flows for the field-side app.
By analyzing touchpoints within the defined workflow, I structured the user flows for the field-side app.
With the work flow defined, I identified the touch points in each step, allowing me to define the user flows for the field-side app.
Dive into Workflows and Design
02
Punch in & Punch out
01
Punch in & Punch out
System needs to know what time the worker departs for service, arrives in the site, and leaves the site. Before leaving, worker needs to complete checkout process. To avoid users from accidentally tapping the buttons, I design the pop-up modal as a confirmation step.
System requires the input of what time the worker departs for service, arrives in the site, and leaves the site. To avoid users from accidentally tapping the buttons, I design the pop-up modal as a confirmation step.
System needs to know what time the worker departs for service, arrives in the site, and leaves the site. Before leaving, worker needs to complete checkout process. To avoid users from accidentally tapping the buttons, I design the pop-up modal as a confirmation step.
Depart
commute
Arrive
service
Checkout
checkout
Leave
01
01
Punch In & Punch Out
Punch In & Punch Out
Typically, work logs are generated through the service management system.
However, there may be instances where workers need to manually add their work logs.
Typically, work logs are generated through the service management system.
However, there may be instances where workers need to manually add their work logs.
Typically, work logs are generated through the service management system.
However, there may be instances where workers need to manually add their work logs.
Displaying work cards in list view allows users to view their work schedule in time order. The most recent work would always be on the top.
Displaying work cards in list view allows users to view their work schedule in time order.
Displaying work cards in list view allows users to view their work schedule in time order. The most recent work would always be on the top.
Displaying work cards in list view allows users to view their work schedule in time order. The most recent work would always be on the top.
03
Checkout
Workers need to log in the service details depends on the type of service, have the client makes payment based on their warranty status, and ask the customer to fill out the satisfaction survey.
Workers need to log in the service details depends on the type of service, have the client makes payment based on their warranty status, and ask the customer to fill out the satisfaction survey.
Workers need to log in the service details depends on the type of service, have the client makes payment based on their warranty status, and ask the customer to fill out the satisfaction survey.
03
Checkout
Maintain
Circuit / Fix
Service type?
make payment
Yes
No
Service Complete?
move on to next schedule
Task moved to Pending zone
Ask customer to fill out the satisfaction survey
Different ticket types require different form of service detail record
Needs of Payment depends on if the customer is on warranty.
Iterate from Stakeholder Feedbacks
Iterate from Stakeholder Feedbacks
At this stage, I reached out to the PM who possess expertise and experiences in the system as well as understanding of the workflow to ensure that my design aligns with real needs and is operationally feasible. Below are what I learned and changed based on the feedback.
At this stage, I reached out to stakeholders who possess expertise in the service management system and the workflow to ensure that my design aligns with the workers' needs and is operationally feasible.
At this stage, I reached out to the PM who possess expertise and experiences in the system as well as understanding of the workflow to ensure that my design aligns with real needs and is operationally feasible. Below are what I learned and changed based on the feedback.
01
01
Keep one primary button for punch-in & punch out at a time
Keep one primary button for punch-in & punch out at a time
Efficiency and Error Prevention are Key in Work Scenario
Efficiency and Error Prevention are Key in Work Scenario
In the original flow, I kept all the buttons on the screen with the ones that should not be tapped on disabled as I thought users would like to see the time stamp for each state. After discussing with PM, I realized in the real setting, the key for workers is efficiency.
In the original flow, I kept all the buttons on the screen with the ones that should not be tapped on disabled as I thought users would like to see the time stamp for each state. After discussing with PM, I realized in the real setting, the key for workers is efficiency.
In the original flow, I kept all the buttons on the screen with the ones that should not be tapped on disabled as I thought users would like to see the time stamp for each state. After discussing with PM, I realized in the real setting, the key for workers is efficiency.
Too many Buttons Increase Cognitive Load and lead to Errors
Too many Buttons Increase Cognitive Load and lead to Errors
More than one buttons on the screen increase users' cognitive load and prone to errors, especially in work setting when the field technicians need to commute to the site. Even if the buttons are disabled, errors can lead to additional time consumption and reduce work efficiency.
More than one buttons on the screen increase users' cognitive load and prone to errors, especially in work setting when the field technicians need to commute to the site. Even if the buttons are disabled, errors can lead to additional time consumption and reduce work efficiency.
More than one buttons on the screen increase users' cognitive load and prone to errors, especially in work setting when the field technicians need to commute to the site. Even if the buttons are disabled, errors can lead to additional time consumption and reduce work efficiency.
Before
Reduce Options for Users
Reduce Options for Users
Adopting Hick’s Law, I designed the new punch in & out flow to reduce the options for users, and reveal the options progressively as needed. To ensure feasibility, I communicated design with the engineers to make sure it's feasible to change the button's states based on users' progress.
Adopting Hick’s Law, I designed the new punch in & out flow to reduce the options for users, and reveal the options progressively as needed. To ensure feasibility, I communicated design with the engineers to make sure it's feasible to change the button's states based on users' progress.
Adopting Hick’s Law, I designed the new punch in & out flow to reduce the options for users, and reveal the options progressively as needed. To ensure feasibility, I communicated design with the engineers to make sure it's feasible to change the button's states based on users' progress.
After
commute
service
checkout
02
02
Ensure information is complete for all user touch points
Ensure information is complete for all user touch points
Anticipate Essential Info Needed For Users' Tasks
Anticipate Essential Info Needed For Different Stakeholders' Tasks
Given the complex workflows, I realized that it's important to anticipate the information required in the workflow, not only for the end-users (technicians), but also the related stakeholders (customers) that would also involve in the flow.
Below are two scenarios that require additional information for task completion:
Given the complex workflows, I realized that it's important to anticipate the information required in the workflow, not only for the end-users (technicians), but also the related stakeholders (customers) that would also involve in the flow.
Below are two scenarios that require additional information for task completion:
Given the complex workflows, I realized that it's important to anticipate the information required in the workflow, not only for the end-users (technicians), but also the related stakeholders (customers) that would also involve in the flow.
Below are two scenarios that require additional information for task completion:
Workers need machine details
before going out for service
Workers need machine details
before going out for service
Workers need to know in advance what machine and breakdown issues they are expecting to be fully prepared for the service. Accordingly, I added a button to each task card, allowing workers to view machine details
Workers need to know in advance what machine and breakdown issues they are expecting to be fully prepared for the service. Accordingly, I added a button to each task card, allowing workers to view machine details
Customers expect to view the payment details for confirmation before making payments
Customers expect to view the payment details for confirmation before making payments
I added the payment summary on the checkout sign page for customers' reference.
I added the payment summary on the checkout sign page for customers' reference.
Before
Before
Before
After
After
After
03
03
Balance between UX and Development Cost
Balance between UX and Development Cost
In the checkout flow, workers need to input different reports based on different services. The number of items to report can also vary based on actual situations.
In the checkout flow, workers need to input different reports based on different services. The number of items to report can also vary based on actual situations.
In the checkout flow, workers need to input different reports based on different services. The number of items to report can also vary based on actual situations.
Scrolling in Modal Can Increase Development Complexity &
Overwhelm Users.
Users need to enter the service report directly in the modal.
However, for "Fix Service", they will need to scroll in the modal when there are more than one item to report.
Not to mention for "Maintain Service", filling out a long checklist requires scrolling.
Users need to enter the service report directly in the modal.
However, for "Fix Service", they will need to scroll in the modal when there are more than one item to report.
Not to mention for "Maintain Service", filling out a long checklist requires scrolling.
Users need to enter the service report directly in the modal.
However, for "Fix Service", they will need to scroll in the modal when there are more than one item to report.
Not to mention for "Maintain Service", filling out a long checklist requires scrolling.
V1
V2
To avoid scrolling, I decided to let users enter input in separate modals for each reported item. For "Maintain Service", though still needed scrolling, having full modal to decrease length of scrolling.
To avoid scrolling, I decided to let users enter input in separate modals for each reported item. For "Maintain Service", though still needed scrolling, having full modal to decrease length of scrolling.
To avoid scrolling, I decided to let users enter input in separate modals for each reported item. For "Maintain Service", though still needed scrolling, having full modal to decrease length of scrolling.
1
Efficiency & Error Prevention are Key
Final Design
Final Design
Explore more projects
Explore more projects
Explore more projects