Apartment List~4 min read

Three analysts with the same title needed 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

The Teams and access screen displayed on a laptop, beside an ornate brass padlock.

Impact

0% ↓

Permission tickets per month

45% of partners, down to 24%

0% ↓

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, and they run against the roughly 1,000 property management companies on the platform — so 75% is about 750 partners raising an access ticket in a month, and the permission share within it moves about 450 to about 240. They cover separate projects, which is why they differ from the Better Billing study. They were read at three weeks, ahead of the three months Apartment List normally took to report, and were still at this level when I left 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 org chart stopped matching

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 rather than 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 a question about how these organizations delegated authority. Interface preferences never came into it. Only the administrators could see that the org chart and access chart had drifted apart.

A job title predicted nothing

Give access to people, not titles

A job title didn’t 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 couldn’t support it within three weeks. I 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.

The role-based model. Three levels of role hierarchy descend on the left from a primary user group through nested user groups to a single user; on the right, policy sets fan out into numbered permissions. A note reads: a user can execute an operation only if there is a role assigned to the subject. — Roles. Worked for enterprise partners with a strict hierarchy and clear definitions; did not survive smaller, less structured organizations, which is most of them.

The attribute-based model. Each user carries user attributes that resolve into policy access, which fans out into two separate permission sets — the same subject reaching different permissions depending on its attributes rather than its position in a hierarchy. — Attributes. Handled teams with overlapping responsibilities, and lost on a fact about the system rather than about the design: the backend to support it did not exist, and would not inside three weeks.

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 can’t 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

The members table that shipped. Four people are listed, each with their own access type — billing owner, admin, viewer, viewer — alongside the regions and the number of communities each one covers, so two people holding the same type still show different scope. — Per-person access as it shipped. Two people can hold the same type and still cover different regions and community counts, which is the thing a job title could not express.

The invite form. Below the email address, region, and communities fields, an access type panel lists three products — listing, portfolio report, and organization's settings — each with its own separate role dropdown rather than one role covering all three. — Individual assignment as a screen: one person, three products, three separate decisions. No title is asked for anywhere on this form.

The architecture won. The argument did not.

Twenty people weren’t 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. How much evidence should it take before a visible mismatch stops being filed as an exception? Twenty people didn’t do it.