Owners — fractional property platform

What was actually there

Owners.gr brought me on as Founding Product Designer. Their "MVP" — at the moment I joined — was a poorly-designed mobile landing page with no real functionality. No booking system, no role logic, no actual product. The team had a vision and a domain. They needed someone to turn it into a working product.

I owned product strategy, user research, design, and roadmap. The brief was open: take co-ownership as a category and build a product that could actually serve five distinct user roles — owners, co-owners, guests, property managers, and admins — without splitting into five different apps.

Five roles, one product, no fork

Most multi-role products solve this by forking the codebase or building parallel apps. That wasn't an option for a self-funded Greek startup. The constraint forced a better answer: design one coherent product whose surface adapts to who's using it.

Each role got a different home screen, different navigation hierarchy, and different action affordances — but every screen used the same component library, the same design tokens, and the same interaction grammar.

What Was Broken at the Start

• Booking flows with no role awareness. Owners, guests, and managers all landed on the same booking surface with no differentiation.
• Accessibility failures. The color palette failed contrast checks across the board.
• Hidden complexity without progressive disclosure. Co-ownership rules 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. The drag-to-select booking engine took the most iteration. 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. Two key findings: filters before context is backwards; "Add Request" was invisible until aligned with the existing toggle pattern.

Results

• 5 distinct user role workflows designed and validated
• 12 usability test participants across 3 role groups
• Drag-to-select booking engine shipped as the core interaction model