Improving Location Control
Third Person
Background
Third Person is a web app that helps eCommerce and direct-to-consumer brands find the right 3PL (third party logistics provider) to store and ship their product.
This was a remote startup environment where I was the sole designer working directly with 2 developers and one founder who was effectively our Head of Product. My responsibilities were: qualitative research, ideation, wireframing, prototyping, testing and UI.
Problem
After launching Third Person's MVP, the first big piece of feedback we received from brands was that many of them only wanted to see 3PL recommendations from a specific city or state, but the app only allowed them to specify a region.
My role
Find a way to give users more precise control over the location of their 3PL recommendations, without making users who don’t have a location preference (the majority) feel like choosing a location is required.
A known problem
Third Person’s founders previously ran a successful consulting business helping brands find 3PLs, and while doing so encountered a common issue: brands sometimes wanted their 3PL to be in a specific location, without realizing that most of the time, location was not important when determining the right 3PL for their business and product.
The app’s current solution
When designing the MVP, we understood that specifying 3PL location would be important to some brands, but weren’t sure how many or how specific they’d want to be. We didn’t want to offer super-specific location inputs at launch because we were concerned many brands would use them when it wasn’t necessary, which would degrade the quality of their 3PL recommendations.
Our interim solution was to let brands select a regional preference in the initial questionnaire flow, including a “no preference” option to remove any implication that specifying a location was required, and see how brands responded.
New objectives
Post-launch feedback proved that a significant number of brands wanted more precise control over location, and many had legitimate reason (e.g. a cannabis brand was recommended a 3PL in Utah, but couldn’t pursue it due to that state’s legality issue with storing/shipping cannabis).
This in mind, our product-minded founder and I formed two main objectives for a design update:
- Give brands the option to restrict their 3PL recommendations by city, state or region
- Ensure the new location controls feel neutral: easily accessible to brands who need them, but without feeling like a requirement so brands who don’t need them aren’t pushed to use them
Exploration
Wireframing: Solution A
I dove into wireframing to get my ideas out fast and explore. At first I updated the location question in the questionnaire to have two parts: the first question simply asked if the user had a location preference. Only if they responded “yes” would a second conditional question appear, asking for region or city/state inputs. An educational banner would also appear, stating that specifying a location was not always necessary or helpful when finding the right 3PL.
Problems with solution A
I quickly realized that if users wanted to play around with what had now become a more complex location filter, they would have to leave the recommendations view and go back into the questionnaire flow every time they wanted to update the filter criteria--a poor user experience.
Solution B
I decided to remove the filter from the questionnaire and apply it to the recommendations view so users could filter their results in real time. This more conventional filter placement also felt “neutral” in that it didn’t feel like a requirement, but was still easily accessible. Perhaps most importantly, this design allowed all users to review their top recommendations first before applying any location filters.
The filter was comprised of the following:
- A searchable dropdown filter for city or state
- Button filters for regional options
- Filter labels which appeared whenever a filter was applied to ensure the current filter criteria was obvious
Prototyping and testing
I presented my wireframes internally to our team and discussed the filter functionality. While everyone was on board in terms of clarity of function, we decided to test it out on a group of peers and acquaintances to ensure the filter logic made sense.
Due to the complexity of the searchable dropdown and region buttons combo, we determined the most effective prototype for more extensive testing would be built quickly by engineering, rather than attempting to recreate the experience in a Figma prototype.
Findings
Most users we tested on understood the filter logic once they began playing with the filter. Some initially expressed surprise at being able to apply many filters at once, but reacted positively to this realization once they understood it was possible. Users commented that seeing the applied filter labels appear over their list of recommendations made the filter logic clear.
Conclusion
Final deliverables
I used my wireframes and the component library I’d previously put together to create high-fidelity mocks of the filter and all its possible states.
Responsive design
Implementation
I worked directly with the developers to implement my designs, then helped QA before pushing to production.
