Land Marketplace | 2024-25
OffersTree - a land marketplace designed for high intent users
OffersTree is a land marketplace in the US. It lets sellers list land or request a direct cash offer from ‘OffersTree’, and lets buyers browse, shortlist, and make offers within the platform.
I led the design of Offerstree, from early research through to the live product.
Live on www.offerstree.com
Product
Web App | Mobile App
Skills
Product Design
Stakeholder Management
Interactive prototyping
Testing
My Role
Design Lead
Team
Designer, PM, BA, SDE
Why OffersTree?
The client behind OffersTree has close to a decade of experience in land. She wanted to use that expertise to build something the market didn't quite have for seasoned land buyers. A platform positioned around intent rather than just discovery, and designed to simulate how a real land deal actually happens. Someone makes an offer, both sides negotiate, and it moves toward a close. No detours outside the platform and no broken handoffs.
OffersTree is not for everyone, and that's intentional. If you want to casually browse, it's probably not the right platform. If you want to actually move on a piece of land, it makes a lot more sense.
Research
Time was tight, so we couldn't do an extensive research phase. We ran workshops with multiple real estate agents in the US to get a ground-level understanding of how land transactions actually work. We understood the process, the pain points of a sophisticated buyer and the language people use.
Alongside that, we studied specific platforms for specific things. Opendoor for their forms and how they communicate complex information without overwhelming the user. Several offer-based platforms to understand where negotiation flows break down and create friction.
The research wasn't about finding one product to benchmark against. It was about borrowing what worked from different places and figuring out how to bring it together.
The real positioning shift
Most land platforms like LandWatch, LandSearch, Land.com are essentially lead generation tools. The first meaningful action on almost all of them is "Contact" or "Message." The platform hands you off, and then negotiation happens outside it. Over calls, WhatsApp, through brokers. Unstructured, untracked, and completely outside the product. OffersTree is designed to own the negotiation layer.
The first meaningful action is "Make Offer" or "Get Offers." You start your dialogue with a number and not a conversation. From there, the platform holds the entire exchange: offer submitted, counter-offer, accept or reject. Everything is structured, visible, and inside the product.
It's a category shift compared to traditional platforms that are lead gen tools. That framing influenced every design decision we made. The primary CTA, the negotiation flow, the trust signals, the copy, all of it had to reflect a product that doesn't just help people find land. It helps them close on it.
Who we were designing for
Three personas, but one thing common across all three: high intent. None of them are on the platform to browse.
The primary user is the deal-driven land investor. Someone who scans listings fast, thinks in ROI, and wants to make offers without friction. They don't want to chat. They want to act.
The second is the urgent seller. Someone who inherited land or needs to sell quickly. They're not trying to maximize every dollar. They want certainty, fewer steps, and serious buyers only.
The third is the semi-pro developer. Someone who evaluates land as part of a pipeline, needs to compare options, and takes a bit more time before committing.
One thing we were clear about: if a casual first-time buyer opened the app and felt "this isn't for me," that's fine. That's actually correct positioning.
Removing messaging entirely
Early on, we made a call that felt a bit uncomfortable at the time. No messaging on the platform.
Most marketplaces treat chat as a core feature. It feels like the natural way to connect buyers and sellers. But we saw it differently. Messaging creates a backdoor. People exchange numbers, move to WhatsApp, and the platform loses the transaction entirely. And beyond that, casual back-and-forth produces low-quality offers. People throw out numbers without really thinking them through.
So we removed it. If you want to engage with a listing, you make an offer. That's the only move available to you.
It's a restrictive decision. Some users will find it cold. But it keeps every negotiation inside the product, forces both parties to be intentional, and prevents contact details from leaking before a deal is done.
Optimising the flows
Optimising the flows for ease, clarity and speed was one of the harder design problems.
The kind of information needed to onboard a property is significant. Sellers have two paths. List the property and wait for buyers, or get a direct cash offer from the platform. Both demand a lot of detail upfront. The question wasn't what to collect. It was how to collect it without making the user feel like they're filling out a government form.
A few things helped. We used APN number input early in the flow to auto-fetch some property details. We replaced open text fields with click-to-answer questions wherever we could. We grouped related questions together. The whole thing was designed as a stepper so it never felt like one long form.
The importance of Copy
Going into design, we expected the flows to be the hard part. They were complex, but manageable. What actually turned out to be the hardest part was the copy.
Land transactions carry a lot of legal and financial weight. We made a conscious decision to keep the copy simple. Where technical terms were unavoidable, we made sure the context around them did the explaining.
For example, on OffersTree, we ask for the APN. There isn't really an alternative term for it, so instead of trying to rename it, we added a short hint to explain what it is and where users can find it — usually on their property tax documents. Keep the term accurate, but make it usable.
Across the product, the tone shifts to focus on what the user needs to do, not the terminology behind it. "Due diligence" becomes "We review the property details." "Escrow process" becomes "We handle the paperwork securely with our partner." "Title verification" becomes "We verify ownership details." It has to be accurate enough to be trustworthy, and plain enough to act on. A lot of time went into lines that most users will never consciously notice.
What changed midway
About halfway through, the legal and regulatory framework around land transactions in the US started surfacing in ways we had not fully mapped at the start. Escrow mechanics, title processes, APN specifics, zoning considerations. It forced us to rework several screens.
What I would do differently
Map the legal and regulatory framework before the first wireframe, not alongside it. In a marketplace where users are making real financial decisions, that domain knowledge should be foundational — not something you discover mid-project and work backwards from.