Pain Points
Throughout user interviews, support calls and general feedback, many users have commented about their frustrations of not having a clear and easy way to surface a truck driver's historical data.
The use-cases for this feature varies from dispute resolution, speeding tickets and MOT (Ministry of Transportation) guidelines.
The use-cases for this feature varies from dispute resolution, speeding tickets and MOT (Ministry of Transportation) guidelines.
Research and questions based off of past user-interviews
Business Problem
Tread uses a Looker integration to visualize Insights data. However, it ends up being a large financial investment with some technological constraints. This feature would allow our team to move away from the integration to give us more freedom.
Pain points with Looker include long load-times, data constraints (there is a maximum amount of data-points it will work with) and general design restrictions.
Pain points with Looker include long load-times, data constraints (there is a maximum amount of data-points it will work with) and general design restrictions.
Current Insights page in Tread using Looker Integration
Scenarios
Listing out the types of scenarios that would make a user go to this feature.
This includes a variety of situations such as complaints from site supervisors, speeding tickets, and ensuring drivers are working efficiently.
This includes a variety of situations such as complaints from site supervisors, speeding tickets, and ensuring drivers are working efficiently.
How might we allow admin to see a truck drivers route history?
Ideation
My first round of iterations focused on the dashboard layout. I began by creating low-fidelity wireframes of what the sections could look like and potential ways to visualize data.
Invision Freehand sketches
High-fidelity mock-ups of two layout options: (left) one that is similar to the “Live Map” page and (right) one that uses a new design system.
"[Right] is too similar to the live maps page which might confuse users."
PM Feedback
User Testing
For the first round of user-testing, I created 3 tasks that testers needed to go through: (1) How would you filter to see Craig Landry's driver profile? (2) How would you filter to yesterday's date and see data between 11:00am – 1:00pm
Task #1
"Find the driver insights page for Craig Landry"
+ To test the site architecture and see if users could find the feature
+ Similar to the PM Feedback, this flow was not distinct enough that users didn’t notice the new feature easily
+ To test the site architecture and see if users could find the feature
+ Similar to the PM Feedback, this flow was not distinct enough that users didn’t notice the new feature easily
Ideal Flow for Task 1: "Find the driver insights page for Craig Landry"
Task #2
"Filter to yesterday's date and see only the data between 11:00am – 1:00pm”
+ All users clicked the arrow to change date and missed the indicator to filter by time
+ Because of this, they did not know how to filter by time.
+ All users clicked the arrow to change date and missed the indicator to filter by time
+ Because of this, they did not know how to filter by time.
Ideal Flow for Task 2:Filter to yesterday's date and see only the data between 11:00am – 1:00pm”
Analyzing Feedback
Categorizing and grouping together the user-feedback for a better understanding of the problem areas.
Categorizing the user feedback (each user is in a different post-it colour)
After categorizing the feedback, I compiled a list of potential solutions that were shown to the PM and engineers to see if we can scope these changes in.
I am able to keep this list for future reference when we come back to upgrading this feature.
I am able to keep this list for future reference when we come back to upgrading this feature.
List of user-feedback and feature requests.
Solutioning + Setting the Vision
During our second iteration, our focus was talking with Engineers to understand the scale of creating the feature in a impactful yet efficient manner. With this, we created a series of requirements that will be included in this version:
Feature requirements written by the Project Manager
Final Feature
For the final design, I implemented these revised features, as well as created a new design system for data-visualizations that Tread didn't have before. The Driver Insights lives within the Map page on Tread. It includes details on the drivers route, speeding information, and the project data.
Next Steps and Revisions
The main challenge of this project was the beginning stages of creating a design system. I found myself going above-and-beyond what the PRD was asking and having to reel myself back and reminding myself that I need to focus on solving the main problem before exploring other situations.
If I were to do this again, I would ensure that each part of the process was fleshed out before moving on. In the beginning, I rushed into wireframing and realized I needed to go back and research a bit in order to not get overwhelmed. I wanted to have a logical answer for all my design decisions. Moving forward, I am going to ensure this doesn’t happen again so I dont waste time getting side-tracked by checking with my Head of Design before moving onto another stage.
If I were to do this again, I would ensure that each part of the process was fleshed out before moving on. In the beginning, I rushed into wireframing and realized I needed to go back and research a bit in order to not get overwhelmed. I wanted to have a logical answer for all my design decisions. Moving forward, I am going to ensure this doesn’t happen again so I dont waste time getting side-tracked by checking with my Head of Design before moving onto another stage.