VisuallyMeta
← Field Notes

Permissions aren't a settings page.

Part of Automated Quality Management

In a QA tool, who-can-see-what isn't a checkbox screen you bolt on at the end. It decides what every other screen even contains.

An auditor overrides scores. A QA manager runs calibration. An exec reads aggregates and should never touch a raw override. A tenant admin configures templates but has no business seeing an individual agent's grade. A superadmin lives in a separate shell.

So before wireframing, I mapped every role against every surface as a matrix — full access, read-only, or none. Not for security theater. Because an exec's "detail view" and an auditor's "detail view" are different screens wearing the same name: one can flip a checkpoint and see the trail; the other can't see the button.

Drawing that grid early kills a whole class of bug — the read-only user shown a control that errors on click, the exec accidentally exposed to data they shouldn't have. You can't design the screen honestly until you know who's standing in front of it.

The permission matrix is a design input, not a compliance afterthought. It reshapes everything it touches.