By Mehdi HassanHow should a property management dashboard be designed?
A property management dashboard should be designed around the three people who use it: the owner or investor, the property manager and the tenant. They look at the same buildings, units, leases and payments, but they ask completely different questions, so one shared screen with every widget serves none of them well.
The approach we recommend is one data model, one component library and three role-based views with their own defaults. That keeps the product consistent and cheap to maintain while each person sees what they came for. This sits inside the broader proptech picture covered in our real estate website design guide, and the marketing side of the same products is covered in proptech website design.
What do owners, managers and tenants each need to see?
Owners need performance and exceptions, managers need today's work and tenants need to pay and get things fixed. Laying the three views side by side makes the differences obvious before anyone draws a screen.
Owner or investor | Property manager | Tenant | |
|---|---|---|---|
Main question | How are my properties performing? | What needs my attention today? | Is my rent paid and my repair handled? |
Home screen | Portfolio summary and exceptions | Work queue across properties | Balance, pay button, open requests |
Key objects | Properties, income, expenses, occupancy | Work orders, leases, applicants, payments | Lease, payments, requests, messages |
Typical device | Desktop, some mobile | Desktop all day, mobile in the field | Mostly phone |
Visit frequency | Weekly or monthly | All day | A few times a month |
Density | Low, summary first | High, tables and filters | Very low, one task per screen |
Main actions | Approve, download statements | Assign, message, update status | Pay, submit request, message |
The visit frequency row explains most design decisions. Someone who logs in once a month needs orientation and summaries. Someone who lives in the product all day needs speed, keyboard shortcuts and dense tables they can filter.
How do you design the property manager dashboard?
Design the property manager dashboard as a work queue first and a reporting tool second. Managers open it to clear tasks: urgent maintenance, lease renewals, late payments and new applications. The home screen should answer "what's next" before it shows any chart.
- A single queue with priorities: emergencies, overdue items and items due today, across all properties, with filters by property and type.
- Status that's visible at a glance: consistent badges for open, assigned, waiting on tenant, waiting on vendor and done.
- Bulk actions: send renewal notices or late-rent reminders to many tenants at once, with a preview.
- Context in one panel: clicking a work order shows the unit, tenant, history and messages without leaving the queue.
- Field mode: a mobile view for inspections and maintenance, with photo upload and offline-friendly forms.
What belongs on the owner dashboard?
The owner dashboard should show money and exceptions in one glance, with a path from portfolio to property to unit. Owners don't want to manage tickets; they want to know whether their investment is healthy and what needs a decision.
- Portfolio summary: income, expenses, net operating income and occupancy, for the period they pick.
- Exceptions list: vacancies, large repairs awaiting approval, late payers and leases expiring soon.
- Approvals: a clear approve or decline flow for spending above an agreed limit, with photos and quotes attached.
- Statements and documents: monthly statements, year-end tax documents and inspection reports, easy to download.
- Drill-down: every number links to the transactions behind it.
Charts help here, because owners compare periods. Keep them simple: one trend line for income and expenses, one occupancy figure, clear labels. Our roundup of dashboard design examples shows how mature products handle summary views, and fintech dashboard design covers the patterns for showing money clearly.
How should a tenant portal be designed?
A tenant portal should be designed for a phone and for three tasks: pay rent, submit a maintenance request and message the manager. Everything else, from lease documents to community notices, is secondary and can sit one tap away.
Show the balance first
The home screen shows what's due, when, and a single pay button. Autopay setup sits right below it.
Make requests easy to submit
A maintenance request takes a category, a short description, photos and permission-to-enter preferences, in under a minute.
Show progress, not silence
Each request shows its status and the next step, with notifications when a vendor is scheduled or the job is done.
Keep messages in one thread
One conversation per tenant with the manager, linked to requests, beats scattered email.
Put documents one tap away
Lease, receipts and building rules live in a documents tab, searchable and downloadable.
Accessibility matters more here than anywhere else in the product. Tenants include older people, people using screen readers and people with poor connections, so large tap targets, readable type and forms that save progress are basic requirements.
How do roles, permissions and data rules shape the design?
Roles and permissions shape the design because the same unit shows different data to different people. A tenant must never see another tenant's details, an owner may only see their own properties, and a leasing agent may see applicants but not bank details.
Design each screen with the permission rules written next to it: who can see this field, who can edit it, and what's logged. Show users why something is hidden ("Only the property manager can change rent amounts") instead of hiding it silently. Keep an audit trail visible on sensitive objects such as rent changes, deposits and approvals, because disputes are common in property management and the history settles them.
Hypothetical example: one work order across three views
For example, suppose a tenant reports a leaking sink. In the tenant view, they see a request card with status "Submitted", then "Plumber scheduled for Thursday morning". In the manager view, the same request appears in the queue as high priority, with the unit history showing a similar leak earlier in the year and a button to assign a vendor.
In the owner view, the request only appears if the repair quote goes above the owner's approval limit, as an exception with photos and an approve button. One object, three presentations, each showing only what that person can act on. This is illustrative, not a client result.
What does a good property management dashboard design process look like?
A good process starts with interviews and real data, not a dashboard template. Talk to managers about their mornings, to owners about what they check and to tenants about what frustrates them. Then map the shared objects before designing any screen.
- Interview a few owners, managers and tenants, and watch a manager clear their queue.
- Map the data model: properties, units, leases, people, payments, work orders, documents.
- Write the main question each role brings, and design each home screen to answer it.
- Build shared components (status badges, tables, money formats, request cards) once.
- Test with real data volumes: a manager with hundreds of units behaves differently from a demo account.
- Ship one role at a time and measure what people actually click.
For a fuller checklist, see our SaaS dashboard design best practices. If you're budgeting the work, our dashboard design cost guide explains what changes the price.
