#
#

Employee GPS Tracking APP & ERP Integration Service

#

Background

Amy is a young, female entrepreneur, who runs a pest control company. As her company growing rapidly, she found herself needing a more digital, efficient check-in system to manage those increasing pest control operators.

Amy had tried to build an ERP including a check-in system by outsourcing to company A. However, the check-in system didn't match her needs.

#

A general view of a pest control operator working.

#

Team

    My Role

  • Project Lead
  • UI / UX Designer

    Collaborate With

  • Rich (IOS & Android developer)
  • Tony (Back-end engineer)

Emphasize

#

Stakeholders

To get the full picture, we needed to notice there were several key roles in Amy's case.

#

Amy

The pest control company owner.

#

HR Team

They supervise the operators, and are the main users of the ERP system.

#

The operators

The pest control operators, users of the check-in system.

#

Company A

It developed the original ERP and check-in system for Amy.

#

User’s pain point

“Why is the current check-in system doesn't work?”

We understood that Amy had built a check-in system, but why didn’t it work well? To find out the issue, we tried the following ways:

  1. Interview with Amy and the HR team.
  2. Understand how the current check-in system and ERP worked.
  3. Interview with the operators.

There was an interesting part in this case, that the main requester of the check-in system was Amy and the HR team, but the operators were its practical users. Each of them had different pain points and goals toward this system.

#

🙁 Amy's Pain

  1. The operators refused to use the current check-in tool.
  2. I could not provide sufficient evidence to my consumers that the operators were working at the exact time and location, while the consumers were not there.
  3. Company A, which developed the current check-in system, refused to revise it.

😃 Amy's Goal

  1. Find a check-in system that is actually helpful and useful to both the HR team and the operators.
  2. To make sure, and keep evidence, that the operators are doing their duty.
#

🙁 HR Team's Pain

Without a location history, it is difficult to calculate the operators' working hours.

😃 HR Team's Goal

A check-in system that keeps location history, and can connect with the current ERP's APIs.

#

🙁 The Operator's Pain

There are so many bugs in the current check-in web, and it is slow and unintuitive.

😃 The Operator's Goal

A fast, user-friendly check-in tool.

Ideation

To sum up the previous research of our user's minds, we could easily find out why the current system wasn't working, and how a new system could solve their problems.

After several discussions with the stakeholders, we concluded the key requirements of this new check-in system：

  • Fast and user-friendly to the operators.
  • Be able to record the operators' location history.
  • Be able to connect to current ERP's APIs.
  • Be able to provide working evidence.

Prototype

#

User Flow, Structure, and Low-Fi Prototype

After some playbacks and several adjustments, a final version of the software sitemap and the low fidelity wireframe was designed.

#

A simplified sitemap.

#

Wireframe (Some flows had been revised in the design stage).

#

API Requirements (For the ERP Integration)

The new check-in app needed to connect with the current ERP system to actually met the needs of the HR team. Fortunately, we found a third party who was willing to develop the APIs for us. Therefore, I conducted an API requirements document based on my wireframe design.

#

Part of the API requirements document.

Design

#

Today's Cases

The user can easily view the cases they have been assigned today. In order to help the HR track their position during work hours, the APP will start the GPS tracking after the user push the "打卡開始“ button and pass the authentication.

#

#

Start a Case

When the user tap on a case, they can see a Google Map navigation. When the APP detects that they are closed to the designated location, the "開工" button will be active.

In the next step, the user need to take a photo of the place with their employee badge, which is to keep an evidence for Amy's company to prove that the worker had truly been there.

#

#

History Cases

The user can check on their history cases, including the GPS tracking history. The location history data will be helpful for HR to calculate their salary.

We also connected the Google Map API's estimated travel time to detect if the user is spending too much time on certain route.

#
#

All Cases

A calendar is designed for the user to quickly find all the cases they are assigned, including the future cases.

#

All rights reserved © 2021 Astrid Lin