Visibility, Security and Permissions
Intro#
Visibility is the basic principle that the more visible an element is, the more likely users will know about them and how to use them – Donald Norman.
Visibility, within our Desktop, Web and Mobile products, means who (role & permissions) can see what (visibility).
Security & Permissions are used within Security Roles to specify what tasks users can perform and what users can access. From the highest level of interaction, multiple or single services to elements, such as fields, within a service, can be enabled or disabled for users based on permissions. Permission-based content, if visible to users without appropriate access, can be overwhelming and frustrating.
Because of the nature of roles and permissions across iQmetrix’s ecosystem of products is complex (Cova and Ready are also intertwined within the ecosystem) going forward the more intentional designs are with maintaining the principles of visibility, security & permissions in conjunction with development, the better the user experience.
Principles#
- Users should be able to see only what is relevant and permitted to them.
- Users should not be able to see or interact with content that is not relevant or permitted.
- Clear, actionable guidance should be provided if unable to adhere to the first 2 principles.
Guidelines#
- Be certain of why content should be visible or hidden. Permission-based content, if visible to users without appropriate access can be overwhelming and frustrating.
- It is always better to hide content than to show an error if user doesn’t have the appropriate permissions.
- Visible content should assist, be relevant and meaningful.
- Appropriately time when user should see content, avoid introducing content before the user needs it.
- At times, users may need to take action to gain access to content, always ensure that it is clear what next steps should be.
- Always reduce the user’s cognitive load, where possible by only making relevant content visible.
- Provide appropriate feedback so users know what to do next if permission-based content cannot be hidden.
Rules#
When should we show or hide content? Scenarios:
Missing a permission
- User might not have access due to role permissions in Hub or security role permissions in RQ.
- Permissions by Company Tree hierarchy in RQ can result in a user missing a permission.
- Despite missing permissions, in some instances, like RQ reporting, a user is able to see non-relevant and/or inaccessible reports.
Not permitted
- User might not have access to an app or feature because their company hasn’t subscribed to a premium feature.
- They are restricted based on Carrier/Partner relationship.
- They haven’t completed steps in order to have visibility and permission to access and interact with content.
In these scenarios, follow these rules:
- Don’t show content that user does not have permission to see.
- If content is visible, but not permitted (due to service/product restrictions) ensure that next steps are clear or an appropriate result, alert or empty state component is used.
- Some error messages in RQ are built-in and are considered anti-pattern, in these cases only the modal title is editable.
- It is the responsibility of service owners to allow ability to grant permissions to their service (enabling/disabling).
- Restrict user to seeing only permission-based content where possible, using relevant components such as dropdowns, tree selects, etc.
- In the case of 3rd party integrations, users may need to enter an ID number, like a
user token, to enable content. This is an example where the user would need to see content to be informed that steps are needed. - Assistive technology like screen readers should follow the same rules as above.