Designing a new Search
How User Research helped us redesign this feature
Good time for ch-ch-ch-changes…!👩🎤
Having recently raised series B, opened some new cities in Europe and launched several amazing marketing campaigns to increase brand awareness it was time for us Product Designers at Badi to revisit one of the main sections of our platform: the Search feature. Here is where users looking for a room to rent–we’ll call these Seekers, enter the location they wish to live in and apply filters to find an accommodation of their choice. We had gone through a soft rebranding the year before, but no substantial changes were made to the flow or the UI structure.
We had a lot of freedom to experiment and try new stuff but, with our first Design System under construction, we had to be wary and choose our new components wisely, scalability was our motto and common consensus was our ally.
The Design Process
CX Feedback and User Interviews
All squad members in our team–and specially Product Designers, make a constant effort to work closely with the Customer Experience Team to make sure we work with up-to-date user feedback. It’s really easy to start making assumptions when you lose sight of the real people using your app everyday and we certainly had learned from past mistakes.
Of course, being aligned with customer feedback isn’t the only requirement in a project like this and it must be taken with a grain of salt, business strategic decisions are also at play and it’s our responsibility as Designers to advocate for the user and at the same time build a viable product.
Besides the feedback provided by CX we also reviewed our latest NPS Survey results and carried out several user interviews with active Seekers (at the office and remotely) to better understand how and when they interacted with the Search tool, we also asked some of them to perform a search in situ for a more accurate assessment.
Once we gathered enough information it was time to step back and focus on the most popular pain points in the Seeker’s journey and make an estimation of the impact their solutions would have and the effort they would take. Many of the top complaints were well-known to us, but hadn’t been tackled because of time and technical constraints or simply because they were out of scope. Now it was the time to decide which improvements made more sense to include in our roadmap.
Prototyping and testing
For this project we had the chance to work along with Barcelona-based agency Interactius for user research and usability testing. We started by developing an early Invision prototype that they would later put to the test in their usability lab. This prototype attempted to cover most pain-points from our previous research and also to provide some UI improvements. We started by defining the main areas of interest we wanted to validate, how this prototype would help us in doing so and how its limitations could constrain the test. The user profiles eligible for the test were discussed along with the agency and recruited by our CX Team and Interactius.
There were three main changes we introduced in this prototype: displaying better visual feedback for active filters, new info shown on the room card and the concept of quick search–only containing monthly budget and availability, which comes from the idea of having a better filter hierarchy, with the most important or frequently used being more handy and the ones we considered complementary more hidden in the filters screen. The sorting option, originally at the bottom of the filters screen, was also moved to the top bar to be more handy.
Overall we wanted to test the usability of our new Search, specially focusing on:
- Validating whether our primary/highlighted filters were actually the most relevant to our users and that they understood the concept of quick and advanced search.
- Making sure users understood what each filter was about–the wording, what they expected them to do etc.
- The discoverability of each filter
There was an important downside to testing this feature with this kind of prototype, though. Filtering and sorting results is a dynamic action that in order to emulate, multiple screens with all possible use cases had to be designed and linked correspondently, which was a huge effort for Design. Later on we came to the conclusion that this kind of advanced usability tests made more sense to be run with a real working prototype, like a build in its pre-launching QA phase.
The Usability Lab
The day of the test, we provided the agency with a few devices with the prototype installed. The interviewer asked some questions relevant to their experience in Badi and other real estate or flat-sharing platforms, their motivations and goals as Seekers etc. We listened and took notes from the other side of the one-way mirror. When the interview was over participants were invited to test the prototype after a few given use cases. All interviews were recorder for a final report.
It was really amusing watching participants interact with the prototype and seeing how some of our assumptions were immediately validated and others completely debunked. It was fun giving closure to long-time inside battles by just letting users speak.
I won’t go into the details of each step in the testing process because that would be too long and deserves an entire different article of its own, but what was most significant to me was the fact that we could start iterating right away just by observing users interact with the prototype. For example, we observed that our bet on the quick search wasn’t that obvious for users, who tended to look for more filters in the quick search itself instead of the Filters button, so we decided to move the quick search module to the Home screen–the previous step to the Search screen. We also realised that the sorting option was better off inside the filters screen (but this time at the top instead of the bottom–for better discoverability) because the space on the top bar was too precious and could be used for a better display of filters.
Speeding things up was one of the main goals of including testing in the design process, so here we were, armed with new feedback and observations on usability, ready to go back to the office and start iterating again.
First iteration: map improvements and filter consistency
Map improvements were the second most popular complaint, accompanied by suggestions such as drawing an area of interest (out of scope at the moment) and filtering by neighborhoods (using the Google Maps API turned up to be quite inaccurate in certain areas if not made custom). These were not exactly quick wins, so we thought of other ways to improve the map until we could go back to these ideas.
From our user interviews we observed that many Seekers –specially those who had a rough idea of where they wanted to live, jumped straight into the map view (I’m too lazy to browse one by one on the list view), so they could browse listings just relying on location and price (shown on the price tag of the room). This led us to believe that a wider map area to move around with fewer elements would be less distracting and result in a more engaging experience for Seekers who don’t feel like scrolling endlessly through a list of cards. The top bar, previously used for list/map tabs could also be put to better use, we changed the tabs for a toggle button on the top right corner and used the bar to show the filter tags. We also improved the interaction by only showing the room cards (which used to be fixed at the bottom of the screen) when a price tag is selected and hiding them back by tapping anywhere on the map–also collapsing the top filter bar if they tapped again (See gif below)
Another improvement was changing the automatic results update as you move on the map for a button that gives you the choice to do that, this lowers data consumption, improves performance and also makes losing sight of a room by accident less likely.
In terms of usability and discoverability we never had specific complaints about filters, but we knew there was room for improvement. On both app and web there wasn’t evident feedback when filters were active nor visual information for the ones selected. After the necessary research and benchmarking we came up with this solution for apps:
In the new design there was better visual feedback when filters were active, and all selected filters were displayed on the top bar like tags, these could also be easily reset by simply clicking the ‘close’ icon on each filter tag, so if you felt like removing some filters to broaden up your search you didn’t have to go back into the filters screen and deselect them one by one. We took advantage of the horizontal scroll to show the ‘Save search button’ at the end instead of showing it as a floating action separated from filters.
It was clear to all of us that, even if we are undeniably mobile-first, consistency had to be maintained across all platforms, so adding missing filters on web was a no-brainer. These included the type of listed space (private or shared room, entire apartment…), the maximum number of flatmates living in the property and the length of stay. We also added the option to filter by the gender of flatmates (e.g. I want to live with girls only), also long requested.
For web, we observed the convention among the most popular real estate sites was still the top bar with custom drop-down filters. For this reason, even if we were adding more filters that would make the commands a bit more complex in the future, we decided to stick with the top bar, which also proved to have higher discoverability rate than side bars–also more likely to suffer from banner blindness.
In the new layout we decided to make less emphasis on the map area and to divide it in half, so users could see more rooms at a time and have equal context of the location and info about the rooms.
We also provided better visual feedback for selected filters and made a distinction between basic/quick filters–such as Price and Availability, and the rest of the filters–the complementary ones, which enable you to fine-tune your search. Basic filters, when active, display their value in the same component with a bolder text style and complementary filters only show the number of filters applied within their category. Just like in app, they can be easily reset by clicking the ‘close’ icon.
I won’t go into the details of the room card and the filters screen redesign because I think that too would deserve another article and we’re currently iterating on them again so I prefer to write about the entire process in a new post. It’s difficult to wrap up a story that is still alive and far from finished but for now all I can say is that we’re already working hard and that I’ll keep you posted on our next moves, I hope you found the reading useful 😉.
