IS Design #3: Using Understandability and Hierarchy of Privileges

On an orange background is shown a pyramid of four gradient purple hues. Each hue is attached to a symbol to illustrate roles: an eye for the viewer, a pencil for the editor, a crown for the administrator and a lock for someone who has no access.On an orange background is shown a pyramid of four gradient purple hues. Each hue is attached to a symbol to illustrate roles: an eye for the viewer, a pencil for the editor, a crown for the administrator and a lock for someone who has no access.
On an orange background is shown a pyramid of four gradient purple hues. Each hue is attached to a symbol to illustrate roles: an eye for the viewer, a pencil for the editor, a crown for the administrator and a lock for someone who has no access.
Posté par
Cécile G.
Le
24 Feb
.
2026
Copier l’URL de l’article

To pursue the exploration of design principles for your information system, let us explore 2 complementary notions to those previously studied.

Today, we will focus on understandability (or intelligibility) and the hierarchy of privileges within information systems.

First, let us define what understandability is about. Systems architecture is, by essence, technical.

An IS should serve to:

  1. access data,
  2. segment and classify information according to specific logics,
  3. access interface with several filters and display of features,
  4. integrate typologies of connection and accesses.

To summarise, it is an environment where tasks are numerous and connections essential.

All of this means you can only reduce complexity to a certain extent. Complexity should not equal confusion. If everything in your system has been thought through with methodology and intent, everything in your system is useful and has a place in your ecosystem.

Understandability is the identification of the usefulness of each element which makes the IS.

If that seems obvious, it helps to grasp the importance the IS holds on performances for safety and reliability.

Amongst the few elements, we can name:

→ its ability to decrease probability of vulnerability and failures in the system;

→ its ability to improve efficiency of crisis handling;

→ its ability to increase steadiness of risk assessment simulations within the system.

Do you find this all a bit too abstract and fuzzy?

In other words, the clearer your system, the easier its management and usage.

You save invisible time (otherwise spent deciphering screen layouts, on tracking unknown and beyond understanding scenarios, and so on) to be used on more important matters.

The Hierarchy of Privileges is a Safety Pillar

We will now look at the second key idea of this article: the Hierarchy of Privileges.

This hierarchy is a structural component to frame accesses to resources within your IS. These accesses should be given according to real needs.

In cybersecurity, the determining principle is that of least privileges. Meaning: “no-one should have more rights than those required to perform one’s tasks.”

This restraining hierarchy aims to:

- limit attack surface in case of hacked accounts,

- reduce risks of human error,

- simplify auditing and traceability of sensitive actions performed.

Reaching a Balanced State between Clarity and Hierarchy

These two notions are meant to feed one another.

A well thought out hierarchy contributes to clarity: each role reflects purposeful right attributions, coherent to identified uses within the organisation.

Conversely, a clear system makes hierarchy easier to successfully implement.Be mindful of stretching these principles into overuse.

An overly compartmentalised hierarchy becomes counterproductive: it weighs daily operations and turns into a productivity slump.

Your aim should be to fulfil your professional needs, identified as realistically as possible.

Devoting energy to create roles of secure use cases is certainly going to prove more of a waste of time than a gain.