Apartment List~4 min read
Why did three analysts with the same title need different access?
The org chart and the access chart no longer matched, and the people administering access every day were the first to notice.
- Role: Product design and research
- Timeline: 3 weeks
- Team: 1 PM, 1 engineer, me
- Impact: Permission tickets down 47%
- Platform: Web
What was happening?
Apartment List had outgrown its access model. In a given month, three quarters of partners raised an access ticket, and 45% raised one about permissions specifically. Routine work stalled. People assumed the wrong colleagues could see sensitive data. Approvals ate time.
The real choice was architectural, not visual: should access follow a job title or the individual? I built both models and tested them with 10 property management marketers before engineering began. Per-person access won and shipped across three platforms using one shared set of role definitions.
What I owned
I owned
- Research with 20 subject matter experts through surveys, interviews, and journey maps
- Both prototypes and usability testing with 10 property management marketers
- Choosing between role-based and per-person assignment
- Defining scope, including cutting customer-defined roles because of audit risk
- The shared role definitions used across three platforms
Decided with the PM and engineer
- What the backend could support, which ruled one model out immediately
The problem
The product grew. Access did not keep up.
I ran surveys, interviews, and journey maps with 20 people who administered access every day. They were the right people to ask. This was not a question about interface preferences; it was about how these organizations delegated authority. Only the administrators could see that the org chart and access chart had drifted apart.
The first decision
Give access to people, not titles
A job title did not establish what someone needed: three analysts with the same title had three different permission sets. Role-based access, where access follows a job title, worked for enterprise partners with strict hierarchies but not for smaller, less structured organizations. Attribute-based access, where access follows properties of the person and resource, suited overlapping teams but the backend could not support it within three weeks. We used roles as a starting point, then assigned access per person. That matched how organizations worked but created a maintenance problem: valid exceptions on day one could be undocumented by month six after the person who granted them had left. Role-based systems are rigid because rigidity is auditable. Customer-defined roles stayed out of scope to keep individual assignments controlled exceptions rather than allow unbounded drift. The model shipped across three platforms with one shared set of role definitions and became the foundation for later systems.
I tested both prototypes for usability even though the question was architectural. That sounds like a category error, but it is not. When the access model is wrong, people say they cannot find how to do what they need to do. Each prototype created different confusion. That difference showed which model matched how these teams already thought.
What made the cut?
Shipped
- Individual assignment, not assignment tied to job titles
- One shared set of role definitions across all three platforms
Left out
- Time-based access expiration: useful, but not critical
- Customer-defined roles: too much unbounded audit risk
What changed?
Permission tickets per month
45% of partners, down to 24%
All access tickets per month
75% down to 54%, including password resets
These figures come from the support tool, where access and billing were tagged separately. They cover separate projects, which is why they differ from the Better Billing study. They were still at this level when I left Apartment List in 2024. The gap between the two figures matters. In a month, 75% of partners raised an access ticket. Password resets, untouched by this project, accounted for 30 points; permission tickets accounted for the other 45. After launch, total access tickets were 54, leaving permission tickets at 24. That is a 47% reduction in the category this work targeted, within a 28% reduction across everything tagged access. There are two caveats. This assumes password-reset volume stayed steady. It should have, because it was a different untouched system, but that was not separately confirmed. It also treats the two categories as separate populations; if a partner raised both ticket types in one month, the split is approximate. Separately, a heuristic evaluation gave the new permissions feature 92%. That is an expert review against usability principles, not a measure of anything an administrator did, so it is not reported as an outcome.
The architecture won. The argument did not.
The uncomfortable truth was that twenty people were not enough to make the case feel settled. The team kept assuming roles mapped neatly to job titles. Then three analysts with one title showed up with three different access levels, and the research still read as anecdote.
I got the architecture I wanted, but not by winning that argument. The unresolved judgment is how much evidence it should take to stop treating a visible mismatch as an exception.
