STRATEGIC PROTOTYPE · 2025 · FOUR MONTHS
How I designed an LLM Interface interaction so people could search and inspect before trusting.
Ask Markerr explored a different starting point for rental discovery: let people describe the life they were trying to build, then help them turn that situation into a useful search.
- CLIENT
- Markerr · real-estate data
- ROLE
- Senior Product Designer via Nortal
- PLATFORM
- Mobile-first + desktop web
- STATUS
- Partner and investor demos · no public release
TL;DR
ROLE
I led the behavioral research synthesis, conversational interaction model, generated-UI behavior, correction patterns, and renter-facing experience.
COLLABORATION
Markerr’s leadership owned the product pivot. AI engineering owned the model, routing, and data architecture. I designed the human-control layer around them.
OUTCOME
The prototype made Markerr’s AI direction concrete enough to discuss with partners and investors. It did not produce adoption, conversion, or revenue metrics.
WHY IT MATTERS
I treated trust as an inspection problem, not a persuasion problem. That decision shaped the entire experience.
THE REFRAIMING
The conversational part was easy to imagine. The difficult part was deciding what should happen after someone pressed send.
The AI did not need to sound more certain. It needed to be easier to inspect, correct, and use without surrendering judgment.
A fluent answer could make the experience feel simpler. It could also hide a misunderstood constraint, an invented property detail, or a recommendation the renter had no practical way to check. That risk became the center of the design.
01 — THE OBVIOUS MOVE
The obvious move was “just add chat.”
Markerr already had a serious real-estate data engine. The first version explored open-ended B2B analysis through Text-to-SQL: a person asked a question, the system translated it into a database query, and the model returned an answer.
The platform contained more than 150 metrics, many named around the underlying data model rather than the language customers used. Internal notes described queries taking around a minute, with recurring problems in joins, metadata, and answer quality.
A slow answer is annoying. A fast, fluent, wrong answer is harder to notice.
THE PIVOT
Do less, make the constraint useful.
Markerr’s leadership shifted the system from open-ended analysis toward guided rental discovery. The model would extract location, budget, timing, and amenities, then route those parameters to verified property data.
That strategic and architectural pivot was not my decision. My responsibility began with its consequence: help renters express what mattered, see what the system understood, and inspect the evidence behind a recommendation.
02 — BEHAVIOR BEFORE SCREENS
Traditional filters narrow a database. Renters are still figuring out the decision.
We did not have direct access to renters for primary research. I used AI-assisted desk research, competitor analysis, behavioral story mapping, and known LLM interaction patterns to build a working model of the problem. I treated that material as design input, not validation.
Make intent visible. Keep evidence outside the model. Make mistakes cheap to correct.
03 — THE CRITICAL MOMENT
Trust moved earlier in the flow—before the recommendation.
If the system jumped straight to listings, the renter would discover a misunderstanding only after the AI had acted on it. By then, the result had already framed the decision and correction had become more expensive.
ECHO BEFORE RESOLVE
“I’m looking for pet-friendly options in Austin under $2,000, with walkability and access to transit as priorities. Is that right?”
The extra pause made the system’s working interpretation visible while the request was still easy to change. Instead of behaving like an oracle, the assistant behaved like a collaborator checking whether it had understood the assignment.
04 — TRUST ARCHITECTURE
Five decisions turned the idea into a system people could inspect.
Each choice traded a little conversational theater for clearer scope, better evidence, or cheaper correction.
01
I treated the empty state as a promise.
A blank chat field quietly promises “ask me anything.” I replaced it with starter prompts built around renter situations—budget pressure, pets, commuting, accessibility, safety, and first-time renting. Selecting one placed editable language into the input instead of submitting automatically.
I gave up some of the theater of infinite possibility. In exchange, the product showed what it was good at and kept the renter in control.
02
I used follow-ups to teach the new behavior.
People could simply rebuild the old filter panel as a sentence. Situation-based follow-ups—starting a new job, needing outdoor space for a dog, caring more about neighborhood than square footage—demonstrated the new interaction at the moment the renter was ready to continue.
This remained a hypothesis. Prompt-path adoption would be one of the first behaviors I would measure.
03
I kept property facts outside the model.
A generated paragraph is the wrong place to store exact rent, availability, fees, pet rules, and floor-plan details. The model could explain why a result might fit. Structured cards, populated from the property database, owned the decision-critical facts.
Here is the recommendation. Here is the evidence. Check it yourself.
I rejected confidence badges attached to generated prose. A badge can make an answer look safer without making it easier to verify.
04
I designed correction as a normal route.
The assistant would misunderstand people. That was not an edge case. It was a product condition.
EDIT
Edit the request when the system misunderstood the renter.
REGENERATE
Regenerate when the request was right but the response was weak.
FOLLOW UP
Ask a follow-up when priorities changed.
KEEP CONTEXT
Return to the same list or map without resetting the conversation.
05
I made the map part of the answer.
Rental products often treat the map as an alternative view. I treated it as a decision surface. Price pins made affordability visible without requiring a tap; grouped results supported neighborhood-level comparison; and the follow-up field kept the conversation active inside the map.
Conversation could refine the request, but it should not erase the geography that made the answer meaningful.
ACCESSIBILITY BEFORE HANDOFF
Pinch-to-zoom alone excludes people who cannot perform a multipoint gesture. The specification included visible zoom controls as an alternative.
05 — LATENCY WITHOUT THEATER
The system needed feedback, not a silent spinner.
A silent wait would make interpretation and retrieval feel arbitrary. I explored progress states that described useful system activity in plain language without exposing private model reasoning or performing intelligence.
The experience might feel slower than an instant answer. That was the trade-off: a short, legible wait was more honest than false immediacy.
- 01Reading the commute constraint
- 02Checking available pet-policy data
- 03Narrowing the current property set
06 — WHAT THE PROTOTYPE MADE POSSIBLE
Strategic proof of direction—not product-market proof.
Ask Markerr was demonstrated as a white-label concept in partner and investor conversations. It gave Markerr a concrete way to discuss an AI-mediated product experience beyond the data platform it was already known for.
If partners could inspect the system’s interpretation, verify property evidence, and see how correction worked, they could evaluate a credible AI product direction before Markerr committed to a full consumer release.
PROOF BOUNDARY
The prototype supported Markerr’s AI positioning ahead of its acquisition by REBA. It did not cause the acquisition and did not prove adoption, conversion, retention, or revenue impact. The approximately 40% revenue growth associated with my work at Markerr belongs to the separate, shipped Data Studio redesign.
07 — WHAT I WOULD MEASURE
The goal is calibrated trust, not “more trust.”
Enough confidence to use the system; enough skepticism to verify it when the stakes rise. I would read the signals together because a seemingly efficient path can also mean people are trusting the interface too easily.
01
Intent-correction rate
How often do renters edit a reflected constraint before opening results? A healthy rate could show the reflection layer catches misunderstandings early.
02
Recovery completion
After a correction or weak result, how often do people continue instead of restarting or abandoning the session?
03
Evidence-inspection rate
How often do people open property rules, fees, details, or source information before scheduling a tour?
04
Prompt-path adoption
Do situation-based follow-ups improve request quality, or do people return to filter-style language?
05
Search-to-tour progression
Do guided conversations help qualified renters reach a tour request with fewer resets and less external research?
08 — WHAT I WOULD CHANGE NEXT
The trust model was clearer than the evidence behind it.
If the work moved toward production, I would focus on four gaps before polishing more screens.
TEST WITH RENTERS
The current direction is grounded in desk research and behavioral synthesis, not direct validation.
SEPARATE GENERATED FROM VERIFIED
Generated interpretation and database-backed facts should look different at component level, not only in explanatory copy.
DESIGN QUANTITATIVE UNCERTAINTY
Forecasts, comparisons, and estimates need ranges, source dates, and confidence boundaries—not only citations.
BUILD A CORRECTION TAXONOMY
Misunderstood intent, missing inventory, stale data, and weak ranking are different failures. They need different recovery paths and instrumentation.
I would also test the friction I deliberately introduced. Reflection before results is useful only if it catches meaningful misunderstandings without turning every search into a ceremony.
WHAT I TOOK FORWARD
Trust did not come from a better promise. It came from giving people something to check and a way to push back.
In products where an answer affects a real decision, the interface should not perform certainty. It should help people see what the system heard, inspect what the answer rests on, and recover when either side is wrong. That was the work I owned here—not the model itself, but the interaction layer that made a non-deterministic system more responsible to use.
EVIDENCE NOTE
This case study describes a strategic prototype. Research informed the design but did not validate it, and the prototype had no public end-user release or live behavioral metrics. Markerr’s leadership owned the strategic pivot from Text-to-SQL to guided rental discovery. AI engineering owned the routing and data architecture. My ownership was the behavioral synthesis, conversational interaction model, generated-UI behavior, correction patterns, and renter-facing trust architecture.
Next project
e-TCE
View case study