Fall 2020, 4 months
User Research, User Interviews, Product Framing, Product Design
Ayla Church (Intern Mentor), Alexa Ekberg (Product Manager), Front End + Back End Engineers
What do our users value? What value would this product give them? How would this product make their jobs easier?
The primary users for this product are Driver Managers and Dispatchers. Our team interviewed people in these roles at various trucking fleets to better understand what information they need and value. We found that these users want a centralized location to view detailed information about their drivers' trips. These managers need to see real-time data about where their drivers are, what step they are at in their workflow, and if there are any pressing issues to address.
A value add that our company brings to the trucking industry is visibility of information. We value providing our customers with data-rich interfaces to help streamline their operations. The difference between what we are trying to do and what a backend TMS (transportation management system) does is that our product should take all of the relevant data points from the TMS and expose them to users in a way that is intuitive and encourages fleet management.
A challenge we found is that there is a lot of information that different fleets need, so we needed to find a way to make all of that information visible without visually overloading our users.
What can I learn from existing data-rich systems that are used in trucking?
There is a fine line between transportation management systems and fleet managements systems. In order to really understand how our product should be different while also learning about data-rich environments, I explored the TMS interfaces that our current customers use. I also interviewed a few Dispatchers and had them walk me through how they use these interfaces which ended up being very helpful when I tackled the user experience flow for our product.
From these explorations, I learned that maps provide invaluable context that TMS's lack. I also learned that these users value seeing a lot of information all at one time, so data can be small and close together. Lastly, I learned that these users needs extensive and flexible searching and filtering capabilities to be able to find a specific order, load, or trip. The interfaces themselves taught me that with a lot of data, you need to have a very strict organization and color system that can be intuitively learned over time.
How can the overall architecture of this product better optimize managers' workflows when looking at trips?
The first exploration I did was looking at different options for navigation and overall architecture. When using this product, managers will be focused on looking at real time data and managing by exception. Because of this, I looked at the relationships between the different trip statues and how accessible they should be in the navigation.
How can the layout and user experience promote easy access to information?
After exploring the navigation and architecture, I started to build out the other pages of the portal and explored layouts for the list of trips and the individual trips. I experimented with different experiences of navigating between the two different pages because I wanted there to be a close experiential tie between the two.
How can I learn from my product and engineering partners?
After making mid-fidelity wireframes and going through an initial design review, I brought the designs to my Product and Engineering team to get feedback. There was a lot of pushback from the engineers against having a split-screen view where you could see the list of trips and an individual trip on the same screen. From their tech designs, they found that this would put a lot of work on the server to populate all of this information and would end up causing the page to load very slowly. From this, I needed to weigh the benefits of seeing both pages at once with the detriment of slow performance.
From my Product Manager, I received some suggestions to have a map available with the list of trips in addition or instead of on the individual view. This was something I definitely wanted to get validation on from our users. I also received some questions and comments about the function of seeing historical trips, and whether this experience should be the same or different from seeing active trips.
From all of this feedback, I iterated on my designs and then set up interviews with our users to do some testing.
What can we learn from actual driver managers and how they work?
At this point in the design process, I took my ideas and assumptions to several driver managers. They walked me through their current work processes and the positive and negative aspects of their current software. These interviews reinforced the need for flexibility and visibility within this portal. Different companies needed different pieces of information and prioritized this information differently, so through my designs I needed to find a way to provide hierarchy while still accommodating all the companies that might use this tool in the future.
The users I interviewed also told me that they like to have one screen up with all the high level information they need which influenced the way I looked at the list view of the trips versus the individual view of one trip. Lastly, I learned about the importance of context. Something that our fleet management does that existing TMS systems don't, is provide maps to give geographic context. In my previous iterations I was trying to figure out where this map was needed whether it was on the list view or in the individual details page.
How can I use my critiques and interviews to improve the design?
After getting feedback from driver managers and my internal product team, I made some decisions about how the product should be built. I learned that there was less of a distinction of the use cases for looking at active and past trips than I initially thought, so these pages were merged together. Additionally, I found that maps were only necessary when looking at the details of an individual trip, and not very important when looking at the high level details. Driver Managers said they all they needed to know when looking at a trip at a glance was the start and end cities, so I added these to the list view and removed the map from this page. Additionally, some of the functionality iterations I did for past trips actually seemed to be helpful for active trips, so I incorporated some of those interactions into the final designs.
This project taught me about the product process and how to utilize and learn from different stakeholders. As a designer, my job will always be to advocate for the user, but I learned that I also have to have my ears open for my sales, engineering, and product partners. One of the hardest parts of designing this product was designing it to fit within our existing Fleet Product without having worked on the Fleet Product or having any power to adapt part of that product. I tend to think about design problems holistically and systematically, so it was challenging for me to only get to touch a small piece of the system. With that being said, I really enjoyed the impact I did have on this product, and it gave me a lot of confidence to challenge my PMs and engineers on features that I really believed in for my users.
This product is being beta tested with real driver managers soon, and I'm looking forward to their feedback to make changes and work towards the next iteration.