REALEASE AI
A unified platform that cut coordination friction for realtors and buyers.
01 — Overview
Property transactions involve realtors, buyers, and a mess of disconnected tools holding the process together — one platform for listings, another for documents, another for messages, with no shared source of truth between them. Realtors lost time on administrative overhead instead of client relationships; buyers had no reliable way to trust the information or people they were dealing with.
I led the UX/UI design and research for RealEase.ai — from persona and journey research through wireframes and final interface design — working alongside two engineers who handled development.
Role: UX/UI Designer — research, personas, journey mapping, wireframes, UI design
Status: Class project, not shipped
Type: Web Platform · Real Estate · Multi-user (Realtor + Buyer)
Problem
Realtors and buyers had no shared platform, just fragmented tools and no source of truth.
Solution
Designed a unified platform built around verified profiles, centralized documents, and AI-assisted communication.
Results
Research-backed design decisions, validated against usability heuristics — not live user testing.
Constraints
This was a semester-length class project with a three-person team — no dedicated research budget, no live users, and a hard deadline. Rather than aim for a fully validated, production-ready product, I prioritized depth in research and interaction design over breadth of features, and scoped the UI to what could realistically be designed and reasoned through in the time available. Formal usability testing wasn't conducted; design decisions were evaluated against usability heuristics instead, with testing flagged as the clear next step if this were taken further.
02 — The Problem
The process looked manageable. Until you tried to actually buy or sell a property.
Every step required a different tool. Listings lived on one platform. Documents got emailed as PDFs. Questions went through texts, calls, or whatever channel was fastest in the moment. No single source of truth existed for either side of the transaction.
For realtors like Sarah, this meant administrative overhead ate into the time that should've gone to actual client relationships — chasing documents, answering the same buyer questions over and over, juggling multiple listings across multiple tools.
For buyers like Alex, it meant uncertainty at every step: was this realtor legitimate? Was this listing accurate? Was there something in the disclosure documents he was missing because no one had walked him through them clearly?
Two sides of the same transaction, solving the same problem separately — with no shared platform connecting them.
That was the gap RealEase.ai set out to close.
Design considerations:
One platform, not several disconnected tools
Reduce coordination overhead specifically placed on realtors
Give buyers a reason to trust the people and information on the platform
Build for a market already shifting toward digital-first expectations
03 — Research and Goals
Validating the problem first
Before designing anything, I ran research to confirm the problem was real, not assumed. Survey feedback from prospective buyers and realtors was direct:
67%
reported difficulty understanding property documentation
100%
said they needed help understanding property disclosures
67%
reported minor mismatches during home inspection
That data confirmed something specific: the friction wasn't about finding listings — it was about understanding and trusting the documentation tied to a transaction. That reframed the whole design direction, from "build a better listings site" to "build a platform people can actually trust with paperwork."
Giving the problem a face
To keep design decisions grounded in real people rather than abstractions, I built two personas:
Sarah Mitchell, 38 — Realtor. 12 years in San Francisco's residential market. Buried in administrative overhead — managing documents across listings, fielding repetitive buyer questions — time that should've gone to client relationships.
Alex Rodriguez, 28 — Buyer. First-time homebuyer, tech-comfortable but overwhelmed by disclosures and unsure whether the realtors and listings he was seeing were legitimate.
Despite sitting on opposite sides of a transaction, both needed the same thing: clarity and trust in a process that otherwise felt scattered and opaque. That shared insight — not two separate feature wishlists — became the foundation for the platform's core direction.
Goals derived from this research:
Give realtors a single place to organize and share property documents
Give buyers verified, trustworthy realtor and listing information
Reduce repetitive back-and-forth communication for both sides
Scope tightly: build the core trust-and-communication features well, rather than the entire transaction lifecycle
Features explicitly scoped as future work (not designed in this phase): AI-driven document recommendations, completeness scoring, in-app bidding.
04 — User Flow & Information Architecture
Mapping the full transaction first
Before designing a single screen, I broke the entire property transaction down into its individual steps — deciding to buy or sell, pre-approval, listing agreements, disclosures, escrow, walkthroughs, mortgage, closing — to see the full picture before deciding what the platform should actually own.
This synthesis surfaced a key structural decision: rather than designing around the entire transaction lifecycle (which would have been unrealistic for the platform's scope), I focused the IA around the steps with the most friction — document handling, verification, and communication — while leaving downstream steps like closing and mortgage largely outside the platform's core flow.
That scoping directly shaped the user journeys mapped for both personas:
From synthesis to structure
That scoping decision shaped two separate user journeys, since realtors and buyers move through the platform differently even when interacting with the same underlying data:
The platform's underlying structure — user authentication, listings, document handling, and AI-assisted chat — was built collaboratively with two engineers, which informed how I scoped the IA around what was technically feasible within the project timeline.
Design considerations:
Scoped the IA to friction points identified in research, not the full transaction lifecycle
Separate journeys for realtors and buyers, sharing one underlying data structure
Verification and document handling treated as core, not secondary, features
05 — Wireframes
From sketch to screen
Wireframing started on paper, not in Figma. Early sketches let me work through layout options quickly — where listings, documents, and chat would live relative to each other — before committing to anything digital.
From there, I iterated through several digital versions, refining hierarchy, navigation, and content density with each pass. Some early versions were denser, prioritizing information visibility; later versions simplified toward a cleaner dashboard structure once it became clear that document access and communication needed to feel lightweight, not like a filing system.
Design considerations:
Paper sketches first, to separate structural decisions from visual polish
Low-fidelity wireframes for the two most structurally important screens, to lock hierarchy before visual design
Greeked content (no real copy/prices) to keep focus on layout, not final wording
06 — Key Design Decisions
Six core screens carried the platform's main flows for both personas — three for realtors managing listings and documents, three for buyers browsing, requesting information, and getting answers.
Homepage
Buyers can search or browse listings by address, area, zip, or neighborhood — prioritizing flexible discovery over a single rigid search path, since buyers like Alex don't always know exactly what they're looking for yet.
One listing, two roles
The clearest example of designing around both personas at once: the same property page adapts entirely based on who's viewing it.
For Sarah, the listing surfaces "Send Packaged Documents" and a toggle to enable chat per buyer — giving her control over what gets shared and with whom. For Alex, the same layout instead surfaces "Request Documents" and "Chat with RealEase.ai" — giving him a direct way to ask rather than wait. Same data, same structure, two purpose-built sets of actions.
Same listing, two roles. Drag to see the difference.
Sending documents to specific people
"Send Packaged Documents" opens a recipient picker — realtors search by email and choose exactly who receives the document set, rather than sharing broadly or relying on a generic link.
This gave Sarah the same control over document distribution that she'd expect from email, without leaving the platform to get it.
Upload Document
A drag-and-drop upload flow, with document type selection and clear file requirements shown upfront. Kept deliberately simple — one clear action, minimal steps — since this was one of the most frequent actions a realtor would repeat across multiple listings.
Realtor Profile
Realtors can view their properties and manage buyer-specific permissions in one place — including a per-contact toggle for whether a given buyer can chat, not just a single platform-wide setting. This gave realtors like Sarah fine-grained control over communication without needing to manage it outside the platform.
Design considerations:
The same listing view restructures its actions entirely based on user role, rather than using one generic layout for both
Every core action (upload, request, chat, share) accessible in as few steps as possible
Per-contact permissions (not just per-listing) gave realtors real control over who could reach them and how
07 — Final UI
Two interactions in one view: toggling chat access on or off for a listing, and opening the document upload flow — both handled inline, without leaving the page or interrupting whatever else the realtor was doing.
08 — Reflections
What I learned
The strongest insight from this project didn't come from either persona alone — it came from realizing Sarah and Alex needed the same thing from opposite directions. Most of the platform's core decisions (verified profiles, centralized documents, role-based views on the same listing) trace back to that one shared insight, not a feature checklist. Good design decisions usually come from finding the one thing two very different users actually agree on.
What I'd improve
Scoping was necessary, but it meant some features stayed conceptual — bidding, document recommendations, completeness scoring — flagged as future work rather than designed in depth. If I extended this project, I'd want to actually design those flows rather than leave them as labels on a feature list, since "future scope" is an easy place to hide real design questions I didn't have time to answer.
What I'd test next
Every decision here was reasoned through research and heuristics, not validated with real users. The realtor/buyer role-based listing view, the upload flow, the permission toggles — all of it would benefit from actual usability testing to see whether the friction I designed against was the friction people really felt, or just the friction I assumed they'd feel.
