Designing the Trust & Coordination Engine of a Fixed-Fee Real Estate Marketplace
Role
Product Design
CLIENT/ORG
Bricklist Ltd.
Timeline
Apr — Sep 2025
Team
Me, 2 Full stack devs & Marketing
Credit
0 → 1 product, UX, IA & Product Strategy
Tools
Figma, Monday, Sheets
Overview
Bricklist is a fixed-fee real estate platform built as a broker-free model for the Mauritian market. By removing brokers, the product had to provide what people previously relied on them for: trust, coordination, and clarity.
This case study shows how I designed Bricklist as a system, not just an interface.
Bricklist
Want to skip to
01 / Context: Market & Problem
02 / Mapping the Transaction Journey
04 / Execution, Speed & Outcomes
05 / Reflection & Growth
Want to skip to:
Want to skip to
01 / Context: Market & Problem
02 / Mapping the Transaction Journey
03 / Designing the System
04 / Execution, Speed & Outcomes
05 / Reflection & Growth
01
Context: Market & Problem
The Market
In Mauritius, property transactions historically moved through small broker networks, not open listings.
As tourism and foreign capital increased, the change wasn't just rising prices. It was uneven visibility. Well-connected buyers saw opportunities early. Others encountered them late — or after they had progressed elsewhere.
Access didn't disappear.
It became inconsistent.
Structural Pressures Observed
1.
Price Acceleration
Without public reference points, pricing was shaped through conversations instead of comparable listings.
→ Expectations drifted upward and varied widely
2.
Coordination Bottlenecks
Progress depended on agent availability across regions.
→ Delays occurred between steps, not at decisions
3.
Service Fragmentation
Each broker operated differently.
→ Listing quality and clarity varied significantly
The Structural Gap
Agents weren't just intermediaries — they held the process together.
Verified listings
Arranged visits
Relayed offers
Maintained follow-ups
They acted as the transaction's memory.
But the system itself had no shared state
Information
lived in conversations
Progress
lived in follow-ups
Trust
lived in relationships
The market worked — yet participation depended on connections and patience.
The Product Challenge
Bricklist introduced a fixed-fee model, removing continuous mediation. Now the platform had to provide what people previously relied on agents for: clarity + continuity.
How do you turn a relationship-driven market into an information-driven one without losing trust?
02
Understanding Where Clarity Breaks
Methodology
Before designing screens, I tried to understand how a property deal actually moves in practice.
Not how platforms describe it — but how it unfolds across days, actors, and people. I mapped the journey across four actors: Buyer, Seller, Agent, and Time.
Journey Map — 4 Actors
Discovery
Enquiry
Visit
Negotiation
Close
Buyer
Searches listings
Contacts agent
Visits property
Signs contract
Seller
Lists property
Hosts visit
Receives offer
Accepts terms
Agent
Qualifies listing
Brokers contact
Arranges viewing
Relays terms
Maintains memory
Time
Day 1
Day 3–7
Week 2
Week 3–4
Month 2+
Roles Played by the Agents
While agents were seen as facilitators, they were actually performing structural tasks.
1
Maintaining whether a listing was still relevant
2
Synchronising availability between two unrelated schedules
3
Translating intent ("I'm interested") into a next step ("book it")
4
Keeping both sides aligned on what stage they were in
Where Deals Slowed Down
Early Stage — Trust Ambiguity
Buyers had to verify the listing being built.
Is the information complete?
Is the broker credible?
Is the price fair?
What effect happened before engagement
Mid Stage — Progress Ambiguity
After a visit, momentum weakened.
Negotiations moved to informal channels. The deal didn't fail — it just lost pace.
→ The delay lived in the communication
What I Learnt from This...
The problem wasn't property access. It was about understanding across time.
What happened
Was understood across time
What's agreed
Was unclear outside of direct contact
What's next
No structured prompt to move forward
Understanding Where Clarity Breaks
While agents were seen as facilitators, they were actually performing structural tasks
1 / Validating whether a listing was still relevant
2 / Synchronizing availability between two unrelated schedules
3 / Translating intention (“interested”) into a next step (“visit”)
4 / Re-initiating stalled conversations
5 / Keeping both sides aligned on what stage they were in
1 / Early Stage — Trust Ambiguity
Buyers first tried to verify the listing itself:
Is this still available?
Is the information complete?
Is the seller serious?
Most effort happened before engagement.
2 / Mid Stage — Progress Ambiguity
After a visit, momentum weakened:
no shared next step
negotiation moved to scattered chats
follow-ups depended on initiative
The deal didn’t fail.
It drifted.
What I learnt from this...
The problem wasn’t property access.
It was shared understanding across time.
Every participant repeatedly reconstructed context:
What happened
What’s agreed
What comes next
So the product didn’t just need listings.
It needed to carry 'state' between humans.
Not digitizing real estate
but stabilizing a multi-step social process.
03
Mapping the Transaction Journey
01 / System Design
Designing the System
From journey analysis to a structured two-layer product framework that absorbs responsibilities previously handled by brokers.
The journey analysis revealed a simple pattern that shaped everything that followed: two distinct failure modes were occurring at two distinct moments in the transaction lifecycle — and both needed to be absorbed into the product itself.
The Pattern
Overview
Traditional brokers compensated for trust and coordination failures through manual intervention — a model incompatible with Bricklist's fixed-fee structure.
Finding
The journey analysis revealed a simple pattern. Two distinct failure modes, at two distinct moments in the transaction lifecycle — both needing to be absorbed by the product itself.
"Trust broke before engagement.
Coordination broke after."
Core finding · Journey analysis
The Two Failure Modes
These were the two moments where deals fell apart. Both were previously patched by brokers operating manually across both sides.
1 / EARLY STAGE — TRUST AMBIGUITY
At the listing stage, buyers couldn't confidently evaluate whether a listing was worth engaging with. Incomplete information, unverified claims, and absent signals of credibility caused drop-off before any contact was made.
Most effort happened before engagement.
2 / MID STAGE — PROGRESS AMBIGUITY
Once contact was made, neither party had a shared understanding of next steps. Deals dissolved, and both sides blamed ambiguity — not bad intent.
No shared state meant no shared progress.
Design Principles
These two failure modes led to two design principles. Everything that follows was designed to support one of these two goals — nothing exists outside of them.
1 / LAYER 1 · TRUST FILTER
Improve listing quality before buyers engage.
Surface structured, verified information at the listing level so buyers can make confident decisions without needing to contact the seller for basic facts.
Pre-engagement
Quality gate
Listing quality
2 / LAYER 2 · SELF-SERVICE COORDINATOR
Maintain clarity and progress after engagement.
Give both parties a shared view of outstanding items, next steps, and current status — eliminating ambiguity that stalls deals post-contact.
Post-engagement
Transaction clarity
Pipeline
What this means for the design
The product didn't just need listings.
It needed to carry shared state between buyer and seller — an always-current understanding of:
1 /
What happened
2 /
What's next
3 /
What each party needs
So the product didn't just need listings. It needed to carry shared state between buyer and seller — an always-current understanding of what has occurred and what's coming next.
03
Designing the System
02 / Layer 1
Designing Trust Infrastructure
The first breakdown occurred before buyers ever contacted a seller. Most effort was spent verifying whether a listing was worth engaging with in the first place.
Context
Buyers weren't asking the obvious question.
Expected question
"Can I buy this property?"
Actual question
"Can I trust this information?"
In the traditional model, brokers performed this validation manually. They filtered listings, verified details, and acted as an initial trust layer between both parties.
Without continuous broker involvement, the product had to assume that responsibility.
Design Goal
Create enough confidence at the listing level for buyers to make informed decisions before initiating contact.
This meant reducing uncertainty around four things:
1 /
Property quality
2 /
Listing completeness
3 /
Seller credibility
4 /
Information consistency
The objective wasn't simply to collect information.
It was to establish trust before engagement.
Decision 1 / SELLER ONBOARDING AS A QUALITY GATE
Treat onboarding as qualification, not data collection.
Rather than optimizing onboarding for speed, I designed it as a qualification process. Every property entering the marketplace needed to meet a minimum quality standard before becoming visible to buyers.
This shifted onboarding from a form-filling exercise into the first layer of trust infrastructure.
Structured onboarding ensured every listing entered the platform with a consistent baseline of information quality.
01 / SET EXPECTATIONS EARLY. ..
Sellers knew what was required before starting
Property facts, location, amenities, media, and pricing were separated into focused steps instead of presented as one exhaustive form.
02 / BUILD THE LISTING PROGRESSIVELY. ..
Information was collected in manageable groups
Property facts, location, amenities, media, and pricing were separated into focused steps instead of presented as one exhaustive form.
03 / SUPPORT QUALITY AT HIGH-EFFORT MOMENTS
Guidance appeared where seller input shaped listing quality
Media prompts, description assistance, and pricing context supported sellers at moments where incomplete or inconsistent input could weaken the listing.
Decision 2 / STANDARDIZE PROPERTY INFORMATION
Reduce variability — not by limiting, but by structuring.
The onboarding flow still had to account for properties with very different characteristics.
The challenge was to create enough structure for listings to remain comparable without forcing every property into an identical description.
I standardized the information buyers repeatedly needed while preserving space for property-specific details.
Not this
More information.
This
More reliable information.
Standardized listing structures reduced information asymmetry and improved comparability across properties.
01 / CLASSIFICATION
Start with a shared property taxonomy
Property types were selected from predefined categories, establishing the structure used by later fields and listing presentation.
02 / CORE ATTRIBUTES
Make decision-critical information consistent
Bedrooms, bathrooms, rooms, floor, area, and construction details used structured inputs rather than free-text descriptions.
03 / CONTROLLED ATTRIBUTES
Separate comparable attributes from descriptive content
Amenities and standout features were captured as selectable attributes, making differentiators easier to surface and scan.
04 / CONSISTENT OUTPUT
Structured inputs shaped a predictable listing experience
Information collected during onboarding mapped into consistent sections on the buyer-facing listing.
Decision 3 / INCREASE CONFIDENCE THROUGH TRANSPARENCY
Surface what buyers need to know, before they have to ask.
Buyers were doing significant verification work before deciding whether a property was worth pursuing.
Rather than relying on conversations to fill basic information gaps, I surfaced credibility signals, property details, and decision context directly within the listing experience.
01 / PRE-ENGAGEMENT
Verification happened before engagement
Last updated
Last updated
Last verified
Views
Saves
Freshness and activity indicators help buyers judge whether a listing is active and credible before initiating a conversation.
02 / INFORMATION HIERARCHY
Differentiators were designed for scanning
Standout features
Amenities
Nearby places
Important differentiators were surfaced as structured highlights instead of hidden inside long descriptions.
03 / STRUCTURED FACTS
Core property details stayed comparable
Beds
Baths
Area
Property type
Year built
Price / sqft
Standardized attributes reduced guesswork and gave buyers a consistent basis for evaluation.
04 / PROPERTY EVALUATION
Rich media supported independent evaluation
Property images
Floor plan
3D tour
Multiple forms of property media helped buyers understand the space before committing to a visit.
05 / LOCATION CONTEXT
Location context stayed within the decision flow
Map
Nearby amenities
Access indicators
Buyers could evaluate the surrounding context without reconstructing it across external tools and conversations.
06 / NEXT ACTION
Primary actions followed informed evaluation
Message seller
Request tour
Make offer
Key actions remained accessible throughout the experience, allowing buyers to act once they had enough information.
Buyers could evaluate listing credibility and suitability before initiating contact, reducing the verification effort required at the earliest stage.
Layer Outcome
What changed
Listings transformed from simple advertisements into trusted transaction starting points.
The system now absorbed part of the validation work previously performed by brokers, whcih is still a common thing across many real estate apps globally.
Before
Buyers spent most effort determining whether a property was credible.
After
Buyers spent effort deciding whether a property was relevant.
While Layer 1 improved confidence before contact, a second problem emerged once buyers and sellers began interacting.
Resolved
Trust was the bottleneck.
New problem
Maintaining momentum was.
Continue to Layer 2
03 / Layer 2
SELF-SERVICE COORDINATOR
Decision 1 / CREATE SHARED TRANSACTION VISIBILITY
Reduce variability — not by limiting, but by structuring.
Once buyers engaged, a different problem emerged.
Buyer and seller activity affected the same transaction, but each participant needed different information and actions. A single identical dashboard would not reflect how either side actually worked.
I designed role-specific views around a shared transaction state.
Seller's view
01 / SAME TRANSACTION
Both sides referenced the same underlying activity
Appointment
Offer
Listing/property
An appointment or offer existed as one transaction event, even when presented differently to each participant.
Buyer's view
Seller's view
02 / ROLE-SPECIFIC CONTEXT
Shared state did not mean identical interfaces
Seller highlight:
Listing activity
Performance
Incoming actions
Buyer highlight:
Appointments
Wishlist
Saved searches
Offers
Each dashboard prioritized the information and responsibilities relevant to that role.
Buyer's view
03 / STATE CHANGE
Actions updated the transaction, not just the interface
A single action changed what both participants saw and what each needed to do next.
Buyer's offer view
Seller's offer view
Decision 2 / TURN INTENT INTO ACTIONABLE STEPS
Reduce variability — not by limiting, but by structuring.
Interest alone does not move a property transaction forward.
Buyers still needed to translate intentions such as “I want to visit” or “I'm interested in buying” into actions the seller could respond to.
I converted these moments into explicit, structured workflows.
01 / CONSTRAIN THE NEXT STEP
Availability replaced scheduling back-and-forth
Buyers selected from available dates and time slots instead of initiating an open-ended coordination conversation.
Both Buyers & Sellers have the option to cancel or reschedule the appointment.
Choose time
Appointment confirmed
02 / CREATE AN EXPLICIT STATE
Confirmation turned intent into a scheduled event
The completed flow created a defined appointment that could be referenced by both buyer and seller.
Seller's view
Buyer's view
03 / STRUCTURE HIGH-COMMITMENT ACTIONS
The offer flow captured context before submission
A guided sequence collected buyer intent and offer details before creating a formal transaction event.
Make an offer
Basic Info
Your Offer
Make an offer
Basic Info
Your Offer
Decision 3 / REDUCE COORDINATION FRICTION
Reduce variability — not by limiting, but by structuring.
Creating structured actions solved only part of the problem.
Transactions could still stall if participants missed an appointment, forgot a follow-up, or did not know what required attention next.
The coordination layer connected scheduled events, notifications, and outstanding tasks so progress did not depend entirely on manual follow-up.
Seller's view
01 / PLAN
Scheduled activity had a shared operational home
Appointments were organized by date and status, giving sellers visibility into upcoming and unresolved activity.
02 / NOTIFY
State changes triggered relevant communication
Appointments were organized by date and status, giving sellers visibility into upcoming and unresolved activity.
Buyer's Interaction Journey: Goal was to keep buyer engaged from inquiry → offer → sale.
04 / System
Bringing the System Together
The two design layers established the marketplace's operating model.
Before engagement
Buyers needed enough confidence to decide whether a property was worth pursuing.
After engagement
Buyers and sellers needed a shared understanding of what happened, what was pending, and what came next.
These principles shaped every part of the product — extending beyond individual features into a connected ecosystem of tools that supported discovery, communication, scheduling, and ongoing transaction management.
Product Ecosystem
Interconnected systems, not isolated features.
The marketplace was designed as a collection of interconnected systems. Each workspace served a specific participant and role within the transaction.
01
Seller Workspace
Sellers could monitor and act without switching between disconnected tools.
A centralized operational workspace helped sellers manage listings, monitor performance, respond to inquiries, and keep transactions progressing from a single place.
Listing performance
Pending tasks
Active enquiries
Transaction overview
02
Buyer Workspace
Buyers maintained continuity across multiple properties and stages.
Instead of restarting every property search, buyers could organize opportunities, revisit previous interactions, and continue transactions without losing context.
Saved properties
Upcoming visits
Offers
Search history
03
Property Discovery
Filters and consistent listing formats reduced time-to-decision.
Discovery emphasized structured comparison rather than endless browsing. Standardized property information and meaningful filters reduced evaluation effort before engagement.
Structured filters
Standardized metadata
Comparable property cards
Quick scanning
04
Communication System
Property-threaded messaging kept context intact across both parties.
Communication became part of the product rather than something happening outside it. Context stayed attached to each property, reducing repeated explanations and fragmented conversations.
Property-specific conversations
Reduced manual follow-ups
Context preservation
Event-driven notifications
05
Scheduling & Offers
Calendar & Offer Flow
Insert screens here
Structured flows replaced back-and-forth with guided, confirmable steps.
Scheduling visits and submitting offers became structured product workflows with clear progress, confirmations, and next steps replacing ad-hoc coordination.
Appointment booking
Calendar
Offer pipeline
Transaction milestones
Designing at Scale
Reusable systems over one-off solutions.
Designing individual screens solved immediate problems. Designing reusable systems ensured the product could keep growing without increasing complexity.
Component Sheet
Insert screens
01 /
Component System
Reusable components created consistency across listing creation, discovery, messaging, and transaction management while reducing implementation effort.
Patterns & Flows
Insert screens
02 /
Interaction Patterns
Common interaction patterns reduced cognitive load by ensuring similar tasks behaved consistently throughout the product.
Navigation & Hierarchy
Insert screens
03 /
Information Architecture
Different user roles shared the same marketplace while receiving workflows optimized for their responsibilities — reducing complexity without fragmenting the experience.
Desktop + Mobile
Insert screens
04 /
Responsive Design
Patterns were designed to scale across devices while preserving interaction logic, allowing users to switch contexts without relearning workflows.
Specs & Annotations
Insert screens
05 /
Documentation & Handoff
Components, behaviors, and interaction states were documented to reduce ambiguity during implementation and improve engineering collaboration.
Transitions & States
Insert screens
06 /
Motion & Feedback
Motion communicated progress, confirmations, and system status — reinforcing user confidence throughout multi-step workflows.
Outcomes
From optimizing screens to restructuring transactions.
Rather than optimizing individual screens, the project restructured how marketplace transactions progressed from discovery to completion.
Increased buyer confidence before engagement
Through structured and transparent listings that surfaced what buyers needed before asking.
Reduced coordination effort after engagement
With shared transaction visibility and guided workflows that replaced manual follow-ups.
Replaced fragmented manual processes
With reusable product systems that supported buyers, sellers, and future platform growth.
Reflection
I started by designing interfaces for a property marketplace.
I finished by designing the operational systems that enabled trust, coordination, and scalable collaboration between multiple participants.
Key insight
Successful marketplaces are rarely differentiated by individual screens.
They are differentiated by the systems that quietly remove friction across an entire journey.
Layer 1
Trust Infrastructure
Layer 2
Coordination Infrastructure
Result
Fixed-fee marketplace
Two layers.
One goal: close the deal.
Journey analysis revealed a repeating failure. The same two friction points caused deals to fall apart — and traditional brokers patched both manually. Bricklist's fixed-fee model couldn't afford that.
Layer 1 — Designing the Trust Filter
1 / Decision 1: Seller Onboarding as a Quality Gate
Ensure consistent, high-quality listings so buyers can trust the marketplace without human mediation.
In traditional real estate, brokers filter sellers before listings ever reach buyers.
In a fixed-fee platform, that responsibility disappears unless the system takes it on.
Rather than optimizing onboarding for speed, I designed it as a deliberate quality gate.
Takeaway
These insights directly shaped the system architecture:
Layer 1: A Trust Filter to professionalize listings upfront
Layer 2: A Self-Service Coordinator to guide transactions forward
Everything that follows in this case study exists to absorb the work that brokers previously did manually.
Personas
Personas based on....and for future purposes
User Journey
Across our web-app & different competitors, so far seen
Information Architecture
Mapping all the key features & modules, we wanted to add in the first launch version.
User Flow-Therapy(New)
Created a Therapy user flow, including different features in between.
Domain of Creation
Layer 1 — Designing the Trust Filter
Replacing broker-led vetting and professionalism
Decision 1: Seller Onboarding as a Quality Gate
Replacing broker-led vetting and professionalism
This is the canvas where creativity meets functionality. It's where our vision blossoms into an interactive reality. Let's dive into how our user interface design brings forth an engaging and intuitive journey for every user, one tap at a time.
04
IMPACT
Impact-outcome of this project
I concentrated on the before-and-after metrics for this project, which were measured over a span of 2-4 months*
65%
reduction in drop off rates, in the sign up journey(A/B Test)
1.5x
increase in active user base measured before/after 4 months—compared with Webapp
35%
engagement growth(MAU) measured over 45 days
12%
increase in Lead Conversion rate measured over 45 days
80+ avg
NPS Score(from 65+), within 3 months
Deadlines & reliability
