Work
User Research
The point of research for LuckyTruck is to understand and then improve upon current user experiences. This leads to increases in user engagement and satisfaction in our products. For the business, it reduces cost to serve and cost of sales.
Role
Design Lead
Employer
LuckyTruck
Platform
Webapp
Areas
Here is background context about LuckyTruck.
Go to the research
LuckyTruck Website
Launched in 2019, LuckyTruck (LT) is a modern insurance platform for commercial trucking. It is the first all-in-one retail platform exclusively focused on the trucking insurance market.
Problem Statement
We want to to increase the levels of ease, adoption, use, and satisfaction of the LT platform with both truckers and brokers. Reducing friction points and solving issues will increase these factors and help to drive business goals and metrics.
Research Plan
1
User Journey Maps
Fix broker problems first starting with understanding how brokers are currently working by creating user journey maps
2
Prototyping to Task-Based Testing
Understand how brokers are currently using the platform (moderated remote usability studies aka task-based testing).
3
Research Findings and Delivery
Collect information, analyze, and deliver findings.
Main User Groups & Goals
![](https://framerusercontent.com/images/aokjRCll6VP89D65g62RHks2xt0.png)
Commercial
Truck Driver
Commercial truck drivers (truckers) are LT's primary customer. Their primary goal with LT is to purchase and get covered by an insurance policy that covers their drivers, vehicles, and commodities. They are supported by the LT Platform and LT Brokers.
LuckyTruck
Broker (Sales)
LT Brokers are sales agents who speak with truckers to help them get covered by an insurance policy. They use the platform to support their sales process and communicate with truckers over the phone and email
1
I conducted interviews with brokers asked about their work process. I created 5 user journey maps to find critical friction points and understand their work better. After these maps were created, themes were connected and discussed with product and leadership.
Information has been obscured and altered to protect privacy
![](https://framerusercontent.com/images/pKukSCnTM4GtMPSHjmhANLTDg.png?scale-down-to=4096)
2
To start with task based testing, I re-created the entire broker flow as a high-fidelity prototype in Framer. This prototype had live-text fields, interactive buttons, and was a near replica of the platform. I went through this effort to find issues, but also to quickly build conceptual fixes quickly and without interrupting engineering.
![](https://framerusercontent.com/images/pKaDm6DmoWbB2UrlvayMjm42LbY.png?scale-down-to=1024)
I created scripts to use with brokers during testing. These scripts had brokers act as if they were on a call with a trucker and needed to complete certain tasks. During the remote session using Google Meet, our PM was the facilitator, while I took notes and ran support.
3
For analysis, I would take screen shots and and mark where there were observations. For each observation, there was a consideration on how to fix the issue. Each observation was numbered and given a priority ranking for how critical of a blocker it was for the user. Priority and numbering was great for giving to the PM and engineers to create requirements and turn into sprints.
Information has been obscured and altered to protect privacy. Actual data is much more descriptive and technical
![](https://framerusercontent.com/images/1emREFDxacnVOtcBw5EDi5YRzA.png?scale-down-to=1024)