PRODUCT DESIGN · 2026
Role-based access
Twelve people held admin access. The product treated them like twelve equal kings.
ROLE
Product design and prototyping for Swipey's access model. I defined the permissions, reporting-chain reach, safeguards and connected admin flow, then built the prototype with AI agents.
THE GAP
Swipey had one people-access permission. Give it to a department head and they could manage everyone, not just the people below them. The permission said what they could do. Nothing said whose access they could touch.
The permissions already existed: twenty-five actions across seven product areas. The missing part was the boundary around them — who can invite, who can change access, and whose access they can change.
THE DECISION
A separate Roles page and location scope both looked tidy. Both modelled the company wrong. A role answers what someone can do. The reporting chain answers whose work they can reach.
I started with one person's effective access, reused the same grant model for custom roles, invitations and overrides, then derived reach from who reports to whom. Nobody can grant or remove a permission they do not hold.
THE BUILD
One Users workspace for people, the org chart and custom roles — with effective access that reads before it edits, reachable branches that stay visible, and impact checks before anything consequential changes.
WHAT STUCK