Optimizing the address collection for new partners

interaction designvisual designusability testprototypea/b testing

The problem

When signing up a new property onto Booking.com, the partner needs to go through a few steps to complete the process. During an analysis of the sign-up funnel, we discovered that some users were having issues when filling in their property address.

As you can see in this Hotjar recording below, our users were having trouble understanding the 'Full address' field, preventing them from getting to the next step of the registration process.

Here are some quotes we received from the user testing session:

"I don't know the difference between full address and the fields below"

"I didn't know I had to select the address from the list"

A quick iteration

My next step was to sit down with my team, go through the research, and explain the findings. Together we decided that removing the 'Full address' field could be a quick win and that it was worth trying.

  • Image of the interface version without the full address field

Interestingly enough, in our A/B testing, the new version improved the conversion rate of that page by 4.8%, which was a significant difference considering that 30.000 users sign up daily. Unfortunately, it also decreased a metric called "Address Found by Google" by 12.4%. This basically means the Google Maps API was less effective at finding specific addresses. This was a fundamental metric for us since it can affect a few things:

General guest experience – if Google Maps can't find the address then it wouldn't show the pinpoint in the right place for travelers, generating the need for more customer service

Risk & Legal – both of these teams use the map location to verify that the property is legit and to generate contracts. If the information is not clear or correct it can take a long time for the property to be listed.

Team brainstorm and ideation session

After the results of our first experiment, I scheduled another session with my team where we discussed the outcome and what could be our next steps. We had an ideation session where everyone sketched and discussed ideas.

Involving the team members in this type of exercise proved to be super helpful. I was able to get feedback and alignment with business and development and avoid surprises in the future.

  • Image of the team sketches

Rapid prototype

As we had a pretty well-defined design system in place, it was really quick for me to start converting our sketches into a high fidelity prototype.

Our main approach was to create a simpler interface that gradually reveals the information. It starts with only one field labeled "Find your address" and as the user begins typing a list appears with the autocomplete suggestions.

When the user clicks on one of the items, a block shows up with the address and the option to edit or add more information.

If Google Maps can't find the address, an option to manually add the address shows up, and the user can manually input all the fields.

  • Image of the rapid prototype ui
  • Image of the rapid prototype ui
  • Image of the rapid prototype ui
  • Image of the rapid prototype ui

Making it work

After designing the necessary screens, I quickly created the prototype on Invision using Craft, and we were ready to collect some feedback.

  • Image of the Invision prototype

User testing

With the prototype finished and working, I went to usertesting.com to set up our test. We already had a target audience and screener questions ready from previous research, which made things easier, so I only had to set up the test plan.

We tested the prototype with 8 people, and everything went quite well. Everyone understood how to proceed and were able to quickly finish the task. All the testers gave 5/5 for easy to use. We were ready to start implementing.

Implementing the new solution

Since we were a small team sitting close to each other, it was really easy for me to keep collaborating with the developers during the implementation phase. Some details can be surprisingly more complicated to implement, and great communication between design and development during this phase is essential for a good outcome.

Testing against base

After a few bug bash sessions, we started our A/B experiment, and the results were quite interesting. The overall page conversion increased by 3.1%. Also, the "Address Found by Google" metric increased by 32.2%, which was a massive win for the team. With improvement in these two main metrics, we considered the experiment successful and we felt comfortable making this the new base version

Final thoughts

I really tried to push team collaboration during the whole process, and I was thrilled with the results. The sessions involving the team helped us all to better understand the user pain points, create more empathy for the user, and a better sense of ownership

However, I'd try to go a little more in detail with the devs next time. It wasn't clear that we would have to create our own autocomplete interface instead of using Google's default (important to manually input the data), which delayed the process a bit. Lesson learned.