The Roommate & Rental Matching AppPair Pair House
PairPair House is a rental and roommate matching platform designed to address information asymmetry, low trust, and inefficient decision-making in Taiwan’s rental market.
By integrating property search, roommate matching, and landlord management into one system, the project aims to reduce search friction while increasing transparency and safety for all parties involved.
Role:
UX Strategist / UX Designer
User Research · Journey Mapping · User Flow · Usability Testing · Prototype Optimization
Project Type:
Team Project (UX Design Bootcamp)
Date:
Sep - Oct 2025
The Problem We Set Out to Solve
Taiwan's rental market has a well-known problem: listings are opaque, and finding a place is inefficient. But the problem we wanted to solve runs deeper. For first-time renters — college students and young professionals — finding a unit is only half the battle. Finding someone you can actually live with is the harder part. Budget constraints almost always mean co-living with strangers, yet existing platforms (591, Homates, Facebook groups) offer no mechanism for evaluating roommate compatibility before signing a lease. Whether you end up getting along is entirely up to chance.
This was a four-person bootcamp group project. I served as team lead in a role closer to PM than designer. On the research side, I owned interview guide design, in-depth user interviews, HMW synthesis, and insight documentation. On the design side, I owned the entire roommate-matching module — user flow, wireframes, and prototype — covering filter settings, swipe card interface, match notifications, favorites list, and in-app messaging. On the documentation side, I authored and edited the user research, Insights to Design, personas, and user journey map sections of the project brief.
First Hypothesis, and the Competitor That Stopped Us
Our initial target user was the small-scale landlord.
The core hypothesis: landlords needed a lightweight management tool — easy listing uploads, payment tracking, and tenant maintenance requests — to reduce the friction of managing rental properties. Early market scanning turned up a few human-operated services, which gave us confidence there was still room for a product-led solution.
Then we dug deeper into the competitive landscape and found an app called Banana that mapped almost exactly onto what we were building — same target user, same core features, and a more developed business model than anything we had sketched out.
That left us with a choice: differentiate within the same space, or redefine the problem entirely.
I pushed hard for the latter, and I pushed against resistance. My reasoning was straightforward: competing against a feature-complete product on the same turf would reduce the contest to visual polish — and that wasn't what this project was for. Our bootcamp's primary evaluation criteria were research rigor and insight-to-design translation, not interface aesthetics. Given that shared goal, I argued we couldn't afford to take the easy path. The team initially leaned toward a lighter-touch redesign to save time, but ultimately agreed to start over.
Redefining the Target User and Problem Space
The pivot started with a pragmatic observation: the most accessible research subjects in a bootcamp environment were our fellow students — people with lived experience directly relevant to what we were now considering. We tested the direction informally first, talking to one or two classmates about their rental experiences. Once we confirmed there was real pain worth excavating, we committed: our new target user was 18–30 year-olds with experience co-renting with strangers, either as students living away from home or as young professionals in their first shared apartments.
We ran five in-depth semi-structured interviews alongside a 19-response survey. The findings converged on something the existing platforms had almost entirely ignored.
The core pain wasn't finding a unit — it was living in one. Incompatible cleaning habits, disagreements over pets, rotating chore schedules, the awkwardness of a roommate bringing a partner home. Interviewees didn't demand a roommate who was exactly like them, but they had firm, specific boundaries around particular habits — and they wanted those boundaries established before move-in, not discovered after. The survey confirmed the scale of the problem: 84.2% of respondents said finding a suitable roommate was a major frustration, and 73.7% were still relying on personal networks or private social channels to find one.
A second finding shaped the product just as significantly. When asked how they searched for listings, respondents described a deliberate, focused ritual: set aside a block of time, sit at a computer, filter platforms for candidates, build a shortlist, rank them, schedule viewings in order. House-hunting was a concentrated decision-making activity — not casual scrolling. The survey reflected this clearly: 94.7% of respondents said a list-based interface helped them compare listings effectively, and 89.5% preferred browsing multiple listings at once in list format.
From Insight to Design Decision
These findings drove two consequential design decisions.
Building a roommate-matching feature
This was the direct response to the compatibility pain we'd uncovered — a structured alternative to the current approach of relying on introductions or moving in blind. The survey gave us further confidence: 63.2% of respondents said combining housing search with roommate matching on one platform would be genuinely convenient. The feature used a semi-verified identity model: landlords and lease signatories required real-name verification for platform trust and legal validity, but the roommate matching flow used self-chosen nicknames, preserving privacy while allowing people to connect.
One design tension worth naming explicitly: we dropped the swipe card for listings, but swipe may actually be the right mechanic for roommate matching. The reasoning is behavioral. Browsing listings is a rational, high-stakes decision process — users want control and comparison. Finding a roommate is closer to social interaction, and the behavioral template established by dating apps already exists: swiping to evaluate strangers is a familiar, low-friction act. Applying that same mechanic to roommate profiles could meaningfully lower the psychological barrier to disclosing personal habits, making the action feel like filling out a social profile rather than exposing private information to a stranger.
If this product had launched, I would have set the roommate-matching conversion funnel as the primary metric to track — completion rates at each step from entering the feature to opening a conversation after a match. That funnel data would directly answer whether our core assumption held: that users are willing to disclose their living habits in exchange for better roommate outcomes, and if not, exactly where the friction lives.
Dropping the swipe card for listings, doubling down on the list
We had originally hypothesized that a Tinder-style swipe interface would let users browse listings in spare moments throughout the day. The survey data killed that assumption — 94.7% preferred list-based browsing — and the interview finding that house-hunting was a focused, intentional activity made the case even stronger. There was no evidence to justify disrupting an established behavior pattern. We redesigned around a list interface with a multi-layered filter system and saved filter records, giving users more control over the deliberate process they were already running.
What Testing Revealed, & What We Didn't Get to Fix
Usability testing across three modules surfaced problems at different levels.
In the Find a Home module, the main issues were comparison flow complexity — users found adding comparison criteria more effortful than expected — and a lack of state feedback after completing a booking. Users couldn't tell whether their action had registered. Both pointed to the same underlying gap: the interface wasn't confirming that things had worked.
In the Landlord Dashboard module, the placement of tenant information wasn't intuitive — several users looked in the wrong section — and the term "tenant" was ambiguous enough that users couldn't distinguish between current residents and prospective viewers. Confirmation feedback after accepting a booking was absent, leaving the same uncertainty seen in the renter-side flow.
Given the test findings, my prioritization call would have been: swipe interaction clarity and post-action feedback (booking confirmation, match notification) first, as it's high impact, and low engineering cost. Messaging entry point discoverability second. Information architecture restructuring, the collect-then-compare flow, would be last, because that requires structural redesign and carries more risk within a constrained timeline.
In the Find a Roommate module, the findings were more numerous. The swipe direction conventions weren't self-evident — multiple users didn't know which direction meant "like" versus "pass." The gender field appeared twice during profile creation, prompting confusion about why the platform needed it again. The post-match screen label "Roommate List" was misread by at least one user as a list of current housemates rather than matched candidates. And the messaging entry point required multiple attempts to locate.
We had under two days for revisions, with one of those days already spent on planning and running the tests. That constraint forced an explicit triage: anything requiring structural rearchitecting was deferred. We focused on surface-level improvements that could reduce cognitive load without touching the underlying architecture, for example, adding dimmed overlays for modal confirmations, improving button contrast and type legibility, adding onboarding guidance for the swipe interaction, and replacing ambiguous icons with more semantically standard alternatives. The scope of change was limited, but each decision had a clear rationale.
An Unsolved Deeper Question
The deeper open question, "whether users will willingly disclose personal habits in a roommate-matching context", remains unresolved. The testing conditions weren't designed to answer it, and the prototype wasn't live enough to observe real behavior. But the behavioral analogy to dating apps gives us a reasonable prior: this generation has already normalized swiping through stranger profiles and completing personal-preference questionnaires in social contexts. The framing matters. If the matching interface signals "this is how you find a compatible roommate" rather than "this is where you expose your private habits," the disclosure threshold likely drops considerably.
That's the hypothesis I'd want to test first if PairPair House moved forward.
Make a Contact Today
Want to learn more about my design?