Apartment List~4 min read
What do you do when a sixteen-hour bulk update mostly fails?
Marketing and operations teams moved property data by hand because the API was too costly or technical to use.
- Role: Product design and research
- Timeline: 4 weeks
- Team: 1 engineer, me
- Impact: 4k+ active flows
- Platform: Web
What was happening?
Bulk property updates at Apartment List took eight to sixteen hours, and nearly all large uploads failed. The alternative was an API that marketing and operations teams found too costly or technical to adopt, so it was mostly unused.
We shipped a self-serve data flow built around one structural choice: steps on the left, with a live preview of what a file becomes on the right. Someone who has watched a sixteen-hour upload fail silently does not need only more speed. They need to see, while configuring it, whether it will work.
What I owned
I owned
- Research with 10 property marketing and operations managers, read against failure logs
- The split-panel structure, chosen over wizard steps and an infinite canvas
- Three navigation patterns built and tested; two failed
- The mapping model: raw fields to business entities, then how those entities update
Decided with the engineer
- What the preview could compute in real time, which set how much of the file it could display
- Which validation ran client-side and which needed the pipeline
The problem
The API worked. The people who needed it could not use it.
An average update took 8 to 16 hours. Nearly all large updates failed outright. For a marketing manager with a spreadsheet from a third-party portal, the API was either too costly to commission or too technical to run.
I interviewed 10 property marketing and operations managers at large property firms, then read the failure logs alongside what they told me. The reported problem and the thing that breaks are not always the same.
Could it be efficient?
Make bulk edits without errors.
Could it be flexible?
Handle multiple formats and sources.
Could people trust it?
Give clear feedback and validation.
Trust was why the first two were not enough, and it changed the brief. An eight-hour job that fails sounds like a job that should run faster and succeed. That makes it look like an engineering problem, with design as decoration.
But a fast automated import that people cannot inspect recreates the trust problem at higher speed. The dangerous outcome is not a rejected file. It is an accepted one: a successful upload that quietly maps the wrong column to the wrong entity puts bad data in front of renters, and nobody notices until someone complains.
The first decision
A visible configuration and live result
Users had to configure something they could not yet see. Wizard steps hid earlier context, leaving people unsure whether they had broken something two steps back. An infinite canvas showed everything at once; the canvas tool we reviewed was technically powerful but visually hostile to people who did not already know what they were looking at. We chose a split panel, keeping steps visible on the left and the active step's live result on the right. A fast preview that was subtly wrong would create confidence rather than earn it, so it covered both mapping stages: raw fields resolving into business entities, then models determining how those entities update. Errors became visible when introduced rather than at the end. It shipped with the existing design system and no new components; the structure did the work visual novelty could not.
The second decision
Navigation that recedes
A timeline with connectors and status was linear and visually clear, but its labels, indicators, and connector lines competed for attention; users read the chrome instead of the configuration. Radio cards improved click targets but added affordance and density at once, and failed worse. We stripped navigation back to plain numbered cards with a bold label, supporting detail, a clean boundary, and no status icons. The plainest option risked looking unfinished in review, so the labels abstracted the framework: Source, Crawl, and Specify Selectors read as a sequence of decisions rather than a technical pipeline users had to understand first. Testing settled the choice twice with immediate feedback. In a multi-step configuration flow, navigation is infrastructure, not content, and must recede from the task.
What shipped?
Three parts shipped: ingestion from CRM, spreadsheets, and third-party portals; transformation and mapping with a real-time preview, where raw fields resolve into business entities and models determine how those entities update; and monitoring and compliance across the flow.
What changed?
Active flows
Daily updates
Both figures come from the portfolio deck, against a path that had been an eight-to-sixteen-hour job that nearly always failed at volume. Neither has a date or named source, and both need one before they are treated as current.
The prettier versions lost
The timeline and radio card both looked better than what shipped, and both lost. I could not see why from the designs. Testing could, and the feedback was blunt enough that there was little to interpret: twice, I mistook an interesting navigation element for a helpful one. The version that worked had the least to look at.
Users caught those failures, but I cannot show anyone disagreeing with me. The split panel went in without opposition, so nobody stress-tested that structural decision with a reason to break it. Whether it deserved the same scrutiny remains the useful unresolved judgment.
