Better Together: Collaboration with Users Makes Your Product Better

Nikki HughesProduct

Team working together through problems

Technology changes fast. And as a technology company, you have to adapt quickly or risk being left behind. Sometimes, that means making changes that are disruptive in the short term, but beneficial in the long term. At Realtracs, we are no strangers to embracing and implementing change as discussed in one of our previous posts on modernizing technology. Changing the product doesn’t have to be a high-risk, all-or-nothing endeavor. We work to reduce risk at every point along the way. And we work to learn quickly from our users along the way.

The Journey to a New (and Better) Search Experience 

A challenge we faced for many years was making our tools available where our customers and consumers needed them: on a mobile device. We iteratively updated our product to be mobile-friendly, but we had to tackle the largest, most used, and most complex tool: our search platform. Not only did we have to meet the challenge of building a mobile-friendly search tool that was intuitive to use, but we also had to migrate all existing searches and sunset the legacy system.

Our search platform encompasses many features, including, but not limited to:

  • Searching for current listings
  • Interacting with the data via maps, lists, and grids
  • Learning about recent changes/updates to listings
  • Saving a set of specific listings
  • Saving searches
  • Automatically searching with set parameters

We began our work to build the new search platform in 2021 and we officially sunsetted the legacy platform in January 2023. Every feature in our legacy search system was revamped or rebuilt in some way, and then the legacy feature was retired. Throughout this entire process, we kept customers at the forefront of our migration process. 

Customer Discovery When Streamlining Features

Our product – like most software that has been around for many years – had some feature bloat and duplication; things that were created for a specific purpose and either not maintained or duplicated out of convenience. For instance, we had two tools for creating lists of specific properties, but in two completely different ways. This was an example of both technical debt and product cruft. 

To understand how these two features were being used, we conducted customer discovery through surveys and interviews to understand how our agents were using them. Some questions included:

  • How do you use Feature A? How do you use Feature B?
  • Is there a time you use Feature A over Feature B?
  • What are the pain points of Feature A/Feature B?

Through this discovery, we validated that many of the use cases overlapped and that there was no need for two different features. We merged the features, eliminating many of the pain points of both, and were able to create a mobile-friendly way for agents to keep track of specific properties.

Because we took the time to interview our customers, we built what was needed and improved the user experience along the way.

Empower Users to Test Drive

We want our users to feel empowered by our product – to try the new features out and feel like they have a voice about what we are building. We also want to provide psychological safety when implementing a completely new change – this was especially true during our migration. Preventing an agent from running a search or halting access to their saved searches/saved listings was not an acceptable outcome. 

One way we empowered our users was by letting them opt into new features.

One large platform change we made to our search domain was the navigation experience. We knew it would be a large change, not only from a code perspective but from the user experience perspective as well. Some items that users were accustomed to seeing in the legacy system had been moved in the new system and some elements had been redesigned completely. We wanted them to get used to the new experience, but also needed an “escape hatch” in case issues were found.

We approached this navigation change in the following manner:

  • Iteration 1: Allow users to opt-in to the new navigation themselves + get feedback
  • Iteration 2: Opt users in by default, but let them opt out + get feedback
  • Iteration 3: Communicate (a lot!), then make the switch permanent

This turned out to be a beneficial approach because several early adopters opted in and helped us find issues very quickly. Because they could return to the old navigation, they were able to continue work while our team filled in all the gaps. 

Image courtesy of Wikipedia

Iteration 1 helped pave the way for Iteration 2, where all users started experiencing the new navigation by default, many for the first time. Most of the bugs had been fixed, but some users did experience issues that forced them to return to the old navigation, but they were still able to continue their normal workflow. Our team did receive a lot of “Where did x go?” and our incredible support team was able to help guide our users, all while we continued to iterate through necessary changes and bug fixes.

By the time we were ready to make the change permanent, we felt very confident in the feature set and we knew how to guide our late adopters/laggards through the changes.

Listen with Curiosity and Respond Quickly

Throughout the journey, we provided many ways for our users to contact us and to leave us feedback. And they did, especially once features were retired.

Image courtesy of imgflip “Knope”

Many were unhappy with the new search platform simply because it was different. But in many cases, our users left us very valuable feedback about why they preferred the legacy system. So we looked for patterns to find where we needed to learn more and we reached out to customers to follow up:

– What did you prefer from the legacy system?

– What are the pain points you’re encountering now?

One example of this was with our county selection. The legacy system opened a list of all counties and users had to check all the counties they wanted to include in their search. The new platform contained a typeahead that allowed a user to type a few characters to select their county. We found that typeaheads allowed us to have a more accurate search experience and were becoming a standard pattern for searching.

Through feedback and discovery, we learned that both implementations had their merits, so we introduced a selection list that met our users’ needs to easily see county names and select multiple counties with a few clicks, while also meeting our technology/UI/UX standards.

Making changes to your product is inevitable. Even if it’s not a system-wide change, your product can – and will – benefit from user feedback throughout the development process. Keep your users informed and involved – you’ll learn a lot from them along the way.