RentalHQ Mobile

01 / OVERVIEW

A focused mobile experience within a broader property-management product.

I initiated RentalHQ after early discovery interviews with two small property owners revealed a fragmented mix of spreadsheets, payment records, tenant information, maintenance notes, receipts, invoices, documents, and separate tools.

As Product Owner / UX Lead, I led discovery, product definition, UX architecture, workflow design, design-system development, and the product experience across desktop and mobile.

Desktop established the broader operating environment first. Mobile followed as a deliberately focused experience built around the information and actions owners need away from their desk.

The second challenge was cross-platform: preserve business logic, workflow state, information meaning, and task outcomes while using Material Design 3 on Android and Apple Human Interface Guidelines on iOS.

FOCUSED MOBILE PRINCIPLE
One connected product.
A deliberately focused mobile scope.
Two native interaction systems.

02 / PRODUCT CONTEXT

From fragmented property management to one connected product.

The product opportunity emerged from early interviews with two self-managing property owners. Both relied heavily on personally maintained spreadsheets and separate records to track rent, tenants, property history, maintenance, receipts, invoices, and documents.

The problem was not simply missing software features. Important information existed in different places, making it difficult to understand each property as one operating and financial system.

Maintenance exposed the problem especially clearly: repair requests, contractors, costs, receipts, invoices, and property history were difficult to connect into one useful record.

CONNECTED PRODUCT PRINCIPLE
A property is not just an address or a row in a spreadsheet. Rent, tenants, maintenance, documents, expenses, and history all contribute to the same operating record.

03 / MOBILE REFRAMING

Desktop is a command center. Mobile is an action surface.

Desktop was designed first as the broader RentalHQ management workspace, with mobile planned as part of the product direction from the beginning.

Once the desktop experience had matured enough to establish the product model and begin receiving early feedback, I moved into mobile design.

Mobile intentionally carries less functionality. The goal was not to reproduce every desktop capability on a phone, but to preserve the same product logic while prioritizing the information and actions owners need in a mobile context.

FOCUS, DON’T MINIATURIZE
Mobile has a reduced scope by design, not a reduced understanding of the product.

04 / MY ROLE

End-to-end product ownership, from discovery to cross-platform mobile design.

As Product Owner / UX Lead, I owned RentalHQ from the initial product opportunity through architecture, workflow definition, design-system development, desktop design, and the focused Android and iOS experience.

The mobile work was therefore not a handoff of an existing product into two operating systems. It was part of a broader product-design process in which I defined what the product should do, what belonged on mobile, what needed to remain shared, and where the platforms should behave differently.

PRODUCT OWNERSHIP PRINCIPLE
AI-assisted tools accelerated exploration and iteration. Product strategy, prioritization, architecture, and UX decisions remained part of my Product Owner / UX Lead responsibility.

05 / SHARED PRODUCT ARCHITECTURE

One mobile product architecture, expressed through two native systems.

The mobile experience uses one shared product structure across Android and iOS.

Home, Rent, Maintenance, and supporting account functions remain organized around the same information relationships, workflows, and business rules. What changes between platforms is how those requirements are expressed through native navigation, controls, temporary surfaces, feedback, and system behavior.

Home

Portfolio health, financial state, and items requiring attention.

Home ContentPortfolio, cash flow, alertsOverdue RentPayment alertMaintenance IssueOpen requestTenant DetailTenant / rent statusExpense ReviewReview / approve

Rent

Collection status, tenants, payment context, and follow-up.

Rent CollectionTenant list / payment statusTenant ListFilter / sortTenant DetailTenant / payment actionsPayment HistoryRecords / receiptsSend ReminderReminder / follow-upReminder ConfirmationReminder sentUpdated Follow-UpFollow-up recorded

Maintenance

Issues, estimates, approvals, expenses, and related property context.

Maintenance ListStatus / priority / vendorMaintenance DetailRequest statusExpense ReviewReview / approveExpense ApprovalApproveCash Flow ImpactFinancial impact

More

Supporting account, settings, reports, and secondary functions.

SettingsPreferences / notificationsReportsReports / exportsAccountProfile / sign out

Native Platform Expression

Android

Material Design 3

Bottom navigation: primary destinationsTop app bar: context and actionsBottom sheets: temporary tasksDialogs: confirmation and feedbackAndroid system navigation: return behavior

iOS

Apple Human Interface Guidelines

Tab bar: primary destinationsNavigation bar: context and actionsNative sheets: temporary tasksAlerts: confirmation and feedbackiOS navigation behavior: return and dismissal

SHARED BUSINESS LOGICThe platform does not need identical UI to remain the same product.SHARED

• Core information
• Business rules
• Workflow sequence
• Financial and operational meaning
• State and task outcome

PLATFORM-SPECIFIC

• Navigation
• Controls
• Temporary surfaces
• Feedback
• Dismissal and return behavior

Shared Cross-Platform Principles

06 / FINANCIAL HOME

Financial health first. Exceptions before detail.

Early discovery showed rent and payment tracking living in self-maintained spreadsheets and separate records. On mobile, I treated collection health as the first financial question to answer: what has been collected, what remains outstanding, and what needs attention now.

That led to a deliberate hierarchy: collection health first, actionable exceptions second, broader portfolio context third. Android and iOS preserve that order even when each platform uses different spacing, grouping, navigation, and controls.

01 / COLLECTION HEALTH

Establish the rent position before asking the user to investigate.

Collected and outstanding rent provide the first financial signal. The owner can understand the current collection position before opening individual tenant records or moving into deeper portfolio detail.

---

---

02 / EXCEPTIONS

Move from financial state to the items that require action.

Overdue rent and pending maintenance costs appear immediately after collection health, with enough property, tenant, amount, and status context to help the owner decide what needs attention next.

---

---

03 / PORTFOLIO CONTEXT

Keep broader portfolio context available without letting it compete with priority.

Property count, occupancy, tenant context, and cash flow remain available after the immediate collection position and actionable exceptions are understood.

---

---

MOBILE PRIORITIZATION DECISION
On a phone, broad portfolio context is supporting information. Collection health and actionable exceptions take priority.

07 / RENT COLLECTION JOURNEY

One shared workflow from financial awareness to accurate follow-up.

Rent collection turns a financial signal into a follow-through workflow. Mobile has to help the owner move from noticing an exception to understanding the tenant and payment context, taking an action, confirming it, and returning to an updated record.

The business sequence remains shared across Android and iOS. What changes is how each operating system expresses navigation, temporary surfaces, confirmation, and return behavior.

01

UNDERSTAND

Start from the Home financial state and attention items to recognize that a rent issue requires action.

02

IDENTIFY

Open Rent Collection and locate the overdue tenant or payment exception that needs follow-up.

03

INVESTIGATE

Review the tenant record, amount due, due date, overdue state, payment history, and relevant context before taking action.

04

ACT

Open Send Payment Reminder and verify the recipient, amount, and intended action before committing it.

05

CONFIRM

Receive clear confirmation that the reminder was sent before leaving the action state.

06

FOLLOW UP

Return to the updated tenant record with the follow-up preserved as part of the ongoing payment context.

WORKFLOW DECISION
Preserve the business sequence across platforms. Adapt the interaction pattern, not the task logic.

08 / SHARED PRODUCT, NATIVE INTERACTION

The workflow stays shared. The interaction model adapts to the platform.

The shared layer defines task order, information meaning, state, and business rules. Material Design 3 and Apple HIG then determine how those requirements are expressed through navigation, controls, temporary surfaces, feedback, dismissal, and return behavior.

01

PRIMARY NAVIGATION + HIERARCHY

Android uses Material navigation patterns while iOS uses Apple navigation conventions. The primary destinations and task hierarchy remain aligned even though their native presentation differs.

02

FILTER + SORT

Android expresses the temporary filtering task through a Material-style surface while iOS uses its native sheet treatment. The filtering logic and resulting task remain the same.

03

REMINDER + CONFIRMATION

The recipient, amount, action, and success state remain consistent while confirmation and feedback are expressed through platform-appropriate interaction patterns.

04

NAVIGATION + RETURN

Android back behavior and iOS navigation and dismissal behavior differ, but both return the user to the same tenant and payment context without breaking the workflow.

CROSS-PLATFORM RULE
Define shared product intent, information, state, and task outcome first. Then map them to native interaction patterns.

09 / ADAPTIVE LAYOUTS

Adapt the layout without changing the task.

Adaptive behavior extends the same focused mobile architecture across compact, landscape, medium, expanded, and regular-width layouts.

More space can reveal additional context or relationships, but it should not change the task, disrupt the current state, or turn the mobile experience back into the full desktop workspace.

ANDROID / WINDOW-SIZE CLASSES

COMPACTSingle-pane task flow

MEDIUMPersistent navigation + more visible content

EXPANDEDList + detail visible together

IOS / IPADOS, SIZE CLASSES + TRAITS

PORTRAITCompact width · focused single-pane flow

LANDSCAPESame task · more context side by side

REGULAR WIDTHPersistent list + detail relationship

ADAPTIVE DECISION
Use additional space to expose context, not to reintroduce the full desktop workspace.

10 / MAINTENANCE + FINANCIAL IMPACT

Operational work becomes a financial decision.

Maintenance was one of the clearest gaps in early discovery. Repair requests, contractor relationships, receipts, invoices, costs, and property history were being tracked separately, making it difficult to understand the work itself as one connected record.

For mobile, I focused that broader maintenance model on a decision path an owner may need away from the desk: understand the issue, review the expected cost, decide what to do, and see the financial consequence.

01 / ISSUE

Maintenance Financial Alert

Establish the property, maintenance problem, urgency, and current state before asking the owner to make a financial decision.

02 / ESTIMATE

Expense Review

Present the expected cost together with enough issue and property context to evaluate whether the expense should move forward.

03 / DECISION

Expense Approval

Approve, reject, or continue the workflow with the expected cost and relevant context visible at the point of decision.

04 / FINANCIAL IMPACT

Cash Flow Impact

Carry the approved expense back into the broader financial picture so the operational decision remains connected to its effect on available cash flow.

MOBILE SCOPE DECISION
Mobile carries enough context to evaluate and act on a maintenance expense without reproducing the full desktop workspace.

11 / STATES + ACCESSIBILITY

Design the states, trust, and accessibility beyond the happy path.

A credible mobile product has to account for more than its primary workflow. I defined loading, empty, error, success, unavailable, and attention states so users can understand what is happening and retain context when the product is not in an ideal state.

Accessibility was treated as a design requirement across both platforms. The specifications account for touch targets, scalable type, semantic structure, non-color status cues, and native accessibility conventions. These are design and implementation requirements, not claims of completed accessibility validation.

ACCESSIBILITY PRINCIPLE
Accessibility is part of the product specification from the beginning. Formal accessibility validation remains a separate implementation and testing activity.

12 / DESIGN + DEVELOPMENT

Define the product behavior before expanding implementation.

RentalHQ is still moving from design into a usable initial release, so this work is not a completed production handoff. I have been defining the product rules, workflow behavior, platform mappings, states, and phased scope needed to move the experience toward implementation.

The specification separates what belongs to the shared product from what should remain native to Android or iOS, while also distinguishing core release requirements from capabilities planned for later phases.

IMPLEMENTATION PRINCIPLE
Document what must stay shared, what should adapt by platform, and what belongs to a later release phase.

13 / WHAT CHANGED

What is established now and what comes next.

RentalHQ Mobile is an active product-design and development effort, not a post-launch case study. The work to date establishes a focused mobile architecture, key owner workflows, native Android and iOS interaction models, adaptive behavior, state requirements, and implementation specifications.

Prototype and workflow reviews have produced early positive feedback and ongoing refinement. A reduced locally usable release is the next implementation milestone; hands-on user testing and broader product capabilities will follow.