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, a different navigation hierarchy, and different action affordances — but every screen used the same component library, the same design tokens, and the same interaction grammar. An owner's booking flow and a guest's booking flow looked structurally identical to engineering. They diverged only in copy, hierarchy, and what was permissioned.
The system became the spine. Without it, the product would have fractured by role within three months.
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.
What this engagement was actually about
Founding-designer work doesn't look like the case studies in design schools. It's not "redesigning an established product." It's standing in front of an empty roadmap, deciding what the product even is, and building enough structure that a small team can ship without you reviewing every decision.
Owners taught me that the highest-leverage move in 0→1 work isn't visual polish or even research depth — it's the system you leave behind. Five roles, one codebase, one designer. That's the real output.