Regardless of the origin, one of the pages most of Rightmove’s users land to is the the search results page. As GA told us the number of users dropping off when that page returned 0 results was over what we could expect it to be. In order to increase the retention of users at that stage we kickstarted a project that aimed at driving people to stay on the site and see more relevant results.
The balance between keeping a consistent language across the app and having visually recognisable sections was to bear mind.
As the designer in charge to deal with the project I was meant to understand the data with the BA of the project and work with the designated development team (formed by front-end and backend developers as well as a QA) to get to the right solution, as well as ensuring it corresponded to a vision on where our product was headed.
For this projects we didn’t have time to research or user test properly, at the same time we knew making an improvement was going to be easy, the tricky bit was doing it in the best possible way.
We gathered data with the help of the feature team to be able to understand what the behaviour of our users is when they get to ‘no results’. This way we got a list of most frequently taken actions. For example, apart from leaving the page, most users decide to change their search radius filters when they face no results.
In addition to the gathered data, we had previous research that told us more about our users mental models, like for example what criteria was usually flexible and what wasn’t when looking for a property.
After kicking off the project with the team and the involved people, were data and solution directions were shown, I headed off to ideate a few hypothesis that could solve the problem: from seeing if we could show straight away some extra related properties in that zero results page, to creating shortcuts for users to quickly amend their search and therefore get to see more relevant results.
Working collaboratively is great cause one gets to understand what ‘everybody’’s point of view looks like and how can it help. At the same time ideation takes place in all corners which could be beneficial for the product but, from a design point of view, communicating the pros and cons of solutions from both user and strategic points of views gets as interesting as challenging.
A good example here was that, it was of course easier to show results straight away to users so they never face the ‘no-results’ situation, as for example Gumtree does. But at the same time doing so may confuse the users or show results that were not relevant enough (specially if we consider that in our site people is looking mostly for properties to buy or rent mid-long term and therefore their filters are a bit less flexible that if you’re using Gumtree to find a toaster around North London).
After some iteration and get togethers with the team, we agreed to move on with a solution that would let the user take control of the next steps after no results, rather than trying to be too smart and make decisions on their behalf.
To not ovewhelm the screen (end of the day the message is still 'no results here') we limited the pods to show to 5-6, prioritising the filter amendments more likely to be flexible to our users)
We planned to release a few pods at the beginning and measuring engagement. Then we designed the rest and we used behaviour knowledge to establish a priority for them to be shown. Later analysis of engagement could tell us if the order we chose was the most efficient, and what parameters could make that priority vary.
Once the design components where finished, the design was provided to the developers using Zeplin and I did regular catchups with them to ensure they were not missing anything and neither was I.
Copy was provided separately using Airtable, this way, the design artefacts referenced the components’ visual and behavioural decisions while the copy’s source of truth remained separated, so updating it didn’t mean updating the designs.
Towards the end of the project, making sure the copy across pods was consistent in tone and structure was something to take care of.
Once we got a concept that was solid enough, we did a round of 6 user tests with real users to detect any possible problems and we planned how could we release it iteratively and test it from a quantitative point of view.
Once the two first pods were released, and we observed engagement with them, we released the rest of them. Although we already envisioned good results (there was no prompt for the users to amend their search before other than changing their filters manually) we were proud to observe that, when comparing monthly data, the exit rates from that page decreased an average of 30%.
Component-based modularity in the solution would allow us to use those pods to make suggestions on different points of the user’s journey in the future.