Stop designing permissions last!

For years, I’ve watched project teams (including my own) approached projects the same way: decode tender requirements, validate needs across business-ops-tech, interview users, prototype screens. Rinse and repeat.

In prioritisation cycles, features like audit logs, access control and permissions always got pushed to the last sprint. They felt like technical add-ons — low UI effort, rarely used, easy to tack on later.

We’d design all the features, map entire journeys, then ask: “Ok, which users need to access which features?” “What permissions do we need to introduce?” “What configurations are needed and for which features?” The foundation was built backwards.

Then I tried ORCA.

By mapping the ecosystem first: actors, systems, objects, and their relationships, everything shifted. Permissions and access needs surfaced naturally, right from the start.

What changed:

• Early Role-Based-Access-Control = clearer actor definition → stronger UX foundations
• Not all actors see the same menu, dashboard, or content
• Entry points differ by role
• Stakeholder impact becomes visible early, before processes or tools change

When you define roles and boundaries upfront, you’re not just checking boxes. You’re building on solid ground. Flows become realistic. IA gets cleaner. Navigation makes sense.

First post here — would love to hear how others approach permissions in their design process. Early, late, or somewhere in between?