Apartment List~3 min read

Three analysts with the same title needed different access.

Three weeks, one PM, one engineer, and a backend that ruled one access model out.

Role: Product design and research
Timeline: 3 weeks
Team: 1 PM, 1 engineer, me
Impact: Permission tickets down 47%
Platform: Web

0% ↓

Permission tickets per month

45% of partners, down to 24%

0% ↓

All access tickets per month

75% down to 54%, including password resets

From the support tool, where access and billing were tagged separately, against the roughly 1,000 property management companies on the platform. They cover a separate project from the Better Billing study. Read at three weeks, ahead of the three months Apartment List normally took to report, and still at this level when I left in 2024. Password resets, which this project did not touch, were 30 points of the 75%, so permission tickets were the other 45, falling to 24. That is a 47% reduction in the category this work targeted. The 47% assumes password-reset volume stayed steady, which I did not confirm. A partner raising both ticket types is counted approximately. A heuristic evaluation also scored 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.

Overview

Access followed job titles, and the people administering it every day were first to see that no longer worked.

In a given month, 75% of partners raised an access ticket. Routine work stalled, people assumed the wrong colleagues could see sensitive data, and approvals ate time.

Worked with: 1 PM and 1 engineer; 20 subject matter experts in research and 10 marketers in testing.

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

Research

Twenty administrators told us the org chart and the access chart had drifted apart.

I ran surveys, interviews, and journey maps with 20 subject matter experts who administered access every day. Only administrators could see the drift. The question was how organizations delegate authority, so interface preferences did not come into it.

Decision: who access follows

I assigned access per person and used roles only as a starting point.

I built two models and tested both with 10 property management marketers before engineering began. Role-based access, where access follows a title, worked for enterprise partners with strict hierarchies and failed smaller ones. Attribute-based access suited overlapping teams, but the backend could not support it in three weeks.

The cost: valid exceptions on day one can go undocumented by month six, after the person who granted them has left. Role-based systems are rigid because rigidity is auditable.

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.

Redesign

One screen shows each person’s access, and one form assigns three products separately.

Two people can hold the same access type and still cover different regions and community counts, which a title could not express. The invite form asks for no title anywhere. Each product gets its own role decision.

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.

Scope

Individual assignment and one shared set of role definitions shipped. Customer-defined roles and expiring access did not.

I cut customer-defined roles because they add unbounded audit risk, and kept individual assignments as controlled exceptions. Time-based expiration was useful but not critical.

Results

Permission tickets fell 47%, within a 28% fall across all access tickets.

I got the architecture I wanted without winning the argument

The team assumed roles mapped to job titles. Twenty people were not enough to make the case feel settled, and the three-analyst example still read as anecdote. I do not know how much evidence it should take before a visible mismatch stops being filed as an exception.