Rightmove, 2017

Maps search revamped

Understanding properties in the context of their location is key in property search. Our current solution for maps search wasn’t responsive, so our mobile users (which represented around 60% of our traffic at the time) could not benefit from the feature. At the same time two other things happened: a code refactoring of the tool was needed and a new data set for location data came into play. With all this ingredients in place we saw the opportunity to deliver a better experience on maps at Rightmove across platforms.

My role

As part of the design team, working altogether with people from the development team, me and my colleague Daniel Munday, were responsible for the needed research (requirements and data gathering), conceptualisation, testing and final design of the product. I focused specially on the conceptualisation and final design phases while giving a hand on the other ones.

Understanding the problem

Although the main problem was getting Maps to be available on mobile devices, we still had to check the current data, traffic and exit points. But also, we needed see what were our (potential) users expectations of a map when trying to find a property.

For that we organised a round of user testing that involved 5 users externally recruited and who would be varied in age and gender but would all be on the process of looking for a place to buy or rent. We tested our current solution to see what problems existed as well as competition map products that could help us understand what kind of behaviours may work and which ones wouldn’t.

Image from one of our testings. We grouped all the points per topic to later on summarise main insights.

In addition, understanding what the limitation of the current technology and its dependencies meant as well as what opportunities Elastic Search was going to bring us was something we had to keep an eye on.

Designing & protoyping

We worked in a small core team of 4 people (two developers and and two designers) and that allowed us to move fast and iteratively. Hence, meanwhile at design we were dealing with understanding the issues and conceptualising solutions, development was taking a chance testing the new technology and prototyping our first concepts and ideas to ensure viability.

From a early stage, then, we worked with real-data and real-code prototypes that allowed us to keep or discard solutions much easily than if we used prototyping tools (the interaction complexity on maps is not something that could be easily tested using Invision, Flinto, Principle or similars).

On our side, we were building sketches on whiteboard or paper (involving mostly me and Daniel, the other UX designer, but also the developers in some cases) while parallelly exploring visualisations and flows over Sketch.

Design challenges

One of the main headaches we faced was showing multiples properties in the same exact location. When testing we saw that showing numbers in pins could be interpreted in very different ways (relevance, bedrooms, etc.) so we had to work out how to represent this using a different pin.

Density was another interesting one. From a technical point of view, showing more than 300 pins was not possible, so we experimented on how to show density maps both conceptually and development-wise.

To these ones we have to add the space problem when facing a map application on a mobile device as well as the theme of navigation interactions: from the rest of the site to maps and vice versa but also within the maps tool itself.

Handing off

After iterating the designs with the insights from the user testing and internal design discussions I refined the design and put into view all the different states of it for the different viewports and devices.

Some of the modules and scenarios we designed for in the maps project. We aimed to get an experience as similar as possible in all devices, despite that we made a concious decision of designing a specific navigation for touch devices, different from the desktop one.

With the aim of having our design system as modular as possible, it was important for the ‘property cards’ that we were showing on the map to not differ too much from the ones in search results and other instances of the same module, despite their smaller size.

The designs then were exported into Zeplin for developers to work on the final bits of the refining code.

Validating & impact

Once we had a concept we thought was usable enough we organised another round of user testing recruiting 10 more people in their process of looking for a property to rent or buy. The script aimed to see if they could go through the basic flows within the concept we had put together.

After release we also considered how to get qualitative and quantitative feedback. We know that when changing products and features that have been adopted by many users during extended periods of time there is going to be a notable rejection. Therefore it was important to understand what people thought about the new Maps.

So we came up with a feedback bar that allowed us to get both positive and negative quantitative inputs while being able to get some users to give us a more qualitative feedback. That’s more important than what it seems, since we know that people tend to engage more with giving feedback when there’s something to complain about, while positive feedback stays unspoken.

The graph shows feedback received in a month time after release. One one side feedback of people that completed the survey that followed, in the other feedback of users who dropped off the survey.

In terms of usage, we observed a very positive increase of about x8 of unique views. Part of it expected since mobile users didn’t have the option before. Bounce rates where also significantly reduced.

If you want to know more about the project, Daniel and myself wrote this Medium article you may find interesting.

See it live

← Back to case studies