top of page

User Experience Update Redesign
Mobile+ 5.0 
 

Transflo is one of the largest trucking applications in the United States, with over 500, 000 truck drivers actively using the Transflo mobile application. it has become the cornerstone for Transflo's business. 

 

One of my first assignments, when I joined Transflo, was to get involved in the Transflo Mobile +  Refresh. This update touched nearly every aspect of the Transflo ecosystem. 

 

Since the release of Mobile 4.0 the product team gathered feedback from the customers and decided there were three key components that needed to be worked on. 

​

1. Switching fleets. 

2. Offline Document management.

3. A personal account creation and login process.

mobile +.png

The Team

  • Director of Product Experience:

John Karl 

​

  • Product Owner:

Leisa Dareus

​

  • Tech Lead - Mobile:

Darrel Durkie

​

​

Applications

  • Sketch 

  • InVision 

  • Anima

  • Zeplin  

  • Maze

The Challenge: 

1. Switching fleets.  

With a high number of support tickets coming in for drivers having difficulty adding and managing fleets it was apparent that this feature needed to be updated.

2. Offline Document management. 

With drivers traveling through and working in remote locations drivers have been asking for a offline document que and confirmation for when documents are uploaded and sent. 

3. A personal account creation and log in process. 

Before the the 5.0 update, Transflo drivers had to join a fleet or be invited by a fleet to access the application. Because of the way the original login was set up, drivers did not have their own accounts. With Drivers not having their own accounts when they updated the app or got a new device they had to manually add any fleets that they had previously been added to. By creating a more standardized log in we were also able to create Transflo Lite, a freemium version of the app.   

​

My Role

As the UI designer my role was to work with the Product Owner and Director of Product Experience to understand the voice of the customer and synthesize their input and design solutions to improve the Mobile App.  

​

I then worked alongside the Development leads for the mobile app to make sure the designs were implemented correctly and refined designs based on development  input.   

Switch Fleets and Log in 

The first time that switching fleets was brought up in front of me I had to look at our support videos to learn how the existing switch fleet user flow worked. The fact that even an employee had to watch support videos to figure out this process is a perfect example of why this user flow had to be updated.  

Original User Flow 

User Flow .png

In the original user flow when a user launched the app for the first time they were required to input their personal information and the fleet information to access the app. If only one fleet was added and the user wanted to add another they would have to go into their profile and add the fleet through there. 

Even once the fleet was added the user had no real direction on how to switch fleets. Located next to the Transflo Icon was the switch fleet Icon. Which would only display if the driver was added to multiple fleets, but most users thought it was a Logo and not a button.

Group 33.png

First Concept

My Director instructed to conceptualize how we could improve the switch fleet user flow while he worked on the log in flow.

 

My first switch fleet user flow concept  would start with the fleets hidden as the previous design did and when the user selected the switch fleet icon the fleets would exist behind the dashboard and offer quick access or insights to the fleets. 

​

When I showed this concept, my director pointed out that fleets could not operate in a way where insights or shortcuts could be displayed here. And although a fun concept  It didn't really help with the bigger problem of users not being able to understand how to switch and add fleets. 

Second Concept

My next concept was to display only the two most recent fleets the driver had used and quick access to the new freemium version. I also suggested switching the "switch Fleet Icon" to a more traditional menu icon. 

​

However, this design was not supported by the leadership team because it put too much emphasis on the freemium application. I was later told that the drivers that have multiple fleets would need to switch through more than two fleets on a regular basis and this design was not accommodating to their workflow and wouldn't increase efficacy. 

​

Fleet swap draft .png

Tentatively approved concept

My second switch fleet user flow concept  would start with the fleets down to teach the user where fleet options would be located. I also made the add a fleet option more prominent by placing it in front of all of the other fleet options.

 

I then thought that adding an interaction to the switch fleet Icon would  help the user connect that the icon was specifically for switching fleets. So the next time the user wanted to switch fleets they would have learned that the Icon was for fleet management. 

​

The product team liked this Idea and it was decided we would move ahead with this design. However their next project for me made me rethink the entire concept.

The Curve Ball

After the design and flow was approved the product team had another recommendation for a feature they would like to add to the update. Some of our customers were requesting that we add a wifi only document upload because many divers have small data plans and were complaining about how uploading documents was taking up to much of their data.

​

While I was looking through the Voice of the Customer documentation I realized there was more to it than just allowing for WIFI only document upload setting, there were also problems with drivers having issues when uploading documents in locations with poor reception.

 

I concluded that this feature would need its own UI to act as a Document que, where the user could see failed, in-progress and completed uploads. But part of the problem was where could we store it? Because it would have to have a UI  hierarchy above fleet management because the document que could house documents across multiple fleets at time. 

​

Artboard – 1.png

Back to the Drawing Board

I decided that both theses features are connected (Switching Fleets and the Document Que) and had to be thought about together. My first Idea was to manage theses higher level app wide features through a drawer type navigation.

​

However after consideration of Standard heuristics of drawer navigation I thought this could be deceiving and miss-leading UI for the users. I wanted the UI to demonstrate that these features were above and controlled the individual dashboards. 

Group 55.png

Refining the Idea

I Started to narrow in on how users could manage fleets and the document que. By switching the switch fleet Icon for a traditional menu icon the user would not question if the switch fleet Icon was a button or a logo. Also by expanding the top navigation bar over the dashboard demonstrated that the menu controlled the dashboard. 

Close .png

My main concern with this design however was that it took users off the dashboard screen and out of their workflow during the the process.  

A Switch Up to Switching Fleets

By putting the added fleets in a carousel the user could quickly and intuitively switch between their added fleets. By adding fleet management to the top navigation it allows the user to easily navigate to the fleet management features. It was also imperative that the user could add a fleet from this navigation menu to avoid any set up confusion. 

​

This design also allowed for the addition of the Document Queue feature to be easily accessible and maintain its hierarchy above the fleet dashboards. 

iPhone-12-Isometric-Stand-Up-All-Colors-Mockup.png

Switching Fleets on Tablet

Document Queue

 Once I had the switch fleet feature designed and how the Document Queue would present in the hierarchy of design, I switched my focus to the design of the document queue. 

First Draft

My First draft on this feature was simple, The Document Queue concept displayed what documents had failed to upload and gave the user the opportunity to either remove or retry uploading the documents. 

Group 57.png

However after reevaluation I realized this design was showing signature status which was not information that was not important to the driver. The design also was not taking into account all of the potential states of a document 

Second Draft

After discussing the previous design with the product team, there were a few discoveries we made. Collectively we decided that the document Queue must display 3 different states: queued, completed, failed. And each of theses states would require the individualized functionality. The solution that I came up with was to have bottom drawer that would allow each state to have individualized functionality. 

Doc Q Draft 2.png

The Concept was well received by the product team, however the product owner wanted to get this feature completed quickly and asked me to create a simplified design to speed up the development process. 

Approved Concept 

The approved simplified design, maintained the three possible document states, a simplified UI for quicker development, and implemented setting specific upload rules for automatically uploading  queued and failed documents.  

Group 60.png

instead of implementing a bottom drawer action sheet I decided to go with a more heuristic approach and implement Kabab menus. This way the user was more aware that the action they were taking was directly affecting the individual element on the page that they were interacting with. 

Group 61.png

Errors

The upload systems was architected in a way that if an error occurred during upload the error notification would be surfaced to the user in two locations. If the user was in the app at the time of failure, it would trigger a pop notification letting the user know of the failure. If the user was not in the application at the time of failure the notification would be pushed to our internal notifications tab. 

Group 62.png

User Registration 

iPhone X_MockUp.png

My Role in User Registration 

My director had already started the mobile user registration  when I was hired, I was directed to work on other projects during this time. The original design that was developed I was aware of and looked at but never had any real involvement with the project.

​

Version One User Registration and Log-in 

Artboard.png

As we began to release this new update on the Mobile+ application we started getting feedback that users and carriers were taken by surprise by the new registration. We paused the rollout and started to roll back the update. 

Because we never tested the design with any drivers or carrier's or fleet managers the log in and registration was not received well and we had to go back to square one. The main problem with the initial design was the email verification. Due to the fact that we work in the outdated transportation industry many drivers do not have valid email addresses.

Taking the Lesson 

Since my first month at Transflo it quickly became concerning how little research was done before entering development of a project. Very little Voice of Customer (VOC) information was getting gathered and projects were being rushed. 

​

Since my initial hire at Transflo I was campaigning for more time during the research phase and allow time for user testing. My director had been attempting to get leadership on board with this as well since before my hire. We both saw this as an opportunity to show leadership the importance of user testing before starting development. I created a presentation on the importance of user testing and how it could save the company significant investment. After pitching the importance of user testing to the leadership team we got the approval to build user testing groups and the allotted time to test the new registration flow with both drivers and carriers before development would begin. 

​

Simplified Log In 

After communicating with the Transflo clients we pin pointed their concerns to two significant obstacles in the current design. 

  • Email validation wasn't necessary and caused major inconveniences for their drives. 

  • Drivers were having difficulties adding their initial fleet because it was not part of the registration flow. Many of their drivers only belong to one fleet and the fleet management existing separately than the registration was causing confusion.

​

In John's redesign he focused on the VOC feedback and eliminated email verification and added a pop up asking drivers if they already had a FleetID.  If the user already knew their FleetID that user would automatically be directed to the fleet registration user flow. 

​

MicrosoftTeams-image (7).png
User Flow SimplifiedUser Flow Simplified.png

User Testing

Once John had received approval on this redesign concept from leadership we had the opportunity to user test this design for the first time in company history. We still had limited resources and could only do remote user testing so leveraging the power of a program called Maze I created a remote user test.  

Screen Shot 2022-02-25 at 1.58.04 PM.png
Screen Shot 2022-02-25 at 1.59.06 PM.png

This user test tested drivers ability to register an account, manage their fleets, and login to an existing account. After carefully considering and creating the user testing questions and user flows we sent out the user test to small groups of both our drivers and carriers.

​

Results

Screen Shot 2022-02-25 at 2.39.28 PM.png

 Alongside the remote user testing we displayed the design changes to leaders at multiple carriers and fleets to make sure that all of our major clients were onboard with the design changes. And after we received positive feed back from our partners and clients development began on the new registration refactor.   

Retro

 After working on this mobile redesign I learned an incredible amount about the transportation industry, logistics management, and mobile application design. Working on this re-factor was a great entry project for what was to come next in my time at Transflo. The mobile application is tied to multiple backend management software's and understanding the drivers side would become invaluable when moving onto are Web-based applications to manage drivers. I got to work with an incredible team and I am thankful for the experience. At the time of writing this the application re-factor is 2 to 3 sprints from roll out. I'm looking forward to the new rollout and believe that we are much more prepared than we were for the first one and I do not see a likelihood of a second roll back. There are many parts of this re-factor that are attached to back and management systems and document management that I did not touch on in this case study because there are more closely related to the backend systems being developed currently. You can read about these in my other case studies on the Transflo One Portal and the Shipper Portal coming soon!

bottom of page