Client
Dirent
Industry
Proptech
Country
Kenya
Role
Product designer (solo)
Platform
Mobile, iOS and Android
Automating property income
Designing for landlords who manage millions of shillings through WhatsApp messages and memory.
The Problem
In Kenya, most rental income is managed on trust. Over 90% of rent is paid directly to landlords or through agents with no real-time way to verify or reconcile what has been collected. A landlord with five units is reconciling payments that trickle in across SMS, mobile money notifications, and WhatsApp, with some tenants paying in instalments and no single place where the full picture exists. When a payment is disputed, and it frequently is, there is no authoritative record to settle it. The alternative is outsourcing to a property manager, who resolves the problem by taking 5 to 12 percent of collected rent in exchange for doing the administration manually. For landlords whose primary motivation for owning property is passive income, neither option is acceptable. The administration was eating the return.
Role and constraints
I owned the full design process end-to-end: UX research, information architecture, wireframing, and high-fidelity UI. I worked directly with the Dirent founders, who owned the product brief and business logic, translating their vision into a validated design ready for handoff.
Scope
End-to-end product design
The core constraint was trust. Landlords were being asked to hand the management of their primary financial asset to a platform they had never heard of. Every design decision was filtered through one question: does this feel like something a landlord would trust with their rent money?
Research
Tenant surveys were collected through a Google Form disseminated across various platforms to capture a balanced range of experiences. Responses from tenants across five Nairobi properties, combined with research into three local property managers (Mongoose, Real, and Axis), surfaced the core patterns: inconsistent documentation, disputed payments, and a reconciliation process that depended entirely on human memory and WhatsApp threads. Competitor platforms including Baselane (USA) and getmomo (Germany) were reviewed to understand where existing tools fell short for the Kenyan landlord context, particularly around M-Pesa integration and low-friction onboarding for users without formal banking infrastructure.
Two landlord personas anchored the design:
Wanjiku M.
Independent Landlord
Manages 4 residential units. Collects rent manually each month, follows up on late payments via WhatsApp, and reconciles everything in a notebook. Has no visibility into which tenants are consistently late until several months have passed.
David K.
Portfolio Landlord
Manages 12 units across two properties. Uses a part-time caretaker who collects cash and reports back inconsistently. Has experienced disputed payments and one case of rent being pocketed before it reached him.
Over 90%
of Kenyan rent is collected with no digital record. Most landlords have no real-time visibility into what has and has not been paid.
With the user context established, the first major design decision was authentication; how users would log in to a platform handling their rental income.
Rejected
Password-based login
Familiar in SaaS contexts, but adds friction for users unaccustomed to managing passwords on financial platforms. Password recovery introduces additional complexity.
Rejected
OTP via SMS
Round-trip delay on every login. Poor experience for a payment confirmation flow where speed and confidence matter.
Chosen
PIN plus optional biometrics
Mirrors M-Pesa authentication. No new mental model required for the target user.
Authentication decision: three approaches evaluated before settling on PIN-based login to match the mobile money mental model users already trust.
Three decisions that mattered
Profile completion is deferred, not skipped. Landlords can set up at their own pace, with progress saved across sessions until the platform is fully operational.
DECISION 2
Invoice-bound payments
The informal system ran on screenshots and self-declared confirmations, a process that failed constantly through lost messages and disputed payments. Dirent ties every payment to a system-generated invoice. Tenants can partially pay but cannot overpay. The payment is reconciled or it is not. No middle state requiring human interpretation.
TRADE-OFF
No flexibility for ad hoc payments outside the invoice system. That flexibility was excluded because it reintroduced the ambiguity the product existed to eliminate.
DECISION 3
Progressive profile completion
Forcing full profile completion before access was blocking activation entirely. Landlords rarely have every lease, property detail, and bank account to hand when they first open an app. The design allows sign-up with deferred completion, surfacing contextual prompts as each piece of information becomes relevant. Progress is saved continuously across sessions, so a landlord can complete their profile across multiple sittings without losing what they have already entered.
TRADE-OFF
A landlord with an incomplete profile cannot unlock the full value of the platform. The progressive approach reduces abandonment at the setup wall, but the product only delivers its promise once all the information is in. The design mitigates this by making the completion prompts persistent and contextual rather than blocking, nudging landlords toward completion without forcing it all at once.
PIN entry in light and dark mode. A familiar input pattern for anyone who has used M-Pesa, with biometric sign-in available as an alternative.
From structure to final UI. The sketching phase focused on information hierarchy: how to surface collection status, arrears, and transfer data without overwhelming a user who is not a trained accountant.
Final Screens
The full onboarding flow, covering three paths: new account creation by user type, returning user sign-in, and PIN recovery. All three paths converge at the dashboard, with first-time users routed through profile completion before they arrive.
ONBOARDING
Role selection (Landlord, Tenant, Caretaker) with sign-in option on the same screen.
Account creation form with Google sign-up option to reduce friction at registration.
Three-path setup screen covering payment info, properties, and tenant lease info, each with individual progress bars.
PAYMENT
Landlord view showing line items, payment status badge, balance remaining, and timestamped payment history.
Pre-filled amount with quick-entry chips, partial payment note, and PIN confirmation numpad.
Success state after PIN entry. Timestamped receipt confirming amount paid and balance remaining.
RECONCILIATION
Collection summary with progress bar, four stats, arrears list with status badges, and transfer summary.
Breakdown of overdue and partially paid tenants with days overdue, late fees, and outstanding amounts.
Consolidated remittance view showing amount, expected date, and payment channel.
Outcome
Dirent was delivered as a stakeholder-approved MVP. During landlord walkthroughs, users navigated the payment flow without prompting and were able to locate tenant payment status without instruction. The invoice-bound payment model was consistently understood on first exposure, which validated the core design assumption: that a structured record is more reassuring to landlords than a flexible but ambiguous one.
What I learned
The biggest insight from this project was that landlords do not think about rent as transactions. They think about it as money owed and money received. The product had to reflect that mental model, not the one that made sense from a fintech architecture perspective.
Trust is not established through features. It is established through the absence of confusion. Every screen that required no explanation during testing was a screen that had done its job.
