Landeed UI

Context

Property ownership in India is fragmented across state portals, sub-registrar offices, municipalities, lawyers and agents.

The concept explored how Landeed could move beyond being a place where owners simply store documents toward becoming a proactive property-management platform.

The competitive reference point was DigiLocker, which primarily stores and displays documents rather than proactively identifying and resolving property-management risks.

Problem

The business/product challenge was:

How might Landeed create enough ongoing value and trust that property owners return to the product beyond simply retrieving documents?

The research identified high-stakes moments such as:

• An owner needing an emergency property record during a transaction.

• A loan being delayed because of a legal-record mismatch.

• Uncertainty around title health.

• Property-management tasks that continue after the initial purchase.

My role

My role: Product Designer / UX Researcher
I owned: Competitive research, user journey mapping, opportunity definition, product concept, UX strategy, interaction design, monetization concept and design system.
Collaborated with: Solo project.

Research & insights

A competitive teardown of DigiLocker established a key strategic gap:

Document storage solves access; it doesn't necessarily solve property ownership.

I mapped the broader property lifecycle:

Acquire → Own → Maintain → Sell

and attached metrics and hypotheses to each stage.

Four high-stakes bottlenecks were identified using a Deal-Breaker Bottleneck lens, particularly situations involving financial loss, time pressure or fraud-related fear.

Product opportunity

The opportunity was to shift the product from:

"Where are my property documents?"

to:

"Is my property healthy, and what do I need to do next?"

That led to the concept of a Property OS — a proactive layer that identifies issues, explains them and guides owners toward resolution.

Design principles

1. Replace document visibility with actionable confidence.

2. Make complex property risk understandable at a glance.

3. Never hide resolution progress.

4. Build recurring value beyond the transaction.

5. Make monetization part of the product model, not an afterthought.

Key decisions

Decision: Title Health Score
Alternative: Display individual property documents and statuses.
Why: Owners need a high-level answer to "How healthy is my property?" before navigating individual records.

Decision: Issue → Resolution flow
Alternative: Simply flag issues.
Why: Identifying a problem without helping users resolve it doesn't create enough product value.

Decision: Visible progress stepper
Alternative: Generic status message.
Why: Property/legal processes can be opaque; users need to understand where they are and what happens next.

Decision: Periodic Maintenance Services
Alternative: One-time document transaction.
Why: Property ownership is an ongoing lifecycle, creating an opportunity for recurring product value.

Decision: Explicitly cut AI litigation agents and other ideas
Alternative: Expand the concept with every potentially differentiating feature.
Why: The sprint required focus on the highest-value property-management problems rather than feature breadth.

System/architecture

The concept connects:

Property → Health → Issue → Resolution → Maintenance

The Title Health Score acts as the entry point.

A detected issue leads into a structured resolution flow involving relevant verification or documentation, while Periodic Maintenance Services creates an ongoing relationship after the initial issue is resolved.

Final experience

The final concept includes:

• Property Health Score

• Issue detection

• Resolution workflows

• Escrow confirmation

• NOC verification

• Encumbrance certificate tracking

• Progress stepper

• Tiered resolution services

• Periodic Maintenance Services

• Supporting design system for light/dark modes

The result is positioned as a Property OS rather than a document repository.

Validation

This was a 3-day design sprint, not a shipped product.

The portfolio documents competitive research, journey mapping, hypotheses and product reasoning, but does not document live usability testing or post-launch validation.

The next validation step would be testing whether the Title Health Score and resolution workflow actually increase user trust and willingness to return.

Impact

The project delivered a coherent Property OS concept within three days, including the trust model, resolution workflow, recurring-service concept and supporting design system.

No production business metrics are documented, so I would not claim conversion, engagement or revenue impact on the portfolio.

What I learned

The strongest product opportunities often come from asking what users need after the obvious transaction is over - not from making the transaction itself slightly better.