Filters in a real estate search tool
The context
Real estate agents rely on Multiple Listing Service (MLS) search engines to do their work. Through UXR, we knew that Compass agents were turning to this third-party tool to validate searches they carried out in the Compass search tool. This was because the filters that Compass used in its search engines differed from the filters more familiar to agents through the MLSs.
Since it was one of the core value props of Compass to provide a suite of easy-to-use tools, all in one place for its agents, this was a problem. To solve for agents using third-party tools, a team proposed introducing MLS filters into the Compass search engine.
The problem
The team was getting stuck on how to represent these changes in the filter experience. A designer and product manager came to Content Design office hours.
Their first question had to do with a single line of copy introducing the MLS filters section.
Asking questions
I began, as I often do, by asking a lot of questions. Questions asked in real-time together often elicit the best material for UX writing. Designers and PMs speak conversationally about what they know. I’ll often jot down what they’re saying in a shared doc or the Figma file, which becomes the starting point for revised copy.
In this case, I couldn’t put my finger on what the intent of the sentence was. It sounded like a limit — these filters can ONLY filter listings from a particular feed. It also sounded tautological and not very informative. What was I missing?
I learned that the sentence intended to let users know that it’s not a good idea to use MLS filters exclusively in their search because doing so would limit the results they see. In particular, they wouldn’t be able to see listings from other MLSs or Compass exclusives. The desired action was for agents to use both sets of filters in combination — this would get them the best results.
What the sentence needed was not a technical description of the limits of the new feature. It needed a description of the value of using both Compass and MLS filters together.
We renamed the section “Statewide MLS filters” so agents could deduce, from their prior experience, the limits built into this filtered search.
We changed the copy to read:
Incompatible filters
There was another problem. Using two sets of filtering logics could lead to poor search results. Some filters conflicted with one another, leading to artificially low result counts. Each platform defined filters somewhat differently, so duplicate filters needed to be explained.
For example, a user might fill out the square footage under Compass filters, and then try to fill out the square footage under MLS filters (perhaps forgetting they had already done so). The duplicate filter itself might be confusing enough to users. But if the user entered square footage a second time, a toast would appear: This filter conflicts with the “Square Feet” filter.
Why not remove duplicate filter inputs? Because the filtering logics were different. Some filters include below- ground square feet while others didn’t.
Why not disable the second filter once the first had been populated? Because the agent might opt to use the second once they knew how square footage was differently defined.
The backend complications invited a much more robust, step-by-step, branching flow rather than a flat form. But we needed to work with what we had.
Non-error state
The team had played around with multiple ideas for guiding users through incompatible filters, including persistent info icons, error messages, and blocking modal dialogs.
I made an alternative suggestion that blended UX design and content: when a user went to input square footage in a second filter field, a text link would appear in the interactive blue (rather than the error state red). I suggested we avoid using “conflicting” or “incompatible” because it was too technical, and set a negative tone.
When selected, the text link would yield a popover that gave users the option to keep or replace the filters.
In this way, guidance on conflicting filters would be revealed as needed (rather than peppering the page in the form of info icons). And the attempt to enter info in a second filter wouldn’t make the user feel like they had done something wrong (which they hadn’t).