iKargo

Client Interview

The kick-off was initiated by the project manager to define the project's goals, problems and scope.

Problem

‍iKargo is at its early stage as a company and some processes are done manually. This has caused problems in tracking their day-to-day delivery of packages such as:

Lack of package monitoring which resulted to loss and delays
Inconvenient paperwork
Slow productivity

Goals

Our goal is to build a transportation management system (or at least an MVP) with the following features:

A QR scanner that updates the package status and location
Geolocation tagging
Daily reports

No-go's

For project feasibility, only the MVP features will be prioritized and the team will not include the following features which are usually found in logistics apps:

Route optimization
Customer portal or order plug-ins
Delivery signing or confirmation by customer
Delivery feedbacking

Exploratory Research

Research Objectives

To have a good understanding of the domain
To create hypotheses or assumptions to be confirmed in user interviews
To find out what success metrics can be used

What We Discovered

There are 4 types of logistics apps: On-demand, Fleet Management, Warehouse Management System (WMS) and Transport Management System (TMS).

Based on the scope of the project and the client expectations, the logistics app that we will be designing is a Transport Management System (TMS).

A TMS supports two scenarios – for a manager and for a driver. This application can also include statistics and reports which will be used by the managing staff.

Users

Managers
Managers will mostly use a desktop to view and manage reports.
Drivers
Drivers will mostly be using phones or tablets for the app. Based on previous UX case studies, some drivers can have difficulty in navigating applications, thus a simple and straightforward design should be considered.

More personal context must be uncovered in the next step such as user problems, background, and how their daily tasks will shape the app flow.

Technical Plan

Based on the preliminary information we gathered, the team came up with a summarized flow of how the MVP will work. I made a rough sketch of the interface which was then presented to the team.

User Research

Focus Group Discussion

As the UX designer of the team, I spearheaded the focus group discussion which was attended by stakeholders -- each one explaining their day-to-day tasks and the current system that they are using. The initial sketches on the technical plan was also presented to the stakeholders.

Through the discussion, the user pain points were identified and it gave me a clearer vision of how to design the app's interface and flow.

User Pain Points

Manifest creation: the users have a problem about manual input of information from different sources.
Delivery address location: drivers find it inconvenient to copy paste the delivery address or manually type it in Google Maps or Waze.
Updating reasons of package loss or damage: managers have to call each driver to confirm what caused the loss or damage of package.
Update on package location: managers have no idea where the last location of the package is in case it gets lost.

User Flow for Package Delivery or Pick-up

Solution

The app will be composed mainly of two major features: a QR code scanner for parcels and reports where users will be able to view details of scanned parcels.

Since the app is still an MVP, the design is made to be simple yet expandable in case more features will be added in the future.

View prototype.

Home Screen

The home screen design is straightforward and simple. I put in mind the possible expansion of features since there are still more pain points that the client wants to address in the future.

The MVP is only limited to few major functions as of now such as scanning the QR Code and viewing daily reports. Since these functions are considered a priority, these will be included in the home screen.

QR Code Scanner

The company's system will generate a QR Code for each parcel that will contain the parcel information.

Scanning each parcel in every hub that the users stop by will record the package information, status and updated location (done through geolocation tagging).

Customer Delivery

Scanning a parcel for customer delivery is for situations where users deliver the parcel to the customers.

The screen will both show the customer's and the parcel's information. By clicking the link of the address, this will direct users either Waze or Google maps so they can immediately locate the address.

A proof of delivery is also required if the parcel is delivered successfully. In case the package delivery is failed, another section will appear where users will have to submit a reason of failure and remarks.

Pick up

Scanning a parcel for pick up is for situations where users transfer the parcel from one hub to another. It only includes the parcel information and not the customer's. This does not include any need of proof of delivery, but users will still have to choose a parcel status.

In case the parcel is unable to be delivered, choosing the fail option will require the users to submit a reason of failure and remarks.

Delivery Report

Pressing on the delivery report button from the home screen will bring users to a summary of daily reports. They will be able to check the parcel status and when it was last scanned.

The same information will be shown from the manager's screen.

Future Plans

User Testing: after the initial launch of the app, user tests on actual users from iKargo will be conducted to validate if the app is functional and usable.
Expansion of Features: since our time is limited, we were only able to launch an MVP that has minimal but high-priority functions. Additional features will be added to address more pain points stated by the users.
Admin View Panel: the system goes in two ways -- for the drivers or warehouse personnel and for the managers. An admin view panel will be developed for managers to view records, create manifests and track parcels.

My Takeaways

Keep an open mind and allow the design process to be flexible according to the situation. There were unexpected turn of events in this project, but what helped me cope up is by being open-minded and by preparing ahead. This made me practice making better design decisions.
Overcommunication is better than under-communication. Since we were all working on different locations and different time zones, we had to update each other constantly about our tasks. It also helped that we shared one Notion page to track which tasks are pending and which ones are finished. For the client's side, I made sure to ask every question that I had in mind as long as it will help make our team create a usable app.
Keep the exploration going. Even if the discovery stage is complete, I was still able to discover more in between designs. Of course, action should be matched with constant exploration of information.