One Platform, Many Operating Contexts

Owned: information architecture, the UX of role-based access control (RBAC), contextual navigation, onboarding and reusable reporting patterns. Worked with: product and engineering, turning requirements into flows, views and implementation guidance. Engineering owned the enforcement of access rules. Internal teams and customer organisations shared one portal. Someone opening a report needs to know what they’re looking at, whose activity it represents and what they can do with it; a correct figure read in the wrong context is a business error. I framed the target behaviour as choosing the relevant view, understanding its scope and acting on it. The barriers were uncertainty about context, memory load when switching views, and having to relearn each report.

I chose a shared information architecture and page structure, with capabilities that respond to assigned roles and permissions. Separate interfaces per customer type would fragment the platform; an identical experience for everyone would ignore real differences in how people work. A common structure lets people build one mental model and carry it between views. The leadership call was deciding what the platform owns centrally and where reporting can vary, so later requests had a foundation to extend.

I separated three related concepts. Permission determines what someone may access. Viewing scope identifies which permitted part of the business they’re looking at. Local filters refine the report. Selecting a scope never grants access; the choices on offer stay within assigned permissions. This is recognition over recall: the interface shows the active context instead of asking people to remember an earlier selection.

Organisations aren’t structured the same way. Conditional controls reflect the structure that actually exists, so a simple organisation isn’t pushed through hierarchy levels that don’t apply. The same care applies to the data: a missing or inapplicable measure must never appear as a real zero.

The reusable views move from summary into comparison, breakdown and detail, so people aren’t shown every control and data point at once. Each chart needed a clear purpose, and emphasis had to point at the comparison or trend that matters to the task. That is how I managed cognitive load in practice: what appears first, where detail lives, and which controls sit next to the data they affect.

I designed invitation, account setup, verification and access management as part of the same platform experience. A new user needs a clear route from invitation to the right landing view. An administrator needs to understand which capability they’re granting and whose access an action affects. Security requirements shaped these journeys; engineering owned their enforcement.

When delivery priorities moved to reusable report views on existing datasets, I narrowed the immediate scope to overview, time-series, comparison, table and drill-down patterns, with consistent context and navigation. That gave the team a practical starting point without making every future report a prerequisite, while protecting the access and context model every report inherits.

Role definitions, onboarding journeys and reusable views turned a broad brief into decisions product and engineering could discuss against something concrete. I used the same three questions throughout: what is the person trying to do, what could get in their way, and what do they need to know before they act? The reasoning lived in the guidance, so it didn’t need re-explaining screen by screen.

Delivered: a role-based platform model, invitation and onboarding journeys, and reusable reporting views, now live on a shared access and context foundation. The main judgement was protecting that model while reducing delivery scope. Still to measure: can someone state the scope of a report, predict what a control will change, and move into detail without losing context?