Redesigning the search field for a property seeking app

Main problems

Confusing about the current search

We had a problem where users had a hard time understanding which searches criteria they were currently seeing, and therefore confused about the listing of properties. Because the listing of ads is the main page of the app, we wanted to make sure that we eliminate all kinds of confusion for users, so they can focus on what’s important.

Zero search

At the same time, we as a company wanted to help people reaching their desired search.

But if it happens that a user uses a combination of areas and filterers that doesn’t have any matches, we have a responsibility to inform the user why that is and help them on their way to a search with matches.

• We should, therefore, help users to ‘’trim’’ or change their filters to reach a list of results.

• Or if the search is what they actually are seeking, we should help them create a Property agent, that will notify them as soon as we get a new property that matches their criteria.

Design process

Header/search field

To meet these goals, we started off by looking at the main place people interact when they want to create a search — the header of the list view.

When doing these kinds of redesigns we first of all need to document the current feature set, to make sure that we don’t miss anything doing the redesign.

We called this ‘‘feature mapping’’ and it helps us noticing odd patterns, or maybe features that are not supposed to be there. In this case, we didn’t find anything odd or misplaced, but actually found something that was missing: sorting.

Instead of giving the user the option to toggle different sorting options for the list, on the list view, the sorting option where hidden inside the filtering page.
We haven’t heard any feedback from users about this being a negative thing, but logically we wanted to move it out and into the list view, and hopefully more users will notice the feature and use it.

After the feature mapping, we ended up with a good understanding of the current solution and could now start sketching out the new design.

The main idea consisted of creating a contextual search field, that displayed both the area you were searching within and what kind of filtering you had set.

Sketching and designing

The search field:

There are two ways for users to create a search, and specify what they are seeking.

1. Picking and choosing the area(s) they want to live in.

2. Applying filters that specify their criteria: number of rooms, size, rent etc.
   

Understanding that this is how people search, creates an overview of the data points we have available and can use to inform the users of the current search.

We, therefore, created two different states of the search field.

1. No search — The users haven’t picked any areas or filters — this is usually what new users will see at app launch, and here we want to nudge the user to create a search.

2. Active search — This state takes the area(s) and displays them at the top of the search bar. Depending on the number of areas, we can display the name or the number of areas picked.

Underneath we display the enabled filters that the users have specified, starting the hierarchy of the search filter page — max. Rent, number of rooms, etc.

The whole header — feature mapping:

By creating this contextual search field, we decided to divide the header into two parts, searching and viewing.

By doing this, it was easier to map the rest of our feature-set. We, therefore, placed the filter button in addition to the search field, and by that keeping the feature close to the data it changes.

We then placed the agent-bell (Notifications about new properties) alongside this search field that contains all the datapoint, to create a clear indicator about the search you will be getting notifications about.

While moving all the features and data regarding the search together, we could then have a whole section with settings just regarding the view — sorting, map view, and list view.

We here decided to change the ‘’change-view-function’’ to label-buttons instead of icons, to solve the problem with users that couldn’t find the map feature.

The final product — a header with a contextual search field and view-options that’s easy to find and use.

Zero search

And now to the zero search, and helping users getting from a search with zero results, to find the property they are looking for.
Before creating this solution we didn’t do anything to help the users getting from an empty search state, in fact… We just displayed an empty screen. Not good enough.

To help the user find the right property we wanted to do two things:

1. Primary action: Help them trim their filtering to find a search combination that has properties in it.

2. Secondary action: Help them create an agent. So we can notify them whenever we get a new property.

This should be fairly easy to design, and pretty straightforward. But it actually took quite a number of iterations, before we found the right solution.

Here is the final result

Conclusion

We ended up with a total redesign for how searches are displayed in our app.

A solution that contextually shows the user’s witch listing they are currently seeing on the phone.
Combined with that, we took the opportunity to create an informative empty state to help our users reach their desired search.

This redesign is currently live and in production, and the feedback has been silent. And that’s great.
We solved a major problem in our app, that users were leaving feedback about. Now they can focus on what’s important — finding their next home.

CHECK OUT SOME OF MY OTHER PROJECTS