Five Roles, One Product, No Fork
Owners.gr is a fractional property ownership platform — co-owners, guests, property managers, concierge, and admin. Each role has distinct responsibilities, different data needs, and different failure modes. The MVP treated them almost identically. I was brought in to fix that without forking the product into five separate apps.
What Was Broken at the Start
Three structural problems dominated the MVP:
- Booking flows with no role awareness. Owners, guests, and managers all landed on the same booking surface with no differentiation. A co-owner managing their own calendar and a guest requesting dates needed fundamentally different first actions — but got the same screen.
- Accessibility failures. The color palette failed contrast checks across the board. Text against backgrounds wasn't legible in bright conditions. This wasn't a preference issue — it was a WCAG failure that created real task friction for quick, time-sensitive booking actions.
- Hidden complexity without progressive disclosure. Co-ownership rules — maintenance cost splitting, last-minute availability, shared scheduling windows — were surfaced all at once. Users either got confused or ignored them entirely.
The My Property Module
I designed the My Property section from scratch — a unified management surface that adapts to role. Owners see their schedule, maintenance requests, and co-owner communications. Managers see their full client roster and daily task queue. Guests see their bookings and requests. Same module, same codebase, different data rendering based on auth context.
The drag-to-select booking engine took the most iteration. The interaction had to feel native on mobile while supporting complex date logic — last-minute windows, blackout dates, shared owner priority rules. I prototyped five different interaction models before landing on the one that passed usability testing: select range first, then surface availability constraints, not the other way around.
Testing What Matters
Twelve participants across three groups (owners, guests, managers) tested the booking engine and request flows iteratively.
Finding 1 — Filters before context is backwards. The initial design surfaced advanced filters (last-minute, special occasions) before users had selected dates. They found it overwhelming. Fix: move date selection first, reveal filters as contextually relevant options after. Removed perceived complexity without removing functionality.
Finding 2 — "Add Request" was invisible. Participants managing guest details consistently missed the add request feature. It wasn't labeled clearly and didn't use the toggle pattern established elsewhere in the app. Fix: aligned it with the existing interaction model. Consistent patterns don't need onboarding.
Reflection
The Owners engagement taught me how much product complexity can be hidden through role-aware rendering rather than role-aware routing. You don't need five apps. You need one system where the data shown, the actions available, and the language used all shift based on who's looking. The booking engine was the hardest part — not because of the UI, but because it required deep technical alignment to make co-ownership rules feel invisible to the person booking a week in August.