Bark's Mobile Header & Map Tab Redesign
November 2024
Project context
Bark’s mobile app for professionals allows users to purchase customer leads to turn into clients. (For example, a professional graphic designer or an electrician may use the app to purchase potential clients who need print materials designed, or help with a kitchen renovation.)
Users can shop for these leads in the Bark app in two primary views: a list view and a map view.
When I worked on this project, the map view of leads was one of the newest features rolled out in the app, and usage was being monitored to understand impact on converting browsing activity into lead purchases.
The team
Direct: The mobile app team (Product lead / manager, front-end dev, QA dev, backend dev), Insights partner and 1 designer (me);
Informed: CPO, Head of Product, Head of Design
My role
Senior Product Designer
The problem
In monitoring map usage, we noticed that users who used the map in their browsing process were leading to a higher purchase rate, which correlated to higher revenue. This was a good sign, however…
In working with our Insights partners, we were able to segment a large group of users who were viewing the map in sessions, but failing to ultimately purchase leads viewed on the map.
This meant map users were successfully finding more leads to purchase (great!) but that there was also a large population of users who weren’t using the map (not… so great).
The data couldn’t tell us why this behaviour was happening, so I advocated for conducting a few day’s of qualitative research on the following target population:
Target user: the 33% of professional app mobile users who were viewing the map, but not buying anything from it.
Research conducted
I started by launching an in-product survey that afternoon asking app users for simple feedback on their experience using the map, and asked if they would be comfortable with someone following up with them to chat more.
By the next morning, I had hundreds of users who I could segment into self-identifying map and non-map users, and who I knew were open to being contacted for a quick follow-up chat. For users who participated in my survey, I was able to verify their actual usage patterns in Heap and confirm their survey answers to be accurate.
I segmented out users who:
1) Answered Other, I don’t use the lead map, and Viewing Potential leads but not buying
2) Had actual behaviour patterns in Heap that matched these answers
3) Had responded “Yes” to being open to a quick follow-up
This led me to conduct 10 phone interviews with customers who weren’t currently power map users and gathered more color to add to the team investigation of what was happening.
What I learned
Customers were seeing the map tab and the list tab as two separate tools (and not necessarily as 2 different views of the same content).
"I thought that leads displaying on the map were somehow more relevant to my location."
Many customers were coming into the app via notifications of new leads, which bring them straight to the lead details and leads list screens (where they purchase)
"I really cherry-pick leads based on the location and always check a lead's location before I purchase."
A larger theme emerged in almost all of the conversations that the map wasn’t already part of users’ habit formation and workflow
"I just take the post code and copy paste it into Google Maps as it is right now."
Opportunities
Every person we spoke to found value in the map and seeing the lead’s location. Location is a leading qualifier before making a purchase for most of our users, and these conversations once again confirmed lead location is a high value piece of information when considering a purchase.
It was also becoming clear that customers were already using the map, or using another map tool like Google Maps—we just needed to do a better job of placing the map as part of their workflow.
ABOVE
I documented the customer research calls I had in a Miro board for the team and stakeholders to look together. I paired the qualitative insights I was hearing with some usage data to tell a more complete story, and distilled key problems and opportunities from each conversation.
Proposed solution
Considering many users were struggling to connect the list view with the map view, and there was a lack of awareness that the two tabs were the same content in different form, I proposed the solution of merging the tabs into one and designing a way to toggle the view back and forth.
1) Building a new header that is the same across both tabs
2) Testing a variant that merged both tabs into one tab, and featured a toggle CTA to go back and forth between the two tabs
Hypothesis
I was lucky on this project to collaborate with a lead product manager who is an amazing thought partner when defining scope. Based on the data on current CTRs from filters, what customers had been telling us about their discovery issues, our shared hypothesis came together as:
Adding additional filters and sorting to the index page will increase CTR to artifacts
Helping users find what they are looking for faster in their moment of discovery leads to improved retention
Understanding marketplace patterns
From there, we moved into the design phase and I looked at a few existing design patterns from across products like AirBnB, Zillow, and Rightmove to understand how products were treating this map/list view swap. I needed to confirm what major patterns users were already experiencing (and expecting) based on standard industry design patterns.
All of the competitive research I looked at confirmed two things:
A single-tab approach was fairly common to encounter in a marketplace mobile app and a standard design pattern
The complexities after that varied greatly. For example, AirBnB’s swiping and disappearing map view is incredibly unique, whereas Rightmove’s more simple toggle button simple switched list <> map views around
Exploring through 5 iterations
I went through multiple iterations on this, and narrowed it down to five primary directions we could go to present to the design team, CPO, and my immediate team:
- Mr Boring option
Small changes to increase space option
Airbnb option
Wanna wanna? (Which actually turned out not to be the winner)
Last but not least
An exercise that got my wheels spinning and helped orient myself with all the elements we were considering changing was to take a few passes at grouping all the pieces of our current header.
Data-informed design
As part of the design decision making process, I went on a hunt for some data to inform some of my bigger decisions/ assumptions. Some of the questions I needed answers to were things like:
- What of the 66% that see a lead in the map, and buy from the list, are buying the exact same lead? How many of those then proceed to buy a lead outside
How were users currently using the header, and which parts of it were they using with high frequency? (Sorting, filter, lead settings etc)
Could we afford to make changes to how this current design functioned without hurting current usage?
Lead Settings
We know traffic to lead settings is low (4% of users click it each day)
We know users don’t set lead settings once they’ve applied filters (only around 100 users do this a day)
We know all ages of users do use the lead settings CTA (50/50 split)
Sorting
We know sorting is a low engagement repeat action
Users “set it and forget it” and isn’t a high-priority action during each new session
I placed this data summary in my design file to speak to whenever stakeholders were viewing the designs.
The experiment we launched
We started to iterate into a direction we felt good about. A big consideration was an internal push to re-organize the global side-nav in the product, and so this felt like the perfect time to pivot away from our existing right-nav filters and consolidate our entire new filtering & sorting experience at the top of the screen.
Experiment results and roll out
The experiment is currently in progress as of November 2024. I will be updating and finishing this case study when we have more concrete results to share.
Impact & Next Steps
Coming soon!
Reflection
Small changes can lead to big impact. Data doesn’t tell the whole story. Sometimes you really need to have real conversations with customers in an investigative way in order to understand what the data is telling you. In this case, the data led us down a path that we had to investigate with qual, and then apply to the data.
I’m excited for when we have the quantitative data from our A/B test, and a full month of insights to learn from.