Background
In November, the Acquire team launched a brand new feature within the My Rightmove space that lets home-hunters organise their saved properties into different lists.
The new Property Lists feature gives home-hunters an easier way to consider a number of properties based on however they wish to group them; budget, location, property type, dream homes etc.
Being able to sort saved properties into various lists is one of the most common requests we receive from people, so we’re really excited to launch this new feature and give people yet another reason to create an account on Rightmove.
Part of the appeal of this feature is its simplicity. You need to come up with a name (plus an optional description) and then start adding any relevant properties you’ve saved to it. Rinse and repeat.
But it’s easy to forget that whilst something on a website you use might seem easy, in the background a huge amount of work has been undertaken by a variety of different people to make it possible.
Send in the reinforcements
We’re a relatively small team – a Product Owner, Product Designer, QA, two back end engineers and two front end engineers. For the duration of building the MVP, most of us were more or less 100% focused on this. For the best part of four months, the team transitioned from discovery and analysis to refinement and planning to coding, testing, a bit more coding, a bit more testing until eventually we were in production.
Once in production we were then inundated with a mixture of positive and negative feedback, the latter being what we focused on resolving within the following two weeks. We successfully managed to iron out most of the challenges users were facing before then returning to some of the corners we’d cut in order to get to market. The biggest win was replacing pagination with lazy loading, which by my count resolved three bugs and two usability issues (and was what our Product Designer had requested in the first place… oops).
It’s interesting throughout the process of delivering a feature like this how roles interchange from being fully focussed and up against it, to more reactive and less involved. However, two or three weeks from go live and everyone is fully in the mix pulling out the stops to get into production.
But we also needed various other disciplines to make this possible; Architects, Marketing, Analytics, Operations engineers, Database administrators, plus a variety of other product development teams whose services we needed to work in (more on this later). Involvement ranged from a few hours to a few weeks, but it’s important not to understate how critical roles outside your immediate team are when building a new feature/product.
It involved a lot of people from a variety of teams to enable our users to name a list and add their properties to it.
Inside and outside our comfort zone
Like any product development team, there are codebases and product concepts that we own outright, but also those that have a lot of overlap with other teams. Property Lists not only involved us working in services outside of our ownership but also in a new centralised library (called Kanso) that exists to serve all teams and is managed centrally.
Front end wise, the Property List pages were built in a Node application but much of the work was actually done in two libraries, which we then integrated into the Node service:
- Kanso – a base component library containing the simplest components like buttons, links and inputs using Rightmove’s styling
- Consumer-UI – a more complicated component library containing the reusable parts of My Rightmove such as widgets for displaying saved searches or saved properties
The idea here is to create reusable components that we and other teams can take advantage of whenever building something that shares a similar design pattern. The additional benefit of this, is any changes then only need to be made in one place, rather than each team having to manually go in and update their services (or worse, not doing anything and leaving users to navigate a website of inconsistencies and broken user flows).
From a back end perspective, we’re used to working in Oracle databases. Property Lists is underpinned by Couchbase, which is more flexible and scalable. However, we had little experience in this domain so part of our story involved a fair bit of knowledge transfer and upskilling… that’s not an easy space to navigate for an engineer when on the one hand they’re trying to align with the architectural strategy, and on the other deal with an impatient Product Owner who wants to know when we can start coding!
There are also several other principles to consider… GDPR data minimisation, application security, accessibility and automation testing. Rightmove is making great strides in these areas, but as the list of things to consider grows it makes getting a product to market all the more complicated. Each of these have their own requirements and own subject matter experts that you need to liaise with in order to ensure your product is fit for purpose.
So, there was the core feature we were trying to get out, in new technologies and adhering to a variety of principles. It’s quite a lot to think about so that users can name a list and add their properties to it…
Bartering on the final increment
At some point you’ve got to take the plunge and go live. From my experience it’s rare everyone is happy about it, which I always think is a positive because it demonstrates pride and care for what you’re building. But there is absolutely no point in spending an inordinate amount of time creating a 100% pixel perfect, feature rich product in a pristine code base if no-one is able to use it. And until you go live, you don’t really know what users will ultimately find valuable vs frustrating… so let them tell you!
The weeks leading up to going live can be stressful but are always enjoyable. It’s funny how it almost turns into a bit of lobbying process cross team. Product Designer will accept a success message being a bit clunky IF the Front End Engineer agrees to add a different loading state. Product Owner will agree to prioritising the different loading state if the Product Designer accepts replacing a dynamic component with a static banner. QA will accept the static banner if the PO agrees to prioritise missing CDC tests with the back end engineer. Back end engineer agrees to add the missing CDC tests on the condition they can update the application version at the same time.
That’s not meant to sound as conditional as it probably does, but the point is each discipline is balancing the principles that make up the core elements of their role whilst trying to get the main feature into production. What can we live with vs absolutely need to resolve before going live? Once we’re live, how quickly should we sort out X, Y and Z?
It’s never as simple as just turning something on… there is a lot to consider and negotiate so that users can name a list and add their properties to it…
There’s a lot involved in creating the beginning
Hopefully this post has gone someway to highlighting the amount of thought, care and work involved by a huge amount of people to get a seemingly simple feature into production. And this really is only the beginning of our Property Lists journey. In parallel to delivering this feature, there has been a lot of thought put in to what we want it to ultimately grow into. We’ll be spending some time raising awareness and increasing visibility of Property Lists as well as applying some technical love to areas we cut corners on in order to get to market.
After this, we will be looking to introduce the opportunity for people to create a list with more than one person, so together they can review properties and send leads.
Further improvements will be largely dependant on what our users tell us they want or need… but one thing is for sure, whatever we do it’ll involve a lot of people working together to create something as simple and easy to use as possible.
