Apartment List~3 min read
Rich media arrived as a directive and had to earn the build.
Nobody asked for it. Before building it, we had to find out whether it was worth it.
- Role: Product design and research
- Timeline: 3 weeks
- Team: 1 PM, 1 engineer, me
- Impact: Conversion 1% → 5%
- Platform: Web
- Platform: iOS, Android
Start with the awkward question
Rich media arrived as a reactive directive. No customer had asked for it. So the first question was whether it was worth building or simply something to put on a sales sheet.
Research gave us two answers. Renters had wanted apartment-specific photos for years. Partners weren’t set up to produce them. No version could wait for better media, so the work became surfacing what was already in the system.
What I owned
I owned
- The research establishing whether rich media was valuable or merely defensible
- The alignment concept used across Product, Sales, Engineering, and Operations
- Three explorations scored on impact, confidence, and ease, and the reasoning that picked one
- The dynamic unit card and the enhanced listing view
- Preference and usability testing
Shared with the PM and engineer
- The performance and accessibility limits that ruled out two of the three directions
Problem
Was rich media genuinely valuable, or just something we needed to say we had?
The initiative came from the top after partners began asking for something competitors had. That is a bad reason to build, but not enough reason to refuse. We needed an actual answer before anyone built anything.
There was a real renter problem underneath it. Someone looking at an apartment couldn’t tell which photos actually showed that apartment. The listing card was static, used building-level media, and didn’t convert.
So the answer was yes, with a constraint: partners’ internal systems couldn’t produce apartment-specific photos, videos, or 3D tours. Whatever we shipped had to work with media already in the system.
Why the card won
Why did the card beat the more ambitious ideas?
We compared a media carousel, image-led listing layout, and restructured card. Scored on impact, confidence, and ease, the card was 4/4/4, the carousel 4/2/1, and the image-led direction 3/2/1. The carousel raised a performance concern and was too far from the existing design system. Pulling and rendering the image-led assets would have crushed performance; it was too far from the brand for the resources available and raised accessibility problems.
We chose the restructured card, the only direction that scored evenly across all three. The lowest-ambition option can change nothing measurable, so preference and usability testing validated the card against renter priorities. It was never run head-to-head against the other prototypes. Conversion moved from 1% to 5%.
The catch: we did not control the media
Surfacing what already exists means surfacing whatever a partner uploaded. A listing with four dark photos gets those same four photos, larger and earlier. A renter who might have skimmed past now has a reason to rule the unit out. The feature improves good listings and sharpens bad ones.
There was no version that waited for better media. We could work with what was in the system or keep showing nothing.
What changed
Conversion
up from 1%
Unit-specific tickets
down from 70%
Both held against the pre-launch figures through to my departure in 2024. Neither has a denominator recorded (conversion across how many listings, and 70% of which ticket population), and both should before this is read as settled.
The research answered the question, then the roadmap moved on
The alignment concept remained a concept. Internal priorities changed, and the further media enhancements didn’t move forward, even after research answered the question that started the project.
I don’t have a record of why they stopped. The feature wasn’t finished, and I can’t turn the research result into an explanation for the roadmap decision. Those are two separate things, and it matters that they stay separate.
