- Strategic LLM + GenUI prototype; demonstrated to partners and investors, not shipped to end users.
- Senior UX Designer / UX Engineer via Nortal. I led the conversational interaction model, GenUI behavior, behavioral research synthesis, competitive analysis, and white-label rental extension.
- Converted a vague AI ambition - 'let users talk to the data' - into a product system with trust mechanics, correction paths, evidence constraints, and partner-demo value.
- Ask Markerr supported the AI roadmap and acquisition-facing narrative. Markerr's broader revenue movement belongs to Data Studio and product repositioning work, not this prototype alone.
BackFrom AI ambition to
From AI ambition to
trustworthy product behavior
2025 - 4 Months
AI / LLM Interfaces
Markerr (via Nortal) — demonstrated to Greystar and investors
Project Overview
Ask Markerr was a strategic prototype that replaced traditional filter-heavy real-estate search and analytics interfaces with a conversational LLM experience capable of generating UI components at runtime. It existed in two expressions: deep analytics for institutional users and a white-label rental discovery flow for partners like Greystar.
Completely replaced the filter model with a conversational LLM interface capable of generating UI components at runtime. The architecture centered on "echo before resolve" (the system always restated user intent in plain language with visible, editable parameters before acting), immediate correction surfaces, stakes-calibrated trust signals, and streaming partial results.
SYS_REF // CASE_STUDY_4.0.0CONVERSATIONAL_AIB2B2C_ENTERPRISE
Markerr (via Nortal) — demonstrated to Greystar and investors is not just another case study
Turned a vague AI search ambition into a conversational LLM + runtime GenUI product system built around "echo before resolve," grounded property cards, visible reasoning, and first-class correction. Strategic prototype (never public) that helped make Markerr's AI product direction concrete without claiming shipped adoption.
Ask Markerr: Turning a Vague AI Ambition into a Trustworthy Product System
The original ask sounded simple: let people talk to Markerr's real-estate data. A chatbox on top of the platform would have been fast to explain and easy to demo, but it would have missed the actual product risk. Real-estate decisions are high-stakes, emotionally loaded, and full of details users cannot afford to have an AI misunderstand.
My role was to turn "AI search" into an interaction architecture: one that could shape ambiguous intent, expose what the system believed, constrain generated UI to grounded data, and keep correction available before a bad assumption became a bad recommendation.
// PRODUCT RISK REGISTER // STRATEGIC PROTOTYPE » INPUT RISK: USERS DESCRIBE LIFE CONTEXT, FILTERS DEMAND DATABASE TERMS » TRUST RISK: FLUENT AI CAN FEEL HELPFUL WHILE HIDING WRONG ASSUMPTIONS » OUTPUT RISK: GENERATED ANSWERS MUST NOT INVENT PROPERTY FACTS » BUSINESS RISK: AI ROADMAP MUST BE DEMONSTRABLE, NOT ONLY PRESENTED
The central product judgment was that users did not need a more charming way to fill out filters. They needed a system that made AI interpretation visible enough to trust, editable enough to correct, and grounded enough to use in consequential decisions.
The Product Risk Was Not Chat. It Was Trust.
Ask Markerr had to work across two related realities: renters making personal housing decisions and real-estate professionals trying to extract insight from fragmented data workflows.
Track A: Consumer Rental Discovery
Renters do not search through tidy database language. They bring life constraints: a dog, a commute, a partner's job, school zones, cash-flow anxiety, and fear of making an expensive mistake. Traditional filters force that context into premature structure, then hide the reasoning behind the result set.
Track B: The Enterprise Workspace
On the B2B side, real-estate teams were still assembling answers through query writing, spreadsheet cleanup, and BI interpretation. The opportunity was not only to answer questions faster; it was to show that Markerr's data platform could become an AI-native product surface with visible, inspectable outputs.
The LLM Interaction Problem
LLMs make the first interaction feel effortless, but they also introduce new failure modes: blank-slate prompting, hidden assumptions, overconfident language, dropped context, and outputs that feel plausible before they are verified. In real estate, that is not a polish issue. It is a product-liability issue.
[Filter-first search] -> Demands structured intent too early [Blank AI prompt] -> Demands prompt engineering from non-experts [Trust architecture] -> Makes interpretation visible, editable, and grounded
The Audience Was Multi-Sided, but the Trust Problem Was Shared
Decision Contexts
Relocating renter[Consumer]Design need: Translate life context into viable neighborhoods, budgets, and tradeoffs.
Practical household decision maker[Consumer]Design need: Compare schools, safety, space, commute, and total monthly cost without tab sprawl.
AI-comfortable explorer[Consumer]Design need: Use conversation naturally while retaining control over generated results.
Institutional real-estate analyst[B2B]Design need: Collapse fragmented query, spreadsheet, and reporting work into inspectable outputs.
Partner / operator evaluator[B2B2C]Design need: Assess whether Markerr could become an AI product platform, not only a data provider.
The Useful Pattern
The consumer and enterprise audiences had different jobs to be done, but the same trust requirement. They needed the system to show its work before asking them to act on it.
That insight shaped the product architecture more than any visual style decision. The interface had to preserve human agency at each point where the AI interpreted intent, generated an output, or asked the user to advance toward a consequential decision.
The Operating Principles Behind the Prototype
I treated the prototype as a set of behavioral contracts between the user, the model, and the data. Each principle was meant to reduce uncertainty at a specific point in the journey.
01 // INTENT SHAPING
Turn ambiguous input into structured, editable intent
The system should not ask users to know the schema before they know their own priorities. The interface lets them describe a messy life situation first, then progressively translates that language into parameters they can inspect and change.
02 // EXPLAINABILITY
Echo before resolve
Before showing results, the assistant mirrors the user's interpreted constraints in plain language. That moment turns a black-box recommendation into a reviewable contract: this is what I heard, this is what I will use, correct me before I act.
03 // GROUNDING
Generated UI must be constrained by evidence
The LLM could shape the experience, but it could not invent property facts. Cards, maps, counts, and analytic modules were designed as bounded output surfaces tied to inspectable real-estate data.
04 // STATEFULNESS
Preserve context across refinement
Real-estate decisions evolve over multiple questions. Follow-up prompts, persistent constraints, and editable parameters keep the user's working model alive instead of forcing them back into a blank search state.
05 // SPATIAL REASONING
Let geography carry the decision
Rental search is not just a list problem. The output needed to make neighborhood, commute, price, and property tradeoffs visible in one canvas, with conversation acting as the control layer rather than the whole experience.
- Reframed the ask from chatbot feature to trust architecture.
- Replaced the filter-first model with conversational intent shaping.
- Made the assistant echo interpreted constraints before resolving results.
- Constrained generated UI to inspectable property and market data.
- Designed correction as a normal path, not a breakdown state.
- A chatbot bolted onto the existing filter UI.
- Black-box recommendations with no evidence surface.
- Hidden parameters users could not verify or edit.
- A fully automated agent that removed human agency.
- A case-study story that treats a strategic prototype as shipped product impact.
Ask Markerr is strong proof of AI-native product judgment, runtime GenUI thinking, behavioral design, and engineering collaboration. It is not proof of public adoption. If I were extending it now, I would add a technical appendix for latency states, hallucination recovery, generated-component constraints, prompt/error taxonomy, audit logs, correction flows, and engineering handoff examples.
The typing state preserved user control while the system helped structure intent. Suggested phrasing could accelerate input, but the sentence stayed editable and cancellable.
The important design move was not hiding complexity. It was postponing schema decisions until the user had expressed the real-world constraint in their own language.
Inline intent shaping: helping users express constraints before forcing database structureSYS_REF // UI_INPUT_TYPING
How the Trust Architecture Worked
1. Empty State: Set a Useful Contract
The screen opens with a humanized display header: "Tell me what you're looking for in your next home." The point was not friendliness for its own sake. It framed the interaction as collaborative discovery instead of a transaction-heavy database query.
To eliminate empty-state prompt anxiety, we introduced contextual prompt chips such as "Budget Friendly" and "Pets?". Selecting a chip shaped the input into a natural sentence, but did not auto-submit. That preserved the user's right to revise the constraint before the system acted.
Invitational input: prompt scaffolding that reduces blank-state anxiety without taking control awaySYS_REF // UI_DISCOVERY_EMPTY
2. Typing State: Preserve Locus of Control
3. Chat Interface: Echo Before Resolve
System explainability: using natural-language feedback loops to confirm interpreted intentSYS_REF // UI_TRANSPARENCY_ECHO
Upon query execution, the AI output maps its comprehension boundaries into natural language text: "Prioritizing affordability and walkable communities makes a lot of sense." This is the core trust mechanic: the assistant exposes its interpretation before committing the user to a result set.
Simultaneously, a live result count badge, "8 Properties Found", updates inside the dialogue tree. The count acts as a lightweight system-state signal, helping users understand whether their constraints are too broad, too narrow, or worth refining.
4. Map Canvas: Make Spatial Reasoning Visible
Spatial canvas: conversation controls the query, but geography carries the decisionSYS_REF // UI_OUTPUT_CANVAS
Ask Markerr moved beyond a list-first layout because geography is a primary decision variable. Price pins, neighborhood grouping, and visible spatial distribution helped users compare tradeoffs without opening a chain of external tabs.
A persistent "Ask a follow-up..." prompt bar remains permanently docked at the bottom viewport. This kept refinement close to the evidence surface instead of sending users back to a separate filter panel.
5. Results and Details: Ground the AI in Inspectable Evidence
Neighborhood-first architecture: grouping listings around how people compare real optionsSYS_REF // UI_LAYOUT_CLUSTERS
Search results are clustered into neighborhood-specific groupings such as "South Austin" and "North Austin" instead of abstract relevance scores. That made the generated UI easier to evaluate against how renters actually reason about place.
When expanded, the detail screen surfaces floor plans and localized context together. The AI can assist the decision, but the user still sees the evidence that matters.
Commitment evidence: grounding generated recommendations in floor plans, maps, and local contextSYS_REF // UI_COMMITMENT_DETAILS
The Pivot: From AI Feature to Product Proof
The important pivot was rejecting the obvious implementation: a chatbot attached to an existing interface. That would have made the product look AI-enabled while leaving the user's real burden unchanged.
If the AI can change the answer, the interface must show what changed, why it changed, and how the user can correct it.
That sentence became the working design standard. It pushed the system toward visible parameters, correction loops, generated components with data boundaries, and a map-led output model that could be shown credibly in partner and investor conversations.
What the Prototype Proved
Ask Markerr was not a public product and should not be evaluated as an adoption story. Its value was strategic: it made Markerr's AI roadmap tangible, gave partners a concrete white-label rental discovery flow to react to, and showed how the platform's data could become an AI-native product experience.
| Risk Vector | Starting Condition | Design Move | Behavioral / Business Logic | Status |
|---|---|---|---|---|
| FILTER OVERLOAD | 20+ manual filters asked users to behave like database operators. | Conversational intent shaping with editable constraints. | Reduced decision latency by letting users express context before structure. | Prototype rationale |
| AI SKEPTICISM | Users wanted help but still needed proof before trusting AI output. | Echo before resolve, visible parameters, and correction loops. | Made comprehension inspectable before the system acted. | Interaction proof |
| HALLUCINATION RISK | A fluent answer could misstate price, pet policy, commute, or neighborhood fit. | Generated UI constrained to grounded property and market data. | Shifted AI from oracle to accountable interface layer. | Design constraint |
| ENTERPRISE WORKFLOW COST | Analysts assembled insights through SQL, spreadsheet cleanup, and BI handoffs. | Natural-language queries with runtime analytic components. | Showed how Markerr data could become a higher-leverage product surface. | Strategic prototype |
| PARTNER BUY-IN | Stakeholders needed to see a credible AI product direction, not a slide promise. | White-label rental discovery flow demonstrated with partner scenarios. | Moved conversations from data availability to product capability. | Demo outcome |
| ATTRIBUTION BOUNDARY | Company-level revenue movement belonged to broader Data Studio and repositioning work. | Kept Ask Markerr framed as proof of direction, not shipped adoption. | Protected credibility while still explaining strategic value. | Honesty boundary |
Business Value Translation
If we make the AI's interpretation visible before execution, then users and stakeholders can inspect, correct, and trust the system earlier; as a result, the prototype reduces product-risk uncertainty and makes the AI roadmap easier to evaluate in partner, investor, and product-strategy conversations.
The acquisition-facing value was narrative and demonstrative, not direct revenue attribution. The broader Markerr Data Studio redesign and product repositioning carried the commercial performance story; Ask Markerr helped make the future product direction visible.
What This Shows About My Product Design Practice
Ask Markerr is the current LLM expression of a pattern I have worked on since my earlier shipped AI/ML work: trust in non-deterministic systems comes from input quality, inspectable reasoning, and the user's explicit right to correct the system.
For a Staff Product Designer audience, the relevant signal is not only the interface craft. It is the upstream judgment: identifying the wrong product framing, turning fuzzy AI ambition into operating principles, defining evidence boundaries, and giving engineering and commercial stakeholders a clearer product object to align around.
Continue through adjacent product systems.
Designing the Trust Layer for Brazil's First Government-Scale AI Audit Platform
Designed the trust layer for Brazil's first government-scale AI audit platform — structured ML inputs and verifiable correction surfaces that cut federal audit cycles by 64% and Audit Instruction writing time by 63%.
Two platforms, one product: B2B pensions for HR and brokers
Shipped dual-platform B2B pension experience in three months: one surface for HR administration, one for broker deal velocity, both on shared foundations.
Ditching Spreadsheets to Make Financial Plans People Can Actually Follow
Led a 3-day design sprint and MVP that replaced spreadsheet-driven financial planning with seven goal-oriented dashboards — cutting manual updates 40%, client confusion calls 30%, and specialist onboarding time in half.