How we built our new search applying Jobs-To-Be-Done
Find the original post here
Uniplaces is building the most beautiful way of living your student experience. This is a lofty and wide-scoped goal so we started by rethinking how you find and book your new home, challenging the decades-old sucky experience of classified ads portals and scammy forums. Needless to say this is a big challenge as moving abroad means “leaving” your family, friends and loved ones. Adding on top of this, as the majority of the audience is experiencing this rollercoaster of emotions for the first time in their lives, the word “responsibility” gets a whole new meaning.
At our company the product organisation is quite new (comparing to the company’s lifetime), so we are always trying new ways of understanding what to build and how to do it. Many startups have been applying the “jobs-to-be-done framework” (JTBD), and job stories seemed the perfect challenge for our next feature. When dug into data and feedback from our users and team, we realised we needed to completely re-think search.
Uniplaces’ job story (“solve all student needs so that they feel safe and enjoy their experience”) is too broad to build on an agile environment, so we narrowed it to “When I am moving abroad, I want to find the right place so I can feel at home”. “Find” is key here: to get us to be “hired”, we needed the search experience to be flawless, easy and fit the user’s preferred way of finding something. Our previous design of the search page was quite simple but it taught us quite a lot about our users.
So what did we build?
Micro-jobs — 3 shades of search
By learning how our users were searching for homes, we actually found 3 different behaviours that seemed like individual jobs: the first one is “When I am searching, I want to use the map so I can connect prices with locations”; we see this as a user hiring the map. The second one is along the lines “When I am searching, I want to filter down so I don’t lose time”; here the user is hiring the filters. The third and final one is “When I am searching, I want to see everything so that I select what seems to fit”; here the user is hiring the information in our listing cards and our algorithmic sorting. Uniplaces isn’t the only one being hired for a job, Uniplaces’ search is also being hired and it has at least 3 “customers” to please.
1. Building for user hiring the map
Map-driven users cared mostly about map navigation and information to tailor their potential choices. They relied on the map feedback to select rooms and houses that could fit what they were looking for.
In real estate tech generally 2 things matter: price and location, but when you never rented nor lived abroad, you have no idea what to pay or where to live. To turn this around we added pricing to our map pins (a common practice), and added secondary aggregate pins spread across the entire city. These decisions allowed a map navigation to 1) offer pricing clusters and city distribution (so you focus in the areas that fit your budget), 2) show the power of supply and reach of what Uniplaces has to offer, and 3) make it easy to navigate from area to area, highlighting our recommended offers ahead of all options.
2. Building for a user hiring the filters
Filters-driven users preferred to zoom out at city level and customise filters to their exact needs. Their search was binary: “either you have the offers (and the filters) I want or I am off.”
People’s brains lean towards finding shortcuts to fasten decisions. Filters are shortcuts and we were looking for the fastest path to output what our users wanted. Applying the Pareto principle we learnt that 80% of room search applies the path “Where > When > What > How much”, so we built a one lane design following this structure. It helped save screen estate, keeps the user on the behaviour and it guides towards the advanced option (which previously was rather hidden).
Advanced filters were also revamped: most marketplaces suffer from low supply utilisation rate (i.e. a large majority of users tend to check a small percentage of supply). To disperse and grow this metric we made advanced filters more clear, added suitability options targeting each person’s specific profile (erasmus, professional, etc) and finally added this option in mobile, previously non-existent.
3. Building for a user hiring the “popular”
Finally some users default everything and prefer scrolling through our “popular” ranking and open something that fits. To assess they relied on what the search cards showed, photos and prices.
These users are the hardest to please: since we knew little about their preferences we still needed to offer a “healthy” experience. Digging into data from our “default” users we realised they were seeing around 50 different options before converting, and a single search visit would lead to open around 20 different options. Our users told us this happened because we didn’t show enough information on the search card! We decided to add to the container key snippets like neighbourhood, star rating, property type, floor plan or video, bills information, made the verification mark clearer, added more characters to the title and the rebuilt the mobile photo navigation.
Every tweak aimed at improving “passive understanding”, in other words making a user decide, from search, if it’s worth actively opening a specific listing. If we can reduce offers seen from 50 to 25 we might halve time to purchase. This is even more important for users not using a filter or a location search.
Did it work?
Measuring success was central to rebuilding this feature. Although we track the ordinary metrics like conversion rates, bounce rates and in-page NPS, these suffer heavily from seasonality and we wanted to single out metrics tied to the feature. We decided to seek a “healthy” search experience and, based on historical converting data, rounded at reducing searches with less than 10 results and mitigate zero results searches, while increasing the number of times users got over 20 different results.
Our data team works side by side with product to closely measure impact, and for this exercise we used a sample of searches and our internal R package called UniplaceR to move, clean and prepare the raw data, as well as share analysis and results. To reduce unpredictability and deviation we excluded searches without explicit user input. Finally we applied a smoother based on the generalised additive model method (GAM).
We launched in mid July, and after a couple of weeks of testing here are the main results in comparison to a sample from March to June.
In terms of our “unhealthy” experiences we noticed a significant drop, reducing searches with less than 10 results by 44.89% (~27% from ~49% of searches) and searches with zero results by 42.9% (~8% from ~14% of searches). We also drove down the standard deviation, key to provide a more consistent experience and help us learn faster and iterate with more confidence.
The best part of this was the compound effect of also improving the “healthy” experiences. We saw an amazing increase of 45.46% of searches outputting more than 20 results without re-arranging our algorithm (64% from 44% of searches). The fact that, for the first time, more than 50% of experiences with our search are “healthy” will have a deep impact on conversion and NPS.
Conclusion
This was the first time we tried to follow JTBD framework, beginning to end, across product, design and engineering. It forced us to look differently at features: not by their specs or designs, but rather by preferred interaction to solve a problem. It made us gravitate basically around the users’ behaviour when hiring the product instead of our assumed scope. In the end, users gained the most and Uniplaces moved one step closer to “solving all student needs so that they feel safe and enjoy their experience”.
