Responsive Web Design📱🖥
FR8Star is a two-sided marketplace that helps shippers with complicated oversize/overweight cargo to find specialized carriers who can move their cargo from A to B. Within the last 8 months we've redesigned all of the major flows and created multiple new large features. ’Shipper Flow’ is a key feature for shippers that helps them to determine a right trailer for their load, understand prices options, calculate required permits and post a load to FR8Star Carrier network.
I'm going to walk you through how we were working on it. The flow is very complex and data-heavy, so I hope you're not going to fall asleep in the middle of reading my story 😇💤.
Before the redesign Shipper Flow was a quite primitive calculator with basic dimensions like length, width, and height where a shipper could get an estimate and post their load to receive bids from carriers. Auction based platforms and bidding in general is a norm for trucking industry. That is how people were operating for years and years, keeping an understanding of market rates in their heads. Traditional brokers being a middle man between shippers and carriers often overcharge shippers and underpay carriers. That is part of the reason why there is not much trust in the industry.
It was clear that there’s a need for a change so we introduced Price Lock. Now shipper could agree to the price FR8Star offers and wait for us to find them a carrier without any additional work. Just provide us information about the load, pay a deposit and wait for your load to arrive!
First of all, we decided to use back then current scrappy version and add Price Lock as an option in order to understand how popular the feature is going to be among our shippers.
And it was! Our first Price Lock was booked within first 3 hours after we released the test version. It was a success!
But the flow was designed poorly for many reasons. First one was the confusing interface - shippers were overwhelmed with data and it wasn’t clear what their options are. Second reason is Price Lock rate being too high - in order to offer a competitive rate we needed much more information about a load. We also needed to understand possible questions we can ask a user, so we can improve our pricing algorithm.
We had a very aggressive timeline for the redesign - 3 weeks - it’s quite tight even for a fast moving start up in the Bay Area. The primary goal that was set by the leadership team was to increase the number of load posts. In order to make it easier to achieve we decided to split this goal into 3 more tangible assumptions.
- If our pricing was based on real time market data, booking options were transparent and easy to understand, then Price Lock would be a more attractive choice for users;
- If we introduced different shipment types (taxonomy) it would be easier for users to fill out dimensions, our success rate on this step would increase, and time required to finish this step will decrease;
- If we asked about loading and unloading methods it would be easier to determine a proper trailer, so that users understand how it works. We will also be able to calculate the price more accurately.
It's quite unusual to test a few assumptions, but this flow is so complex and data-heavy, that we decided to not stop on only one.
In a kickoff session with developers we decided the way we’re going to approach the flow implementation so we are able to deliver it in time. We agreed to simplify some of the interactions that didn't jeopardize the User Experience, prioritize new feature development like load taxonomy and determine a correct trailer type.
Things were changing quickly so we had daily meetings with the leadership team in order to understand and confirm requirements and update them on our progress. We squeezed in some user interviews and validation sessions on a low fidelity stage. Talking to users and validating concepts is an essential step in every feature development even when you have only so much time.
We knew it’s going to be a stepper, because we needed to save some of the info before giving you a rate. And chunking complicated flows into simpler pieces is always a good idea. We split the work between me and Roslynn. At the end I was making sure that all styles are matching, everything is properly aligned and etc. I was responsible for delivering final assets to the engineering team as well as supporting them along the implementation process. There’s a lot of logic behind pretty much every screen, so we needed to make sure that our requirements are up to date and available for backend and frontend developers. We were working on this together with a Product Manager.
Let me explain you how we implemented this flow. The first step is Location. This is essential and pretty easy for a shipper to fill out, so we decided to place it first.
Second step is dedicated to getting to know as many details about shipper's load as possible. That's where we introduced a few new features. First - different categories of a load that you can choose from (we have 7). Depending on a category you choose we ask you different questions. E.g. if you ship a tractor, we're going to ask you if it's operable or not. But if you ship a container, you're not going to get this question (containers are still not self-driven in 04/2018).
Another thing, that we implemented that made a huge difference in our success rate is pre-filling dimensions of your equipment for you. We got this data from our partners, and it solved a huge user's pain point. It's always not clear where to look for dimensions of a Caterpillar 10D e.g. (or any other equipment), you definitely need to open another tab and search for them. Accurate dimensions are very critical in determining the right trailer type and accurate rate.
We discovered a few downsides of these new features in our interviews with users. They didn't really understand the difference between taxonomy levels, therefore it was confusing for them what they should choose for their giant equipment - should it be 'oversized' or 'equipment & machinery'? In our discussion with the leadership team, we decided to table this issue and come back to it later.
Third step allows you to understand which trailer you should choose for the load. We already know your dimensions and weight, based on those some of the trailers are not going to work already. In order to choose the cheapest trailer possible, we need to know how you're planning to load and unload your equipment. This trailer table was a blast among first time/inexperienced shippers, but it still allowed experienced shippers to choose whatever trailer they want. Users loved it, they played with it, they made screenshots of it for their reference.
Fourth and final step is Rate. That's what users are coming for. We figured out all the needed information to offer an accurate competitive rate, so a user can compare booking options and choose between locking in our price or going with bids. We also break down all the costs that might be required (permits in different states, add-ons like tarping etc.). We planned quite a few A/B testings on this step, comparing different presentation of the price breakdown, different copy and etc. We also A/B tested the registration gate placement which resulted in a very significant and unpredictable discoveries.
So we did it! 🎉🎉🎉
It was a lot of work, but it was very exciting to see how our users respond to it. Completion time decreased significantly and users started to choose Price Lock option more often. But the taxonomy levels continued to be confusing for many users, so this is on our roadmap. We delivered this flow in time, but it looked quite ugly and we had many errors that users received. We made sure that this amount if insignificant and polished the flow with time, trying new approaches with data presentation and some new rate options to choose from.
Next time, I’m going to work on a complex data-heat flow like this, I would definitely want to have more time and it would be great to talk to users more then we did on all stages of the development process.