Summer helped people own a vacation home two ways: gradually, through a rent-to-own path to full ownership, or immediately, by managing a home they already owned.
The member app was the owner's window into all of it. They used it to book their stays, follow the equity they were building toward full ownership, and stay oriented in a multi-year rent-to-own contract.
That meant one app had to serve two audiences with very different goals, data, and mental models. I led the design end to end, mapping out each user type's needs and edge cases before shaping a single experience that felt clear and personal to both.
Designing for multiple user personas
The challenge
On the surface, the UI was relatively straightforward, but the real complexity lived underneath. Each user type came with its own use cases, data needs, and edge cases (like single vs multiple homes) that all had to be carefully mapped out before any design decisions could be made.
The "My Home" tab is a good example of this complexity in action. Each version had to account for different user types, data availability, and constraints, so I scoped it with engineering, weighing technical feasibility against the ideal UX.
Phasing plan and considerations
- v1 showed projected end-of-contract equity (real-time calculations weren't feasible yet) and descoped annual net revenue for Immediate owners, using a CTA to home details so the tab didn't feel empty
- v1.5 introduced annual net revenue for Immediate Ownership members
- v2 would show live equity based on where the Gradual member is in their 3-year contract
Design approach
I kept the UI between v1 and v2 intentionally similar to minimize dev rework, but the copy had to clearly separate projected from actual equity, so members never felt misled about their numbers.
SummerOS