ETSA Tracking

Tracking tool for transport of dangerous goods

Year: 2018

My role: UX/UI designer

Company: This project was developed with Undanet for the ETSA company.

Team: This project was developed with a diverse team, including a project owner, back-end developers and front-end developers. We initially collaborated on the conception and information architecture stages. Later in the development of the project I also worked with the front-ends to validate the UI.

Introduction

The transportation company ETSA, specialising in the transport of dangerous goods, required a solution to manage and track the real-time activities of their trucks and drivers on a map. This project involved a lot of data and several entities, and our team was hired to develop a responsive application that would solve their problems and fulfill their needs and requirements.

The process

1. The discovery : interview with the client and a representative of the end-users and definition of the specifications.

2. Architecture definition : definition of the Entity-Relationship diagram and the user journey.

3. First mockups and feedback from the client.

4. Final solution.

The discovery

First, the project owner, the development leader of the project and I met the client who presented the project. We asked many questions in order to better understand the nature and constraints of the transportation activity and discussed further the client’s needs and wishes.

After this meeting we were able to identify the technical and business requirements and to list all the application usage needs.

Product requirements:

Admin portal

A portal for Admins to register and manage users, vehicles, drivers and alerts.

Bilingual app

Application accessible in 2 languages: English and Spanish

Desktop first

To be used mainly on desktop and on mobile by out of the office on-duty workers.

User requirements:

Users needed the display of a map in the app, where the elements such as vehicles or paths could be pointed. This map was very important and the client insisted on it being visible at all times.
Users needed to view and filter alerts, including those from the last 24 hours, as well as conduct personalized searches.
Users needed to be able to see the list of all the vehicles, their speed, the last transmission time, be able to point them in the map, filter them by groups, by area, by status (active/inactive), and search for a specific license.
Users needed to be able to see all the drivers, and the last location and transmission time, and be able to point the last location in the map.
Users needed to be able to create, see and edit points in the map to later be able to create, see and edit paths. Paths would be used in routes and are made of an origin point, a destiny point and none to many middle points.
Users needed to be able to create, see and edit zones, which can be created from paths, to define the perimeter for alerts for those paths.
Users needed to be able to create, edit and delete routes, by using paths and setting the dates and times of the origin and destiny. For each point, alerts could be activated.
Users needed to see all the expeditions by route, and for each route be able to see all the vehicles on that route and point them in the map. They will need to filter “todays” expeditions.
Users needed to assign routes to vehicles and drivers to create new expeditions.
Users needed to be able to read a summary about the drivers and the vehicles and access their history of expeditions.
Users needed to be able to activate the alerts for the Civil Guard.
Users needed to be able to export the tachograph data.
Users wanted to be able to see the vehicle in streaming.
Users wanted to compare 2 different vehicles’ expeditions data and see the route in the map.

Looking at the specifications we realized that the complexity of the project would be substantial, since we had a lof of data to work with.

Defining the architecture

We needed to organise and categorise all the data we had, not only for the developers to create the back-end of the software, but for all of the team members to better understand all the content to visualize in the designs and the relations between the different classes or categories. Then we created the E-R diagram.

Once the E-R Diagram was created, the information started to look clearer so with the project owner, we created the user flow.

First mock ups and client feedback

The user journey was the base to create some low-fi mockups. We shared these wireframes with the client and he returned some interesting feedback. The main concern was about the visualization of the map, even if the information needed to be displayed, the whole map should be visible all the time (but on the admin features). This was a little challenging, as I needed to think on how to display all the information without hiding anything else.

Final solution

I needed to find a solution to ensure the map remained visible while displaying additional data, and the best solution was using transparencies. I did some drafts, by showing the data on a non opaque dark background the user could still see the overlaid portions of the map.

Mobile adaptation wasn’t easy. There was a lot of information and the client needed to keep it all in mobile so the workers could check any data during their on-duty out of the office. However, the usage of mobile devices was very reduced, so we could simplify the views to lighten up the content on the screen.

I validated the solution with the client and, as they were very satisfied, I could design the final wireframes for all the different user stories.

Finally, with all the designs done I proceed to write a handbook for new workers formation on the application, also required for the project by the client.

Project conclusions

The ETSA Location project entailed quite a complexity, there was a lot of data to understand and visualize, and a lot of functionalities related to the different elements to manage. Nevertheless, we planned the project carefully to understand the information, the needs and the constraints concerned, and we looked for the best solution for each problem.

Finally, the client was more than satisfied with the application and especially with the usability of it, which was even better than they had expected.