Information architecture for platforms with multiple user roles
A multi-role platform centrally organizes shared objects but offers different entry points, views, and permissions for each task.
"Information Architecture for Multiple Roles" is considered here from the perspective of "Structural Governance and Hubs." For website managers and UX teams, "Shared Object" and "Duplicate Data Records" are particularly important.
Published: 3 min read · Author: Sebastian Geier
How does an information architecture connect shared content with different user roles?
Content and entities are modeled once. Each role receives appropriate entry points, information, and actions, while permissions are enforced server-side at the object and the action.
Enforced Permission
Control signal
Signal 1
Duplicately maintained business objects and inconsistencies in their status or content between role-based views.
Control signal
Signal 2
Denied direct access, unclear permission cases, and task terminations due to missing role-relevant information.
Duplicate Records
Duplicate Records – Each role maintains its own copy of the same process, resulting in inconsistencies in status, content, and responsibilities.
Hiding Instead of Protecting – A function is missing from the menu but remains accessible via known URLs or direct requests without sufficient validation.
Role Overload – A broad, general role receives too many functions because specific tasks and object relationships have not been modeled.
Task-Oriented View
Initially, shared objects, relationships, and possible actions are described in a business-oriented manner without reference to existing menus.
For each role, task paths, visible fields, and an authorization matrix consisting of actions and object states are created.
Tests with allowed and forbidden direct calls verify the user interface and server-side enforcement for real-world role combinations.
Shared Object
Test criterion
Shared Object
A business object has a single identity and source, even if different roles require different fields or views.
Test criterion
Task-Oriented View
Navigation and priority follow role-based decisions, not simply a generic list of all available functions.
Enforced Permission Read and edit permissions are checked for each sensitive action and affected object, regardless of the user interface.
Check case: "Duplicate records"
Editors and legal reviewers work on the same content object but see different required fields and actions. A reviewer can approve content but cannot change ownership or market assignment; direct edit requests are rejected regardless of the visible menu.
Which decisions complement "Information Architecture for Multiple Roles"
A relevant follow-up question answered Cleanly separating multiple business units on one domain"How do you separate business units on a domain without losing common strength?"
A second connection for "Information Architecture for Multiple Roles" leads to Deriving Breadcrumb Markup from the Actual Page HierarchyThis article remains focused on the question "How do you derive breadcrumb markup from the actual page hierarchy?"
If you want to practically implement "information architecture for multiple roles," you can refer to Robust Website Systems This focuses on "structural governance and hubs" and "shared object."
Conclusion: Information Architecture for Multiple Roles
Multiple roles require different paths through the same domain model. Shared objects and technically enforced actions prevent duplication and a false sense of security.
Sources and Further Information
The following sources document the technical and methodological guidelines used for "Information Architecture for Multiple Roles."
Understanding Success Criterion 2.4.5: Multiple Ways – W3C WAIThe W3C guideline supports verifiable alternative paths and orientation in complex information repositories.
4. Make the service simple to use – GOV.UK Service ManualThe official standard requires simple, consistent service channels tested with actual users.
Key Thesis
The shared domain model defines objects and relationships once. Roles receive navigation, priorities, and actions based on this; access rules are technically enforced and not merely displayed via hidden menu items.
What This Is Not About
Role-based architecture does not mean creating the same content multiple times or only hinting at access rights through hidden menu items.
What it's about
A shared domain model contains objects and relationships; roles modify the view, priority, and permitted actions.
Information Architecture & Taxonomy
Create a content map as a binding architectural model.
"Information Architecture for Multiple Roles" includes, as a separate test step, the question: Which fields make a content map more than just a unique list of URLs?
Information Architecture & Taxonomy
Correctly Classifying Pages Without a Clear Parent-Child Relationship
"Information Architecture for Multiple Roles" is supplemented by a separate decision: How do you categorize content that is relevant to multiple areas and doesn't have a single, unambiguous parent?
Insights Overview
All VELUNO Insights at a Glance
Further analyses on Website Systems, digital visibility, and robust working models.
Enforced Authorization: Next Step
A central process with multiple roles involved is suitable as a model. Objects, actions, visible information, and server-side rules are first fully delineated from one another.