Cotality / OneHome hero image
Back to work

Cotality / OneHome

Concept

Helping Buyers and Agents Get on the Same Page

Cotality came to our capstone team with a timely question: as AI changes how people search for homes, what should that mean for OneHome? We started by looking at AI search. The more we researched the home-buying process, the less convinced we were that search itself was the interesting problem. Instead of using AI to replace the agent's judgment, we explored whether it could make the buyer's changing intent easier for both people to understand. That shift became the center of our work.

Team

Cindy Chiang, Shawn Farnum, Trinah Maulion, Isabel Schnebelie

Role

Research, design, and note-keeping across the team

Timeline

22-week capstone across two quarters · UC Irvine, HCI & Design

Status

Active - final report and evaluation in progress

The challenge

OneHome sits in an interesting position. It gives buyers a place to search for homes, but it's also intentionally connected to the real estate agent. Cotality didn't want AI to break that relationship. They wanted to understand where it could make it better.

Our original research question reflected that: "How might we strengthen real estate agent-homebuyer collaboration by incorporating AI search tools into OneHome and giving agents better support to uncover client priorities and guide them to the right home?"

It was a reasonable place to start, but it still assumed AI search was the answer. We needed to understand the problem before deciding what AI should do.

Looking beyond the search box

Our research looked at the home-search journey from several directions: literature review, competitive analysis, surveys, and interviews with people involved in the buying process. We wanted to understand more than which filters people used:

  • How do buyers decide what's actually important?
  • When and why does an agent become useful?
  • Where do agents spend time translating vague buyer requests?
  • What happens when someone's preferences change?
  • Where is AI already entering the process, and which parts of that work should it actually be trusted with?

By the end of spring quarter, that meant (summer research is still wrapping up, so these numbers will grow):

  • A competitive analysis across 11 real estate and search platforms
  • 290 homebuyer survey responses and 84 agent survey responses
  • 4 homebuyer interviews and 3 agent interviews
The current OneHome property search experience

The existing OneHome search experience - the starting point our research and concepts had to work with.

The competitive side was useful, mostly because it showed how easy it would be to chase features. Natural-language search, chatbots, listing summaries, recommendations, all of it can be useful. None of it automatically solves the problem we were seeing.

The problem under the problem

One pattern kept becoming more interesting to us: what buyers say they want is not always what they respond to. Someone can start a search saying a short commute is essential, then save five houses farther away because they have more outdoor space. Another buyer may insist on a particular neighborhood until they see what the same budget buys a few miles away.

That doesn't mean buyers are bad at searching. It means they're learning.

Traditional search treats preferences like inputs: 3 bedrooms plus $600k plus neighborhood X equals results. Actual home buying is messier. Search, compare, react, reconsider, talk, compromise, search again. The agent is often the person making sense of that mess. That changed how we thought about AI.

Our reframe

We started with: how can AI improve search? We moved toward: how can AI help buyers and agents build shared understanding?

That sounds like a small wording change. It changed almost everything about what we were willing to design. The question stopped being whether AI could make a recommendation. The better question was whether the system could help explain something useful enough that the buyer and agent could have a better conversation.

Visual coming soon

Before/after problem framing - visual coming soon.

Giving AI a smaller job

We eventually developed a pretty clear boundary. AI was good at things like:

  • Remembering what had happened across a search
  • Spotting patterns
  • Comparing information
  • Summarizing
  • Surfacing possible tradeoffs
  • Reducing repetitive work

We were much less interested in letting it own things like:

  • Deciding what a buyer should value
  • Making unexplained recommendations
  • Replacing an agent's professional judgment
  • Presenting an inferred preference as fact

A simple test emerged: does this help the buyer and agent understand each other better, or does it bypass the relationship? That became much more useful than asking whether something was technically an "AI feature."

Turning the research into interaction

One direction we explored started with conversation rather than more filters. The idea wasn't to make the buyer configure every preference manually before they could search. Instead, the system could build context over time from what the buyer said and did, then use that context when it became useful.

For example, a buyer might begin by saying commute matters more than outdoor space. A few sessions later, their behavior tells a different story. Rather than quietly changing the search results, the system could surface that tension: "You've saved several homes with longer commutes because they offer more outdoor space. Has outdoor space become more important than it was when you started?"

Now the AI has done something useful. It noticed a pattern. But the buyer still gets to decide whether the pattern means anything, and that answer can give the agent better context.

Three iterations of an AI preference-summary concept, evolving from a raw match score toward an explained summary

Early iterations of the preference-summary concept. Later versions moved away from a bare match score toward explaining why.

Comparing homes without picking a winner

We also explored how the same idea could work when buyers are comparing properties. Most comparison interfaces are good at showing facts, beds, baths, square footage, and that information matters, but it still leaves the buyer to translate the numbers back into the decision they're trying to make.

Our concept explored an AI summary that could explain the tradeoff instead.

Home A

  • Better fit for your commute preference
  • Lower price leaves more room in the budget
  • Less outdoor space than the homes you've been saving recently

Home B

  • More space and larger yard
  • Similar to several homes you recently saved
  • Requires giving up some of the commute time you originally prioritized

The system isn't saying pick Home B. It's saying here's the decision you appear to be making. That distinction became really important to us.

Iterations of an AI property-comparison summary, comparing two real listings against a buyer's stated and observed priorities

Comparison concept iterations, working through how to explain a real tradeoff between two listings instead of just ranking them.

The critique that made the concept better

Not every version worked. One piece of feedback during critique was that some of our early concepts still felt like more manual filtering, even though our research was pointing toward people not necessarily wanting another layer of controls.

That feedback was right about the tension. We'd designed a conversational entry point, but parts of the experience still drifted back toward asking the buyer to manage the system. That forced a better question: if AI already has useful context, why are we making the buyer keep configuring it?

That pushed the concept toward surfacing relevant information when it mattered, instead of turning preference discovery into a long setup process. This is one of the pieces we want to show in the final case study, because it's much more representative of design work than pretending the first idea was right.

Visual coming soon

Early vs. revised screen - visual coming soon.

Designing around the relationship

Preferences are discovered, not entered once

The system needs room for people to change their minds.

AI interpretation should be visible

If the system thinks it learned something, the buyer should be able to see it and correct it.

Tradeoffs are more useful than scores

"92% match" hides the decision. Explaining what fits and what doesn't gives people something they can actually discuss.

Reduce work before replacing judgment

Pattern recognition and summarization are good candidates for AI. Professional advice and personal values are not the same kind of problem.

The agent should gain context, not lose control

If AI works well here, it should make the agent better prepared for the human conversation.

What we were really designing

By this point, we stopped thinking of the concept as an AI search feature. It was closer to a translation layer. The buyer brings incomplete preferences, behavior, reactions, and changing priorities. The agent brings experience, market knowledge, questions, and judgment. The system can sit between those two things and make useful patterns easier to see.

That gives AI a role that feels much more defensible to us: it handles some of the remembering and pattern finding. People still own the meaning.

Scope

There were some things we intentionally didn't try to prove. We weren't building a production recommendation model, and we weren't validating whether an algorithm could accurately infer someone's preferences across millions of buyers. We were designing and testing the interaction model around that intelligence. Our work focused on the OneHome residential search experience, especially:

  • Preference discovery
  • Property search
  • Comparison
  • Buyer-agent communication
  • AI-assisted support

We didn't attempt to redesign the entire transaction, mortgage process, seller experience, closing process, or the rest of Cotality's product ecosystem. That distinction matters. A believable prototype can show how AI should behave without pretending the underlying intelligence is solved.

Testing and iteration

This section will be completed when the final evaluation is finished. It should eventually answer four things, without turning into a usability-test report: what did we put in front of people, what did we expect to happen, what did we learn that changed the design, and what remained unresolved.

The goal isn't to prove that every idea tested well. The useful part is showing which assumptions survived contact with another person and which ones didn't.

Visual coming soon

High-value testing observations and before/after iteration - coming soon once evaluation wraps.

Where we landed

Final project recommendations and evaluation findings will be added after the capstone report is complete. The direction is already clear, though: the strongest role we found for AI in OneHome was not replacing the agent or simply giving buyers another way to generate listings. It was helping turn search behavior into something buyers and agents could understand together.

That could mean recognizing changing priorities, explaining why two homes represent different tradeoffs, summarizing what the system has learned without pretending that interpretation is fact, or taking repetitive information work off the agent's plate so they have more context when human judgment matters.

The technology matters. But the relationship is the product constraint that makes the technology interesting.

What we took from it

We came into this project expecting the hard question to be what should AI do? We think the more useful question turned out to be what should AI not do? Once we put boundaries around it, the design got better.

Let the system remember things people shouldn't have to remember. Let it notice patterns that are difficult to see across dozens of listings. Let it organize and explain. But when a person is deciding where they're going to live, what they're willing to give up, and what actually feels right, AI doesn't need to become the tastemaker. It can help make the decision clearer. The people involved should still make it.