Hello Medium! We’re Daniel and Oriol from the design team at Rightmove in London. In case you haven’t heard of Rightmove, it’s a property website that helps people find places to buy or rent. Most people don’t realise just how much traffic we get, or how popular the site is — at the time of writing, SimilarWeb puts Rightmove in the top 25 of all sites visited in the UK.

Over the last 2 years, we’ve been working with our product development team to revamp our on-site experience. We started with the main search results page, and have been working through the other interconnected parts that make up the main user journey. Due to typical things like scale, time, and prioritisation, some bits of that main flow have been left for later, one of those being our on-site map page.

That’s where this article comes in, as we thought we’d like to share a little bit about the process, and some of the more interesting things that we learned, now we’ve just finished the first phase of the project. This our first attempt at this kind of thing here on Medium, so please feel free to let us know your thoughts or feedback!

Intro and process

One of the first decisions made back at the beginning of the project was to ideate and user test with real code. Most of the time prototyping software (like Flinto, Principle, Axure, etc…) are the right thing for the job, but in this case making the map feel as realistic as possible was key, be this through interactions, actual data, and placement within our typical flow. All of these add up to something that’s really difficult to get just right.

For instance, designing the behaviours and interactions in a prototyping tool would have been extremely fiddly, and especially time consuming to get just right. In terms of property data, we wanted to make sure that users were interacting with live properties in the locations they’re actually looking to buy or rent in, all wrapped within the flow that they use day in, day out.

We wanted to avoid our users wasting effort processing irrelevant data we’ve hard coded, or getting too hung up on how the map doesn’t behave exactly right. Instead, it makes more sense to help them focus on using the map to explore as they would do if they were sat at home. This way we get past the feedback we already know, and jump straight to the stuff we don’t.

Fortunately, we were able to work closely with Alex and Kintesh, two of our front-end developers, which allowed us to be able to develop a quick-and-dirty version of the map pag that we could use to validate our base hypotheses with users, and then go on to refine it through several iterations.

Throughout the process, being able to collaborate and work so closely was key in helping us to conceptualise and quickly bring ideas to life, taking them further than we would otherwise.

Getting it working

Mobile first

It’s no secret that browsing the Internet on mobile has overtaken desktop, so the fact our map wasn’t available on mobile was a problem.

We knew that designing a map for small screens would be easy enough, but making that small screen experience equally as good as a large screen one was going to be a challenge — something which was voiced as a concern during initial discussions with people around the company.

From early on, it was clear that for our needs at least, making the same solution work across all devices was going to be problematic, as we were finding decisions we made on one screen size, impacted those on another.

Having spoken to users, we identified that the usage of maps on mobile was likely to be short, sharp bursts. Whereas, other devices tended to be more leisurely, and in-depth, which gave us the basis we needed to make two similar, yet different experiences, tailored to how we understood people were using maps on those devices.

To do this, we broke the map up into its core components, starting with ones that would be across all devices / viewports, such as pins, and property cards, focusing on what could be reused as much as possible. Once the barebones were in place, we looked at adding bespoke components to add richness to the experience on that particular device.


When we asked our users what they thought was a good ‘maps’ experience was, the answer was almost universally Google Maps. Whilst this isn’t surprising, we also noticed that the people we spoke to felt anything that didn’t use Google was inferior, and seemed more unreliable.

Additionally, we also observed that wherever a user sees a map using Google, you automatically inherit all of their expectations and limitations. For instance, when we changed the visuals of map, to try and take it away from the standard Google Map style, we found that the general response was perceivably lower. We wanted to use a custom map style (like Snazzy Maps, or Google’s own ‘Styling Wizard’) but having implemented one of these styles, we observed users were far more hesitant when using the map, as it no longer looked like Google’s. This breach caused users to question their ability to trust the accuracy of the map, and also the quality of what we were showing them — something that’s difficult to sacrifice when people are making such an important decision.

Our slightly modified Google Maps style

This highlighted the importance of making sure the user knew they were using a Google Map. Whilst this could be seen as limiting, inheriting the users expectations pre-defined a lot of the interactions, which allowed us to focus time on designing for the bigger, unique problems that are more related to this particular use case.

Minimising UI

With current web trends, we wanted the map to be displayed across as much of the screen as possible. On larger screens this wasn’t an issue, but we found that at some of the smaller mobile breakpoints there just wasn’t the space to comfortably show the map and our pre-existing site UI. Something had to give, so this created an interesting in-house issue that gained quite a bit of resistance when we proposed removing most of the unnecessary UI elements, in order to open the map on mobile.

The general concerns we got were either that users might think they’ve left the site, or would some how get lost, and not know where they were (one of the bits we wanted to remove was the site header). Whilst we recognised there was some potential for this to happen, we were confident that by helping the user along the journey, and showing them clear ways to enter and exit the map, there wouldn’t be any issues.

Naturally, this was something that users could settle in the interim before going live. When we tested it, we were pleased to find minimal issues to users being able to enter and exit the map, which helped us justify our case, and helping us to confidently proceed with this approach.

Dealing with data

Working with clustering

Traditionally, a pin on a map represents a singular thing. However, we have the scenario where multiple properties can be listed at the exact same location. In some cases, there could be hundreds of properties at the same location, if they’re newly built for instance. The previous map did a really bad job at making it clear whether the pin represented a single property, or several at the same location. If there were multiple properties, the UI to browse through them wasn’t much better. So, these were two things we wanted to fix; firstly to make it clearer if the user was seeing more than one property at a specific point on the map, and secondly, to make the properties easier to digest, and browse through in such scenarios.

Next, were the amount of properties we need to plot on the map. There’s two factors at play here. Firstly, if someone really wanted to, they could search for all the properties for sale in London. If they didn’t apply any filters this would yield just shy of 50,000 results. Obviously, this is a bit of an edge case, but shows how much data we’re potentially dealing with.

Even if our users could process this amount of data, most devices would struggle, meaning we were limited in terms of what we were able to show on screen at once. As the previous map was running on older technology, we wanted to increase the limit on results shown at once, but in use cases like the London example, this still wouldn’t help that much, as users would only be seeing a small subset of everything available — something our previous map also didn’t do a very good job of making clear.

Initially we thought that clustering would be the solution to each of these problems.

We’re sure that everyone reading this article will know, or have experienced map clustering at some point when browsing online, or designing stuff. Just in case you’re not, here’s an example of what we’re talking about.

Out-the-box clustering in Google Maps

What we found surprised us. Whilst clustering is a fairly ubiquitous feature, people just don’t get it.

This wasn’t a one off either. It was the same every time we tested it; from the first phase of testing, where we looked at existing sites already using the pattern and later on, when we were building the product. Every time, we observed that users find clusters difficult to understand, and keep track of as they divide and split each time the user zooms into the map, or drills down into the results.

This isn’t to say that clustering doesn’t have its place in certain applications, but in this scenario where it needed to work with properties, we found the use of numbers added more confusion, with these being mistaken for things related to the property, like number of bedrooms, or even some form of a order / ranking.

This put us in a difficult position, as we were hopeful we could rely on an existing pattern to lighten the load cognitively for the user, and make the data more manageable, but as we weren’t confident enough people understood it, we decided to explore something a bit more unconventional to try and solve the problem.


We ended up calling this “density mapping.” The theory was that we were able to split the geometry of the region the user is searching into a grid, and then work out how many properties are within each intersection of that grid. For example, Zone 1 in London, might look something like this:

London’s Zone 1 split into segments.

The idea here is that user we wouldn’t show the user any pins plotted on the map, as we initially wondered if the confusion with clustering stemmed from us showing a mix of ‘normal’ pins, with ‘clustered’ ones. Technically speaking, requesting large numbers of property pins, and plotting these on the map is quite intensive too. So, instead we tried displaying a series of shaded segments, and numbers showing how many results are that segment of the grid, which was easily available from the back end. The user could then zoom into a particular section of the map, until the number properties shown in their viewport matches our capped limit, and then we load the pins for that segment of the map.

Alex prototyped this idea, and together we refined it down so we could put it in front of some of our users. We started off by not showing the numbers on the nodes, as these had been confusing when we tested the clusters. However, this only abstracted things even more, with most users unable to guess what they meant. One user in particular mistook the nodes for a visualisation where people were commuting into London from. After this, we added numbers back in, refined a few bits and pieces, then re-tested the concept with a new group of users, which generally seemed to help. However, what we ended up with felt like a glorified version of clustering, which we’d already found didn’t work, which is probably why this approach didn’t seem to gel with users.

During our user test sessions, we frequently noticed that participants just wanted to see properties on a map, with nothing getting in their way, and their dislike of this approach was something else to back up that observation. In the end, we came to the conclusion that displaying properties like this is just an additional barrier we’d imposed to solve our problem, yet offered little value to the user. As it needed more time than we realistically had to be able explore this further, we ended up putting the idea on hold.

How we solved it

In order to solve the issues we’ve discussed in this article so far, we needed to design a few things to address the solutions.

Firstly, we implemented an on-screen message to tell the user that they’re not seeing everything on screen right now. We made sure this was in a prominent section of the screen, but didn’t get in their way when looking for properties. Each time the user zooms in, the number of properties they aren’t seeing is updated. When the user reaches a zoom level where we can show all the properties at once, we just remove the message.

To minimise the perceived amount of properties on the map, we did two more things. We started by designing a new pin that lets the user know when a two or more properties exist at the same location. Designing this pin to make sense was really difficult, and took several iterations to get to a stage we were happy with, and were confident made sense to users. The other aspect was defining what defined a singular pin from a multiple pin. To do this, we looked at the locations of the properties on the map, and calculated the distance between them. This took quite a bit of fine tuning, but the result is that properties that are roughly in the same area should be combined, and plotted together.

Viewing these properties is also slightly different depending on device. On mobile, we wanted to let the user view everything quickly, and in one place, so opted for an ‘infinite’ filmstrip of properties, whereas, the larger devices can take advantage of the extra space, feeling a bit more exploratory and relaxed.

Here, as soon as the user interacts with one of the multiple pins, they’re shown an interstitial state that lets them know there’s more than just one listing here. The benefit of this is that we don’t give undue prominence to any one property over another, instead handing this decision to the user.

How did it go?

The launch

We scaled our launch, going live to 100% of users a few weeks ago. Along with it, we attached a small feedback bar with a thumbs up / down button so users could quickly tell us whether they liked it or not. The idea was to get a basic, high level feel of the sentiment based on clickthrough rates of the positive / negative buttons.

Each of these buttons linked to a survey, which is slightly tailored towards whether the response was positive or negative.

What our users said

From initial launch a few weeks back up until the time of writing, we’ve had in excess of 11,000 written responses. Initially, the sentiment was balanced between positive and negative, however, as more have come in, we’ve seen a distinct shift towards positive responses.

A quick look at unique visitors to the survey (people who we assumed clicked through but didn’t give feedback) using our analytics tool, showed 50,700 positive click throughs versus 16,697 negative ones (both figures accurate at time of writing.)

It’s fair to say that sometimes users don’t always embrace change, so a response like this is a really positive, and we were really pleased to know that what we’ve designed has been well received by a good proportion of our users.

There’s already lots to fix and improve, but out main next task is to sift through as much of this valuable insight as possible to help guide the next phase of the project If you’re interested in seeing the finished product, here’s a link where you can give it a try.

Thanks for reading, and please leave any comments or feedback below!

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store