Problem
The shipping industry is very antiquated. Therefore, INTTRA was hesitant to move into the mobile space for complex tasks, but their competitors were, so they wanted to create an app that could be used for a simple task.
Project
I was tasked to create a mobile app based on the concept of using AIS tracking that would allow INTTRA users to easily track their shipments from their smartphones.
My Role
I was the sole designer on this project so I was responsible for all of the design requirements from low to high fidelity. I worked closely with the Product Manager and my manager, the Head of UX, throughout the process.
Research & Brainstorming
The first step of my process was a brainstorming session with the Product Owner and Head of UX. The Product Owner explained all her ideas for what the app should do and certain requirements. She walked me through the research she had done prior to my involvment and the main use cases she developed. After working with her on some very low fidelity sketches to make sure we were on the same page, I started brainstorming the user flow. I like to quickly write out what the user flow should be before making high fidelity mock-ups to eliminate any major flow issues. Then I like to make thumbnail sketches of the main screens before moving on to Sketch.
Low to High Fidelity
After sketching, I move to making high-fidelity screens in Sketch. I had never used Sketch before my internship at INTTRA, but I have learned to love it and all of its capabilities. I used the Craft plug-in to link all the screens before I pushed it to InVision.
When the user first logs on to the app it brings them to the point on the map where the highest concentration of ships carrying their containers is. This is the ship view. There is a button to toggle ETA change warnings on and off, which highlights some ships/ports red or green. Red signals that a container is arriving or leaving late, while green signals that it is ahead of schedule.
When a user zooms in to a ship, the name and amount of containers is revealed. Then once a user taps on a ship, the vessel details are shown. The details include the ship’s name and country, its current status, speed/course, draught, a visual of the route, and the list of containers on that vessel (all containers are listed by their container, reference, and booking number). In addition, there is an option to add it to the user’s watchlist, which can be viewed by selecting the third option on the bottom navigation bar.
The map can also be viewed by the port view, where the user can view the ports that their containers are arriving to or departing from. The map can be filtered using the most top right button.
When a user zooms in to a port, the name and amount of containers going through that port is revealed. The details are displayed as a calendar view. It defaults to the current date selected on the calendar, so all the containers listed are coming in or leaving that day. ETA changes are also marked on the calendar by red and green dots.
When a container is selected from any view, the container details are pulled up. The container detail screens are the most in-depth information a user can access in this application. These include the three reference numbers, Track and Trace events, and a view of the vessel the container is on with its position on the map.
The last feature of this app is the search function. It was impossible to have one smart search bar that could differentiate from/to searches from ship names or trade lanes, so I chose to take a different approach. Once the search icon is selected, the app will fetch all of the user’s booking data. The recent searches are displayed for every category, but once a category is selected, only that categories data is selected. The user can then use a search bar to narrow down within that category. For example, if the user selected from/to, all the ship routes that the user’s containers travel would be listed. If "Shanghai" was typed into a search bar, then all "Shanghai to" or "from Shanghai" options would remain. Therefore, the search function really becomes a filtering function disguised as a search for the user. This is only possible because the app is based on solely the user’s data and information and is not looking at all of INTTRA's shipping data.
Outcome
Compared to the first app I created for INTTRA, this one was definitely more difficult because it starts from a vague concept the Product team had. From that loose idea I worked with the product team to develop the main use cases, which lead to more concrete requirements. This was a great learning experience about how ideas are developed in the workplace, with the help of different departments working together. Later that year after I left INTTRA, it was demoed at a technology showcase in Singapore!
Desktop Version
After fleshing out the prototype for the mobile application, I created a concept for what a desktop version of the same app would look like and how it would function. This was the first experience I had translating an app from mobile to desktop. I learned that it is a lot easier to go from mobile to desktop than desktop to mobile because the design is already very simplified.