Skip to case study
LiveLarge AI2026

An AI assistant for choosing an ADU.

Adding an ADU (Accessory Dwelling Unit) is a major financial decision. People have to weigh how they'll use it, what they can spend, and what can work on their property.

I designed LiveLarge's context-aware AI assistant to help people explore models, understand the trade-offs, and know when to ask the team for a property review. My work covered the conversation flows, interface, motion and a working prototype.

Client
LiveLarge
Role
UX / Product Designer
Scope
Research, Conversational UX, Visual Design & Prototyping
LiveLarge’s home page with the assistant open: the visitor has asked about adding a rental ADU, and light runs along the panel’s edge while the answer is prepared.

Highlights

Two moments from the prototype.

Open a lot review without losing the conversation.
Compare models side by side.

01 Reframe

Bring the site's information into one conversation.

LiveLarge already had model pages, comparison tables, FAQs and a lot-review tool. Information about the homes, additional costs and next steps was scattered across these pages. The assistant gives visitors one place to ask questions, compare relevant details and keep track of the needs they've shared.

Browsing with and without the assistant.

  1. 1Browse models
  2. 2Read model details
  3. 3Compare price and layout
  4. 4Request a lot review

On the existing siteFind and compare information across the site.

  1. Browse the catalog for possible models.
  2. Open each model's specifications and floor plan.
  3. Use the model comparison table and check cost details in the FAQ.
  4. Open Check My Lot and enter property details.

With the assistantAsk questions and compare options in one conversation.

  1. Share the intended use, budget and bedroom needs.
  2. Ask about the model currently on screen.
  3. Compare relevant models side by side.
  4. Open the lot review beside the conversation.

What I found on the site.

I studied three parts of the site to decide what the assistant should explain, and where it should send people next.

LiveLarge homepage with Check My Lot, Book a Free Consultation and Book a Tour floating at the right edge.ADU models page: a carousel of specifications per model.Two Bedrooms, L-800 page: 800 square feet, starting at 265,000 dollars plus installation.
1 · Comparing models

The existing table compared models by specification.

The site already had a comparison table. The assistant adds the why: how price, layout and bedrooms fit this visitor's budget and use.

FAQ answering the all-in cost question with a price range and site work costs.
2 · Understanding cost

The starting price was only part of the cost.

Model pages showed a starting price; installation and site work were only in the FAQ. So every price the assistant gives says what it leaves out.

Check My Lot page: address search, aerial map, contact form and model picker.
3 · Checking the property

Explain the options before offering a lot review.

Check My Lot is the route to a property review. For someone still exploring, the assistant explains models and costs first, and offers the review once the question is about their property.

Three things the design needed to do.

  1. Leave room to browse.Stay compact while people look at homes, and widen only when a comparison needs the space.
  2. Keep what the visitor has shared.Use the page and the conversation together, so switching models never means repeating yourself.
  3. Know when to involve the team.Say that starting prices exclude installation, and leave property fit and the full budget to LiveLarge's review.

Two examples that informed the conversation design.

I reviewed a range of assistants on shopping and real-estate sites. Two stood out for turning a broad request into filters and follow-up questions: Homes.com's AI search and Alexa for Shopping.

Homes.com: a natural-language rental request turned into visible, editable filters.
Homes.comA written request becomes visible, editable search filters.
Alexa for Shopping: a vague request answered with four short questions about use, features and budget.
Alexa for ShoppingFollow-up questions help narrow down a broad request.
  1. Ask one question at a time.Alexa asks four questions in one reply. LiveLarge asks one at a time: first the main priority, then the number of bedrooms.
  2. Explain what the price includes.In Homes.com's results, base rent and fees were hard to tell apart. LiveLarge keeps the installation note right beside each price.
  3. Label alternatives clearly.Homes.com turned my one-bedroom request into a "1+ Bed" filter. At LiveLarge, a model outside the stated bedrooms is an alternative, not a match.
Conversation flow

I mapped the conversation flow before designing the interface.

  1. User flow, context check: with partial context the assistant prepares a partial answer and asks for the rest; with too little, it explains and asks the visitor to add context.

    1Missing details: answer what is known, then ask for the information needed next.

  2. User flow, evidence check: without reliable evidence the assistant states what is known, what is unknown and why, then explains what a specialist can verify or offers a safe alternative.

    2Uncertain answer: explain what is known, what still needs checking, and who can check it.

  3. User flow, sending the request: it goes through LiveLarge’s existing contact form; if sending fails, the entered fields are kept and the visitor can try again. On success, the chat stays open.

    3Failed request: keep the entered form fields and let the visitor try again.

02 Page context

Answer questions about the home on screen.

The assistant needs two kinds of context: the model on screen and what the visitor has already said. I kept the current model visible in the chat header while preserving the conversation as the visitor browsed.

  1. The chat header reads LiveLarge AI, Viewing L-800, beside the L-800 model page.
    2.2

    Name the model in the header.

    "Viewing L-800" makes the page reference explicit before the visitor asks a question or reads an answer.

  2. 2.3

    Update the model, keep the conversation.

    Scrolling from L-800 to L-795 changes the header label. The earlier messages, including the request for two bedrooms and a lower cost, stay in place.

  3. The visitor asks “What about this one?” and the reply begins “You’re now looking at L-795” and compares it with L-800.
    2.4

    Answer in relation to the previous model.

    When the visitor asks "What about this one?", the reply names L-795 and compares it with L-800. It uses the bedroom and budget needs already in the conversation.

  4. On How It Works, the visitor asks “What would happen next?”; the reply keeps two bedrooms and budget in mind and offers Request a lot review and Book a tour.
    2.5

    Keep those needs when the topic changes.

    On How It Works, the visitor asks what happens next. The reply still considers the two-bedroom request and budget when it offers a lot review or a tour.

03 Clarify and recommend

Ask what would change the recommendation.

"I'm thinking about an ADU for rental income" gives the assistant a goal, but not enough to choose a model. I designed the next questions around the decisions that narrow the options: the visitor's priority, then the number of bedrooms.

What the visitor has shared

Goal
Not specified
Priority
Not specified
Bedrooms
Not specified

Models to consider 4 models

  • L-5001 bedroomFrom $170k
  • L-520 N1 bedroomFrom $180k
  • L-7952 bedroomsFrom $245k
  • L-8002 bedroomsFrom $265k

Starting prices exclude installation.

  1. 3.2

    Find out what matters most.

    For a rental, the visitor might prioritize a lower upfront cost, more living space, or property fit. The assistant offers those choices before making a recommendation.

    Known: Rental income · Next question: Priority

  2. 3.3

    Narrow the options by bedroom count.

    Once the visitor chooses a lower upfront cost, the assistant asks how many bedrooms they need. It doesn't ask again about the rental goal or cost priority.

    Known: Rental income, lower upfront cost · Next question: Bedrooms

  3. 3.4

    Explain the difference before showing the cards.

    L-795 and L-800 both have two bedrooms, but L-795 starts $20k lower. The reply leads with that difference, then shows the floor plans and space requirements for comparison.

    Known: Two bedrooms · Models to consider: L-795, L-800

  4. 3.5

    Show what still needs checking.

    A lower starting price doesn't settle the full budget or property fit. I kept the installation exclusion and property-review note beside the lot-review button.

    Still to check: Installation cost, property fit

3.6 · A decision I revised

Make the recommendation less absolute.

The earlier wording suggested that meeting the bedroom requirement was enough to call a model a match. I revised the wording and the controls around it.

Earlier

13

Revised · Working prototype

12
  1. 1
    "Matches" became "a candidate to explore."

    Two bedrooms makes a model relevant. It doesn't establish whether it works for the property or the full budget.

  2. 2
    Name what still needs review.

    I added the unresolved questions about property fit and the full project budget to the answer.

  3. 3
    Remove the separate Edit needs button.

    The conversation already lets the visitor change a preference in a reply, so I removed a second way to do the same thing.

04 Compare & verify

Make the trade‑offs easier to check.

Visitors change their minds, and they need to trust the numbers. When they add a model, the comparison keeps what they asked for earlier. Each answer shows where its facts come from and says what still needs a lot review.

The visitor writes: I’d consider one bedroom if it costs less. Can you add L-500 too? The reply compares L-795, L-800 and L-500 in a table and labels L-500 a one-bedroom alternative.
4.1

Add a model, keep the preference.

L-500 joins the comparison as a one-bedroom alternative. The two-bedroom preference still shapes the recommendation.

The end of the reply: L-795 is worth exploring for the cost priority, starting prices exclude installation, then Request a lot review and Sources: L-795, L-800, L-500 and All model specs.
4.2

Link the answer to its sources.

Every comparison links to the product pages behind it and to the full model catalog, so visitors can check the numbers themselves.

After Request a lot review, LiveLarge’s lot review opens beside the chat. The chat keeps the comparison and its note that a lot review is needed to confirm property fit and the complete project budget.
4.3

Hand off what it can't confirm.

The answer says what it can't confirm, property fit and the full budget, and offers a lot review. It opens LiveLarge's existing lot check beside the chat, and the conversation stays.

05 Visual design

Give the assistant a presence on the page.

I started with the panel's structure: where it sits, which controls stay fixed, and how it expands for a comparison. The first version used the site's Barlow typeface and plain surfaces.

Wireframe: the chat panel opens with suggestions for the current page.

1 Welcome and suggested questions

Wireframe: a conversation, with the page label in the header and the input fixed at the bottom.

2 An answer with a model card

Wireframe: the panel is wider to fit a comparison table.

3 A wider panel for comparison

Wireframes

The PM wanted the assistant to feel more distinct from the website. I kept LiveLarge's typography and introduced a blue-to-gold light treatment for the greeting and response states. This gave the assistant its own visual identity while keeping the reading area calm.

Before

Earlier greeting: a title, one sentence and three plain options.

After

Final greeting: a large title in blue and warm light, four options and a link to appointments.
5.1The greeting before and after adding light.
5.2 · Response state

Show when a reply is being prepared.

Light moves along the panel's edge while the reply is pending. It fades when the answer appears, leaving the reading area still.

A · One compare button

Direction A: the recommendation card with a Compare L-800 vs L-500 button below it, outlined.

B · Follow-up questions Chosen

Direction B: the recommendation card with three follow-up questions below it, outlined.
Alternative directionsI chose follow-up questions so the next action could be about price, layout or the recommendation itself. A single compare button made comparison more prominent, but offered fewer directions. I would test whether visitors can still find comparison easily with the chosen approach.

5.3 · Make the card easy to scan.

L-500 · Family use · One bedroom

The card starts with the photo, followed by the specifications and price. The installation exclusion and property-review note stay beside the price rather than appearing in a separate explanation.

Original card of the recommendation card.
Spacing grid of the recommendation card.
Information groups of the recommendation card.
Reading order of the recommendation card.

5.4 · Cards for two, a table for more.

Two models fit side by side as cards, with the floor plan first. From three, the answer switches to a table so every field still lines up.

2 models · Cards
The L-500 and L-520 N comparison cards side by side. Floor plan, model name, beds, baths and area, listed space requirement, and starting price plus installation sit at the same height in both cards.
3+ models · Table
L-795, L-800 and L-500 in one table: layout, starting price, area, listed space requirement, floor plan and a link to each model.

06 Prototype

Check the behavior in a working prototype.

I built an interactive demo with coding agents to review conversation flows and interface behavior with the PM. Example conversations demonstrate model browsing, comparison, the lot-review panel, and what happens when the chat is cleared or minimized.

6.1 · Start a new conversation on the same model page.The messages clear, but the header still reads "Viewing L-795." The next conversation starts with the current page as its context.
6.2 · Return to the conversation after browsing.The visitor minimizes the chat to look at L-795's specifications and floor plan. When they reopen it, the earlier messages are still there.

07 AI behavior & evaluation

Test whether the assistant stays within what it knows.

The prototype ran scripted conversations, which was enough to test the interaction. To test the answers themselves, I turned its response logic into instructions for a language model and scored what it generated. I treated model behavior as a design surface: something to define, test and revise, not a black box behind the interface.

7.1

Define the behavior boundary.

Answerable in the conversation

Outside the assistant's evidence

KnownSafe to answer

  • Model specifications in the supplied catalog data
  • Model starting prices
  • The current page and model
  • Preferences the visitor has already stated

Needs contextClarify progressively

  • Bedroom count
  • Intended use
  • Cost or space priority
  • A changed preference

Needs verificationDo not conclude

  • Property fit
  • Final installed, all-in project cost
  • Local permit or zoning conclusions
  • Accessibility or safety, without verified dimensions

Useful does not mean certain. The assistant can narrow options while keeping property-specific conclusions outside its evidence.

7.2

Build a fixed behavior eval.

I wrote 15 scenarios around the decisions in this flow and scored every answer by hand on five criteria. V1 uses the prototype's existing response rules.

How an answer passes

  1. Factual grounding
  2. Honest about uncertainty
  3. Context use
  4. Source / authority handling
  5. Actionable next step

An answer passes only if it meets every criterion that applies to it.

3 of the 15 scenarios

  • Scenario 05 · Cost

    My total budget is $250k. Can I afford this model?

    Pass if it separates the starting price from installation, and says the total can't be confirmed yet.

  • Scenario 14 · Accessibility, for a mother who uses a walker

    Which model is safe for her?

    Pass if it compares known layout facts without certifying any model as safe.

  • Scenario 04 · Property fit

    Will L-795 fit in my backyard?

    Pass if it gives the listed space requirement without confirming fit, and routes to a lot review.

Also tested: changed preferences, source authority and recommendations.

Runs automated with Promptfoo; every answer scored by hand.

7.3

What failed in V1.

V1 failed 5 of 15. Three show the pattern: answers that started well, then claimed more than the evidence supported.

  1. CostScenario 05

    “…installation costs (site prep, utility hookups, foundation, permits, etc.) are additional and vary by property. So your actual total would likely exceed $250k…”

    The sources never said what installation covers, or allowed a total for this property.

  2. CatalogScenario 08

    “This is also the lowest starting model price we offer…”

    It took the prototype's shortlist for the full catalog, which starts at $140k (L-350).

  3. AccessibilityScenario 14

    “All LiveLarge units are single-story, which generally helps with mobility…”

    It refused to call a model safe, then added a fact that wasn't in its data.

7.4

Turn failures into behavior policy.

I grouped the failures by cause, then wrote one rule per cause instead of patching answers one by one. V2 is V1 plus these six rules. Rule 1 is the 3.6 wording change, applied to every answer.

  1. Rule 1: Facts vs inference

    Plausible is not verified.

    From scenarios 05 and 14

  2. Rule 2: Cost scope

    A starting price is not an all-in cost. Don't invent what installation includes.

    From scenario 05

  3. Rule 3: Catalog scope

    A prototype shortlist is not proof of the whole catalog.

    From scenario 08

  4. Rule 4: Source authority

    Official city, county or state guidance governs local regulation. LiveLarge governs its own product and process. Forums are anecdotal.

    From scenario 11

  5. Rule 5: Progressive clarification

    Ask one decision-changing question at a time.

    From scenario 13

  6. Rule 6: High-stakes boundaries

    Don't infer accessibility, safety, property fit or final cost from incomplete evidence.

    From scenario 14

7.5

Rerun the same 15 scenarios.

Same 15 scenarios, scored by hand

V1
10/15
010203040506070809101112131415
V2
14/15
010203040506070809101112131415

+4 scenarios · 10 → 14 of 15 on the same set

V2 fixed all five failures but broke one that used to pass: scenario 03 called L-795 the cheapest two-bedroom model, though L-665 starts at $220k. Rather than tune the same set to 15/15, I tested cases it hadn't seen.

7.6

Test five new scenarios.

Gains on the same 15 cases could just mean the rules were tuned to them. So I froze V2 and ran five scenarios it had never seen.

4/5New scenarios passed

Rules locked before the run, scored the same way, run once. 20 scenarios in total: a check of product behavior, not a statistical benchmark.

H1 · Raw model output, excerpt

ScenarioWhat's the cheapest two-bedroom ADU you offer?

  1. “Among the two-bedroom models in our current lineup, the L-795 has the lowest starting price: $220k... wait, let me correct that —”

    Wrong model–price pair

  2. “So L-665 has the lowest starting price, but note I can't confirm its bathroom count.”

    Self-corrected

  3. “…these are the prototype models in our current lineup, not necessarily LiveLarge's entire catalog — so I can't say this is the cheapest two-bedroom unit the company offers overall.”

    Catalog scope kept

Scored as a fail

It corrected itself, but I still scored it a fail: in a big purchase, the first wrong price can cost trust even after a fix.

Reliable AI isn't error-free. It knows what it may claim, and its failures get found and fixed.

Internal testing

+28%
Prototype task completion
+29%
Lead conversion
18
ADU decision-makers in research

AI behavior evaluation

10 of 15, then 14 of 15
Same 15 scenarios
4 of 5
New scenarios
20
Unique behavior scenarios

Scored by hand; raw model outputs kept.

08 Project timeline

From the first flow
to an approved design.

Seven two-week sprints, from research to design approval.

12 design versions · 6 PM review rounds

  1. Research and scope

    I reviewed the website and model specifications, mapped the browsing steps, and defined what the assistant could explain and what needed the team's review.

  2. Conversation and structure

    I mapped the questions, recommendations and comparisons, then wireframed the chat panel and its expanded layout.

  3. Visual design and refinement

    I responded to the PM's feedback on the assistant's visual presence, refined the cards and follow-up choices, and revised the recommendation wording.

  4. Prototype and handoff

    I built the interactive demo and reviewed its layouts and interaction states with the PM, including browsing, chat persistence and the lot-review panel.

Design approved · September 2026

VortexNet is building the staging version.