01
Overview
Dashboard and properties establish portfolio health, asset context, reserves, and drill-down entry points.
What this case proves
I do not treat a dashboard as the product. I model the operating system under it — entities, states, financial relationships, exceptions, handoffs, and decisions — then make that complexity usable.
DomainProperty operations / financial workflow
My RoleProduct strategy, UX architecture, interaction design, prototype implementation
FocusHigh-data UX, linked workflows, state visibility, decision support
BuildReact-based browser prototype, local persistence, AI-assisted iteration
Problem
Property operations fragment fast.
A small portfolio can already involve property records, units, tenants, leases, rent charges, income, expenses, vendors, inspections, turnovers, reserves, owner contributions, capital projects, tasks, and reporting.
The hard part is not displaying each record. The hard part is preserving the relationships between them so the operator can answer: What changed? What is at risk? What needs attention? What does this decision do to cash and reserves?
Design challenge
Build one system that supports detailed operational work without forcing users to reconstruct context across disconnected spreadsheets, property-manager statements, task lists, and financial records.
System Architecture
Five domains, one operating model.
The public demo groups thirteen work areas into five domains. The point is not fewer features; it is clearer mental structure.
02
Finance
Ledger, capital, and reports connect operating cash flow, owner moves, reserve transfers, CapEx, and portfolio reporting.
03
Operations
Tasks, units, inspections, turnovers, and vendors expose the work required to keep assets operating.
04
Tenancy
Tenants and leases connect occupancy, rent, renewal state, charges, and unit relationships.
05
Intelligence
Action Center and Scenario convert exceptions and operating shocks into prioritized decisions.
Recruiter Walkthrough
The six-step proof path.
The demo tour is deliberately sequenced to show how context survives as the user moves from portfolio health to operational detail and finally to decision support.
01DashboardSee health, property selection, financial performance, and operating signals.
02PropertyDrill into asset data, reserves, income, expenses, documents, and notes.
03TenancyTrace units, tenants, leases, rent charges, and renewal state.
04LedgerInspect unified financial history with filters and linked context.
05CapitalReview contributions, transfers, CapEx budgets, actuals, and work.
06ScenarioStress vacancy and repairs to see impact on NOI and reserves.
Interactive Product
Use the system, not screenshots.
This portfolio version is a resettable public sandbox. It ships with four fictional assets, five units, four tenants, four active leases, synthetic operating history, inspections, turnover work, capital activity, and a preloaded vacancy + repair stress scenario.
Demo-safe by design
The public build uses a separate storage namespace and synthetic records. It includes a reset path and controlled error recovery so exploration cannot expose or corrupt operational data.
Design Decisions
Where the UX work created leverage.
Decision 01
Group by operating domain
Thirteen peer-level tabs created navigation pressure and made the product read like an admin console. Grouping preserved capability while giving users a more durable mental model.
Decision 02
Keep entities connected
Properties, units, tenants, leases, charges, expenses, capital projects, and tasks share identifiers and context so detail views do not become isolated data islands.
Decision 03
Separate operations from capital
Operating income/expense and capital movement are visible as different classes of financial activity. That makes NOI, reserves, and CapEx easier to reason about.
Decision 04
Design for exceptions
The Action Center surfaces delinquency, renewals, overdue work, and other conditions that require intervention instead of forcing users to hunt record by record.
Decision 05
Turn scenarios into decisions
The stress model lets the operator change vacancy, rent, expense shocks, one-time repairs, and reserve assumptions, then compare projected NOI and risk by asset.
Decision 06
Make the demo recoverable
Local persistence, reset controls, isolated demo storage, and a recovery boundary support exploration without the white-screen or corrupted-state failure mode.
AI-Assisted UX
AI accelerated iteration; it did not own the product judgment.
I used AI as a development and analysis accelerator: pressure-testing workflows, generating controlled synthetic scenarios, auditing cross-record integrity, and shortening the loop between UX decisions and executable prototype behavior.
The product decisions remained human: what belongs together, what state matters, what is dangerous to hide, what the user needs next, and what should be simplified.
Design / Dev Bridge
This is the same operating lane I use in enterprise UX: move close enough to implementation that workflow assumptions can become testable behavior before a team commits to deeper engineering.
Outcome
What the finished prototype demonstrates.
Systems thinkingComplex relationships stay visible across multiple workflows instead of collapsing into disconnected screens.
Enterprise-style IAHigh-data functionality is organized by user intent and operating domain, not by implementation convenience.
Decision supportThe interface moves beyond recordkeeping into exception detection, scenario modeling, and operational prioritization.
Financial UXNOI, operating expenses, reserves, transfers, CapEx, and portfolio reporting are separated but connected.
Prototype depthEditable records, persistence, import/export, linked workflows, and reset behavior make the artifact testable rather than static.
Public-safe proofSynthetic data makes the product inspectable without exposing private operating records or employer-protected artifacts.
Public / Privacy Boundary
All properties, addresses, tenants, rents, financial values, vendors, expenses, and operating events in this build are synthetic. Portfolio Command is shown here to demonstrate transferable product and UX capability, not to expose private investment operations.
What recruiters should look for
Follow the operating model.
Do not judge this case by the real-estate domain alone. Look at how the system handles data relationships, navigation hierarchy, linked state, financial controls, exceptions, scenario testing, responsive behavior, and recovery.
Bottom line: Portfolio Command is public evidence of the same capability my enterprise résumé describes: turning complicated operating rules, high-data workflows, and cross-functional requirements into a system people can understand and use.