Is It Out of Scope? — Web design
Is adding new user roles and permissions out of scope for a web design project?
Yes. Roles and permissions are application logic — controlling what different users can see and do — not a visual design concern, even where the design shows what different views might look like.
A client running an app or member area sometimes wants to introduce new tiers of users — an "editor" role that can't publish, a "viewer" role that can't edit, an admin role with broader access. The design project may have designed the interface those roles interact with, but deciding and enforcing who can do what is application logic, not a visual layer.
Is it out of scope?
Yes. Designing what different role-specific views look like is design work; building the actual permission system that enforces those roles — checking access on every relevant action — is application development, outside a design engagement's scope.
Clause typically implicated
Clause typically implicated
Deliverables clause→ — Scopes the project to visual design — a permissions system that enforces access rules is application logic outside that, even where the design shows what each role's view looks like.
Example contract wording
Example contract wording (illustrative, not legal advice)
I can design what each role's view should look like — what an editor sees versus an admin, for example. Actually building the permission system that enforces those rules is development work outside our design scope. I'm happy to hand off the design specs to whoever's implementing it.
How MarginFlow flags it
MarginFlow checks whether the request is asking for visual differentiation between roles (potentially in-scope design work) or the actual access-control logic (outside scope) — the explanation makes clear which reading it landed on, since the two are easy to conflate in how clients phrase the request.