Ask Markerr | Conversational AI Case Study

How behavioural design and a specialised LLM helped renters make confident decisions — and retire the search-bar-plus-20-filters pattern.

Markerr wanted to explore a strategic bet: what if rental search moved beyond the familiar search-bar-plus-20-filters pattern and became a conversational decision-support experience?

The opportunity was clear. Renters were already experimenting with LLMs, but rental platforms still forced them to translate messy life constraints — commute, pets, budget anxiety, neighborhood trade-offs — into rigid filters. The risk was equally clear: housing is a high-stakes decision, and users do not automatically trust AI when money, time, and life context are involved.

My role was to shape the conversational interaction model, GenUI behavior, research synthesis, correction patterns, and trust architecture for Ask Markerr: a white-label strategic prototype that partners could embed into their rental discovery experiences.

The Core Thesis

Renters weren’t struggling to search. They were struggling to decide — so the AI experience had to make intent visible, evidence inspectable, and mistakes cheap to correct.

Role

Senior UX Designer (via Nortal)

Client

Markerr, New York — real-estate data company, later acquired by REBA

Timeline

2025 · ~4 months

Platform

Mobile (iOS-first) + desktop web, white-label

Focus Areas

Conversational UX, behavioral design, GenUI behavior, trust calibration, correction loops, property evidence grounding

The Problem

A familiar search, broken decision-making

Rental search was not “broken” in the obvious sense. Users understood it. Zillow, Apartments.com, and similar platforms had trained people to expect a search bar, a map, listing cards, and a large filter panel.

That familiarity mattered. Jakob’s Law was working against any radical reinvention: users spend most of their time on other products, so they bring those expectations with them.

But the familiar model was still failing users at the decision layer.

Renters do not actually think in clean database fields. They think in life constraints:

“I’m starting a new job and can’t deal with a brutal commute.”
“I have a dog, but I’m worried the pet policy will have hidden restrictions.”
“I can stretch my budget, but only if utilities or parking are included.”
“I don’t know the neighborhood well enough to tell if this is a good trade-off.”

Traditional filters are good at narrowing a database. They are weak at helping people reason through trade-offs. The desk research was blunt about the cost: 67% abandon property searches under filter overload⁵, opening 8.3 external tabs per session to patch the context gap the platform ignores⁶ — Hick's Law in action⁸. And across every renter segment, the first question was the same: "What's included in the rent?" Financial transparency before neighborhood, before square footage — which set the priority order for what the interface surfaces first.

The design challenge was not to make a chatbot version of a filter panel.

It was to design an AI-mediated experience that helped renters express uncertain needs, inspect the evidence behind recommendations, and stay in control when the system misunderstood them.

The risk:

The behavioral tension behind the project was counterintuitive: Users talk to AI like a friend, but trust it like a salesman

People often interact with conversational AI socially. They share personal context, explain their situation in natural language, and expect the system to respond fluidly. But in high-stakes contexts, that openness does not equal trust. The research made the split explicit: 65% of Americans engage LLMs in back-and-forth dialogue², yet 40.7% actively distrust AI responses¹ — cross-referencing sources and consulting humans before acting on anything consequential.

A renter may tell the assistant, “I need a pet-friendly place near transit because I’m starting a new job,” but still distrust the answer if the system responds with a confident recommendation and no way to verify the reasoning.

That became the central design principle:

You don’t earn a skeptic’s trust by sounding more confident. You earn it by being easier to check.

So the experience could not behave like an oracle. It needed to behave like a transparent decision aid.

The AI had to show:

What it understood
What evidence it used
What changed when the user corrected it
How the user could verify the recommendation

My contribuitions:

I worked on the behavioral and interaction design layer that made the strategic prototype credible:

Synthesized desk research into renter anxieties, search behavior, AI trust patterns, and decision friction
Defined the conversational interaction model
Designed how users could express life-context constraints instead of operating filters
Shaped GenUI behaviors for results, maps, property cards, and follow-up prompts
Pushed for confirmation and correction patterns before the system acted
Defined grounding rules so property facts came from verified records, not generated prose
Documented failure modes, rejected patterns, and measurement hypotheses for future validation

The strategic decision to pivot away from open-ended Text-to-SQL was made by Markerr leadership. My contribution was designing the trust architecture for the renter-facing experience that came next.

The design strategy

Trust architecture, not chatbot polish

The early technical direction exposed the core product risk. An open-ended AI system could translate user questions into database queries, but latency was high and hallucinations were dangerous.

In real estate, a wrong answer is not just inconvenient. A fabricated pet policy, outdated price, or misleading availability claim can waste application fees, tours, and weekends.

So the design strategy shifted from “AI authors the answer” to “AI routes intent to verified data.”

That distinction shaped the whole interface.

The model could interpret what the renter meant, but it should not freely invent property facts. The UI needed to make that architecture legible without forcing users to understand the technical system underneath.

I framed the trust architecture around three rules:

Make intent visible: Show the user what the system understood before acting.
Make evidence inspectable: Ground claims in property data users can review.
Make correction cheap: Treat misunderstanding as a normal part of the flow, not an error state.

Six design decisions

1. Instead of a Location input, the first interaction became a scope.

A blank chat box overpromises. It implies “ask me anything,” which is dangerous for a scoped rental assistant. So the entry point became an invitation, not an empty field.

The screen used starter prompts written around recognizable renter situations:

“I’m moving for a new job and need to be near public transit.”

“I have a dog and a tight budget.”
“I want a quieter neighborhood but still need an easy commute.”

These prompts acted as a scope contract. They showed what the assistant could help with while lowering the effort required to start.

A key interaction detail: chips pre-filled the prompt, but did not auto-submit. Pre-fill preserved agency: the system helped users start, but the user still owned the message.

This reduced blank-state anxiety while preserving user control.

The empty state was not just onboarding. It was a scope contract: it showed what the assistant was good at, what kind of language worked, and how much agency the user still had.

2. The assistant echoed intent before showing results

“Is this thing understanding me?”

Before returning results, the assistant mirrored its interpretation. This “semantic reflection layer” gave users a chance to confirm or correct the system before recommendations appeared.

This was the most important trust signal in the flow.

It applied Nielsen’s Visibility of System Status to AI comprehension. The system was not just saying “loading.” It was exposing the interpretation it was about to use.

For the business, this mattered because every downstream conversion depended on users believing the results were actually tailored to their needs.

This was the most important trust signal in the flow.

It applied Nielsen’s Visibility of System Status to AI comprehension. The system was not just saying “loading.” It was exposing the interpretation it was about to use.

For the business, this mattered because every downstream conversion depended on users believing the results were actually tailored to their needs.

3. Follow-up chips retrained the filter habit

If you replace filters with a chat box, many users simply rebuild the filter panel in natural language:

“2 bed, under $3,000, pet-friendly, parking, gym, near subway.”

That works for simple narrowing, but it misses the advantage of conversation: expressing context, uncertainty, and trade-offs.

After each response, I introduced suggestion chips based on life situations, not database fields.

These prompts appeared after users saw the assistant respond — the moment of highest motivation, straight from Fogg's behavior model.

The chips quietly taught a new mental model. Instead of explaining, “You can describe your situation,” the interface demonstrated it at the right moment.

This reduced cognitive load and improved input quality at the source.

This was one of the design assumptions I would want to test first. Without live usage data, we could not know whether users would adopt these life-context prompts or ignore them as decorative suggestions.

Property recommendations were grounded in evidence the model could not invent

A fluent AI recommendation can sound persuasive even when it is wrong.

In rental search, that is dangerous. A hallucinated pet rule, outdated availability date, or incorrect fee can create real cost for the user.

Instead, the AI interpreted intent and produced structured outputs that populated rigid, database-grounded cards.

The assistant could provide a short match rationale, but core facts — rent, availability, fees, pet policy, floor plans, and property rules — came from verified records.

This changed the trust model from:

“Believe the AI.”

to:

“Here is the recommendation. Here is the evidence. Check it yourself.”

The AI became an accountable interface layer, not an authority.

5. Correction became a first-class interaction

A conversational AI will misunderstand users. That is not an edge case; it is a certainty.

The design question is whether correction feels easy and normal, or whether the user has to restart, retype, and repair the system’s mistake manually.

I treated correction as a primary interaction pattern:

Editable message bubbles for fixing misunderstood criteria
Regenerate actions when the input was right but the output was weak
Clear distinction between “you misunderstood me” and “the recommendation is wrong”
Desktop split-screen patterns where the assistant response and source data could be inspected together

Low-cost correction makes experimentation safe.

Users do not need to blindly trust the system if they can easily see, fix, and recover from mistakes.

For the business, this also signaled maturity: the product was not pretending the AI was perfect. It was designing for what happens when it is not.

6. The map became the decision surface, not a secondary filter

Rental platforms often treat maps as another way to filter listings.

But renters evaluate apartments through neighborhoods, commutes, price distribution, and spatial trade-offs. The map is not secondary. It is where much of the decision happens.

Matched properties appeared as price pins on the map, with results grouped by neighborhood rather than only by relevance score.

A persistent “Ask a follow-up…” bar kept conversation available inside the results view, so users could refine without losing spatial context.

This aligned the interface with how renters decide.

Conversation controlled the query. Geography carried the decision.

Price pins answered the most common first question — “what can I afford, and where?” — without requiring users to open every card.

Outcome

Ask Markerr was demoed to partners and investors as a strategic white-label prototype.

It did not ship to end users, so I do not claim live behavioral metrics.

The value was strategic: the prototype made Markerr’s AI product direction concrete. It helped shift conversations from “what data does Markerr have?” to “what can Markerr’s AI experience do?”

That distinction matters. The shipped, revenue-driving Markerr work I led in parallel was the Data Studio redesign (~40% revenue growth). Ask Markerr’s contribution was different: it supported the company’s AI repositioning narrative and gave partners a tangible way to understand the opportunity.

What I would improve next

If this moved from prototype to production, I would focus on four areas:

Live usability testing with renters
The strongest design assumptions — especially follow-up chips and semantic reflection — need validation with real users.
Uncertainty cues for generated analysis
For any AI-generated estimate, forecast, or comparison, the interface should show range, source count, and confidence boundaries rather than absolute claims.
A technical transparency layer
Users do not need to understand the full architecture, but they should understand the difference between verified property facts and AI-generated rationale.
A correction taxonomy
The product should distinguish between misunderstood intent, outdated data, weak ranking, and missing inventory — because each failure needs a different recovery path.

People Don’t Search for Homes. They Try to Decide.

How behavioural design and a specialised LLM helped renters make confident decisions — and retire the search-bar-plus-20-filters pattern.

Markerr wanted to explore a strategic bet: what if rental search moved beyond the familiar search-bar-plus-20-filters pattern and became a conversational decision-support experience?

My role was to shape the conversational interaction model, GenUI behavior, research synthesis, correction patterns, and trust architecture for Ask Markerr: a white-label strategic prototype that partners could embed into their rental discovery experiences.

Renters weren’t struggling to search. They were struggling to decide — so the AI experience had to make intent visible, evidence inspectable, and mistakes cheap to correct.

The Problem

A familiar search, broken decision-making

Rental search was not “broken” in the obvious sense. Users understood it. Zillow, Apartments.com, and similar platforms had trained people to expect a search bar, a map, listing cards, and a large filter panel.

That familiarity mattered. Jakob’s Law was working against any radical reinvention: users spend most of their time on other products, so they bring those expectations with them.

But the familiar model was still failing users at the decision layer.

Renters do not actually think in clean database fields. They think in life constraints:

“I’m starting a new job and can’t deal with a brutal commute.”

“I have a dog, but I’m worried the pet policy will have hidden restrictions.”

“I can stretch my budget, but only if utilities or parking are included.”

“I don’t know the neighborhood well enough to tell if this is a good trade-off.”

The design challenge was not to make a chatbot version of a filter panel.

It was to design an AI-mediated experience that helped renters express uncertain needs, inspect the evidence behind recommendations, and stay in control when the system misunderstood them.

The risk:

The behavioral tension behind the project was counterintuitive: Users talk to AI like a friend, but trust it like a salesman

A renter may tell the assistant, “I need a pet-friendly place near transit because I’m starting a new job,” but still distrust the answer if the system responds with a confident recommendation and no way to verify the reasoning.

That became the central design principle:

You don’t earn a skeptic’s trust by sounding more confident. You earn it by being easier to check.

So the experience could not behave like an oracle. It needed to behave like a transparent decision aid.

The AI had to show:

What it understood

What evidence it used

What changed when the user corrected it

How the user could verify the recommendation

My contribuitions:

I worked on the behavioral and interaction design layer that made the strategic prototype credible:

Synthesized desk research into renter anxieties, search behavior, AI trust patterns, and decision friction

Defined the conversational interaction model

Designed how users could express life-context constraints instead of operating filters

Shaped GenUI behaviors for results, maps, property cards, and follow-up prompts

Pushed for confirmation and correction patterns before the system acted

Defined grounding rules so property facts came from verified records, not generated prose

Documented failure modes, rejected patterns, and measurement hypotheses for future validation

The strategic decision to pivot away from open-ended Text-to-SQL was made by Markerr leadership. My contribution was designing the trust architecture for the renter-facing experience that came next.

The design strategy

Trust architecture, not chatbot polish

The early technical direction exposed the core product risk. An open-ended AI system could translate user questions into database queries, but latency was high and hallucinations were dangerous.

In real estate, a wrong answer is not just inconvenient. A fabricated pet policy, outdated price, or misleading availability claim can waste application fees, tours, and weekends.

So the design strategy shifted from “AI authors the answer” to “AI routes intent to verified data.”

That distinction shaped the whole interface.

The model could interpret what the renter meant, but it should not freely invent property facts. The UI needed to make that architecture legible without forcing users to understand the technical system underneath.

I framed the trust architecture around three rules:

Make intent visible: Show the user what the system understood before acting.

Make evidence inspectable: Ground claims in property data users can review.

Make correction cheap: Treat misunderstanding as a normal part of the flow, not an error state.

Six design decisions

1. Instead of a Location input, the first interaction became a scope.

A blank chat box overpromises. It implies “ask me anything,” which is dangerous for a scoped rental assistant. So the entry point became an invitation, not an empty field.

The screen used starter prompts written around recognizable renter situations:

“I’m moving for a new job and need to be near public transit.”

“I have a dog and a tight budget.”

“I want a quieter neighborhood but still need an easy commute.”

These prompts acted as a scope contract. They showed what the assistant could help with while lowering the effort required to start.

A key interaction detail: chips pre-filled the prompt, but did not auto-submit. Pre-fill preserved agency: the system helped users start, but the user still owned the message.

2. The assistant echoed intent before showing results

“Is this thing understanding me?”

Before returning results, the assistant mirrored its interpretation. This “semantic reflection layer” gave users a chance to confirm or correct the system before recommendations appeared.

This was the most important trust signal in the flow.

It applied Nielsen’s Visibility of System Status to AI comprehension. The system was not just saying “loading.” It was exposing the interpretation it was about to use.

For the business, this mattered because every downstream conversion depended on users believing the results were actually tailored to their needs.

3. Follow-up chips retrained the filter habit

If you replace filters with a chat box, many users simply rebuild the filter panel in natural language:

“2 bed, under $3,000, pet-friendly, parking, gym, near subway.”

That works for simple narrowing, but it misses the advantage of conversation: expressing context, uncertainty, and trade-offs.

After each response, I introduced suggestion chips based on life situations, not database fields.

Property recommendations were grounded in evidence the model could not invent

A fluent AI recommendation can sound persuasive even when it is wrong.

In rental search, that is dangerous. A hallucinated pet rule, outdated availability date, or incorrect fee can create real cost for the user.

Instead, the AI interpreted intent and produced structured outputs that populated rigid, database-grounded cards.

The assistant could provide a short match rationale, but core facts — rent, availability, fees, pet policy, floor plans, and property rules — came from verified records.

5. Correction became a first-class interaction

A conversational AI will misunderstand users. That is not an edge case; it is a certainty.

The design question is whether correction feels easy and normal, or whether the user has to restart, retype, and repair the system’s mistake manually.

I treated correction as a primary interaction pattern:

Editable message bubbles for fixing misunderstood criteria

Regenerate actions when the input was right but the output was weak