Apartment List~3 min read
Was rich media worth building?
The feature arrived as a directive, not a customer request. 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, not a customer request. 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 were not 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 answer rather than an assumption.
There was a real renter problem underneath it. Someone looking at an apartment could not tell which photos actually showed that apartment. The listing card was static, used building-level media, and did not convert.
So the answer was yes, with a constraint: partners’ internal systems could not 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 rather than 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 did not move forward, even after research answered the question that started the project.
I do not have a record of why they stopped. The feature was not finished, and I cannot turn the research result into an explanation for the roadmap decision. That distinction is the useful one.
