Click here to download the full series in PDF format.
In the previous parts of this series, we moved from structure to operation to governance: we dissected the “digital body” in the structural dimension, then connected it to the “technical pulse,” then placed above it a “governance sovereignty” that holds the center of decision-making, secures data sovereignty, and builds the national performance mirror. Yet all of this—with all its depth and importance—remains, in the eyes of the citizen and resident, an “institutional unseen” that they do not directly observe. What ultimately reaches them is a screen, a set of steps, and a message of success or failure. There, at the point of contact between the human being and the state, all these layers are condensed into a single experience: either it is clear, accessible, and makes the user feel that the state works for them, or it is obstructed and ambiguous, reproducing the same feeling once created by yesterday’s queues.
For this reason, the “usability dimension” should not be viewed as a cosmetic space concerned with interfaces and colors, but as a practical test of everything that came before it: protocol, governance, and structure. If the state fails to convert these layers into an understandable, fair, and usable experience, digital transformation remains an internal project that does not reach its purpose. In this fifth part, we reread usability challenges not as a technical appendix, but as an dimension that ultimately determines how society will judge the value of this entire transformation.
Fragmentation of the Digital Experience: When the State Speaks Through Discordant Interfaces
The first and most visible usability challenge is the inconsistency of the user’s digital experience across “Sahel” and beyond it. When a citizen moves from one service to another, or from one government entity to another, they often find themselves facing terms that change, steps that differ, and messages that do not align in logic or tone. One service asks for the same fields in a different way, another hides the most important step in a side line, and a third throws an error message that does not tell the user what to do next. The result is that the user must learn “the language of each entity,” instead of the entities committing to one national language in addressing the user.
This fragmentation is not a localized design error, but a structural result of the absence of a “national user experience system” equal in level to the “general protocol for smart government.” If the protocol unified the language of systems among themselves, the usability dimension requires unifying the language of the state with its users: fixed terms for statuses, recurring patterns for forms, predictable behavior for buttons, and a unified logic for moving between stages. Just as entities should not be allowed to invent their own dictionary for data, each entity should not be left to invent its own user experience in a way that confuses rather than serves.
The solution here is not to impose one rigid interface on everyone, but to build a national “Design and Experience System” that emerges from the “general protocol” and is established in a binding document. This document should define element patterns, step sequences, rules for on-screen writing, forms of success and error messages, methods for requesting approval, and how the expected time for completing a service should be displayed. These rules should then be integrated into the “protocol’s programming environment,” so that no service is introduced through the “unified national platforms” unless it complies with this system just as it complies with rules of integration and connectivity.
The intended result is for the user—whatever service they use, and whichever entity they address—to feel that the state is speaking to them with one face, even if several entities stand behind the screen. They should feel confident that what they learned in one service will help them in another, and that they are dealing with a stable “national logic,” not with discordant experiences connected only by the name of the application.
The Digital Divide: Who Holds the Hand of Those Who Have Never Held a Screen Before?
The second challenge in the usability dimension is the digital divide among segments of society. When speaking about user experience, we must not always imagine a young user, skilled with smartphones, able to read quickly and follow instructions with ease. The state faces other groups: elderly people unfamiliar with small screens, residents newly acquainted with the language, people with visual or motor disabilities, and citizens who have never grown accustomed to dealing with government platforms except through traditional service offices. If the digital experience is designed according to the standard of the “ideal user,” these groups are effectively excluded from fully benefiting from digital transformation, even if access is theoretically available to them.
Here, technology meets justice. Justice in the smart state does not mean making the service available to everyone on paper; it means making it usable by everyone in reality. This requires the principle of “Inclusive Design” to become a governing rule, not a technical option. Within the “general protocol for smart government” and its technical appendices, services should be required to meet standard levels of digital accessibility: clear contrast, compatibility with screen readers, support for text enlargement without breaking the interface, keyboard navigation, linguistic alternatives for critical messages, and shortened steps for recurring processes.
But justice does not stop at improving the interface. It also requires redefining the role of supporting service channels. Traditional centers should not be abolished or marginalized; they should be re-engineered into “support channels” for digital transformation. A beneficiary who cannot deal with the platform should be able to go there and find an employee using “Sahel” on their behalf within clear controls—not a parallel paper-based path. In this way, the weakest user is lifted up to the platform, rather than having an alternative system rebuilt for them. At the intersection of technology and justice, the rule of the smart state must remain clear: no one is left behind the screen.
The Expectations Barrier: When the Platform Is Burdened with What Is Not Its Role
In the first part of this series, we referred to the inflation of the “barrier of societal expectations,” and how the public often treats “Sahel” as though it were the mother system of the state or a magical solution to every institutional complexity. This phenomenon is not a passing sentiment; it is a direct usability challenge. A user who enters the platform imagining that they will be freed—from day one—from the entire legacy of bureaucracy will usually leave disappointed, even if they have completed much of what previously required standing in queues.
Managing expectations is not a secondary detail; it is part of experience engineering. Just as the steps of a service are engineered, the “promise” that the platform makes to the user must also be engineered: what can it do today? What can it not yet do because the institutional structure is not ready for it? And how does this promise change with each stage of maturity in structure, protocol, and governance?
The solution begins inside the application itself: clear introductory pages before entering services, update messages that explain what has changed, and indicators that show the user—in every service journey—where the responsibility of “Sahel” ends and where the role of the entity begins. It then extends to public discourse: when the state announces an achievement in “Sahel,” it should explain that this is a stage within a broader path, and that moving to a service without documents, without personal attendance, or without forms is conditional on the data sovereignty, protocol, and governance previously discussed.
In this way, the platform is not used to launch promises greater than its capacity, nor is it burdened with what it does not yet possess the tools to deliver. A user who understands the limits of the tool judges it fairly, has patience for its maturation, and participates—through awareness—in accelerating the reform of what lies behind it.
Cognitive Load: When the State Transfers Its Burdens to the Citizen’s Screen
The fourth usability challenge is the cognitive load borne by the beneficiary when using digital services. Many current forms transfer to the phone screen a complexity that used to be distributed between an employee and a paper form: dozens of fields, legal terminology, small conditions at the bottom of the page, and options whose impact on the transaction the user does not understand. What the employee once explained verbally becomes a silent interface that throws the entire burden onto the user without preparing them for it.
The logic of “government without forms” that we proposed in the structural dimension, and the data sovereignty we established in the governance dimension, must be reflected directly in reducing this cognitive load. If the state has the right to reuse the data it already possesses, it has a duty not to require the user to enter it again. And if it has the right to build clear state models for each service, it has a duty not to force the user to understand every legal detail in order to complete a single step.
The solution here is both engineering-based and experimental: (1) engineering-based, when services are designed according to the principle of “the minimum necessary inputs.” Every field requested from the user should be reviewed against a simple question: does the state already possess this information in a sovereign source? If the answer is yes, it should not be requested. And (2) experimental, when every form and every service journey is tested on real samples of users, not only on designers’ desks. The time a beneficiary needs to understand each step should be measured, points of hesitation should be observed, language should be simplified where people stumble, and steps should be rearranged where errors recur.
Because this work cannot be left to the independent judgment of each entity, the “national experience system” must set mandatory standards for linguistic simplicity, upper limits for the number of fields in each step, and recommendations for presenting options gradually through Progressive Disclosure, rather than overwhelming the user with everything at once.
Lack of Trust: When the Experience Betrays the Promise of the Digital State
The images of queues, delayed transactions, and the “specialized employee” who never appears still live in society’s memory. This memory is not erased by launching an application, but by accumulating successful experiences. Any digital experience that ends without a clear result, with an unexplained error, or with a path that stops without an exit brings that old memory back to the surface and reinforces in the user’s mind that “digitization” is merely a new cover for an old incapacity.
Usability trust is not built on appearance, but on “predictability.” The user wants to know: what will happen after this step? What does this button mean? What happens if the connection is interrupted? What if I try again? Where can I follow up if the service fails? If the platform does not answer these questions clearly, every new experience becomes an adventure, not a reassuring path.
For this reason, the principle of “national observability” established in the technical dimension must be converted into a direct effect in the interface: (1) the user should be shown—moment by moment—what is happening in the background of the transaction, based on the “events” broadcast by the systems. (2) Error messages should be presented not as obscure codes, but as simplified explanations of what happened, with a clear indication of the entity responsible for the next processing step and the expected time for it, where possible. (3) The user should be able—from inside the application—to submit a report or objection that is recorded in the same system visible to the “national performance mirror,” so that their complaint does not disappear into the margins. In this way, every user experience becomes a brick in building trust, not a new story told about complexity hidden behind an elegant screen.
Multiple Channels: One State, Even When the Screens Multiply
The sixth usability challenge is the unorganized fragmentation of service pathways across different channels: an old website, the “Sahel” application, a call center, an in-person visit, and perhaps a special application belonging to a particular entity. Often, the user finds themselves starting in one channel and ending in another, without the same state accompanying them. Data is re-entered, steps are repeated, and traces of what has already been completed are lost along the way.
The smart state must be built on the principle of “multiple channels with one logic.” This means that the protocol, structure, and governance should allow a service—in principle—to be completed through any channel suitable for the beneficiary, but with one logic for data and statuses. If the user begins a transaction in “Sahel” and then, for any reason, has to complete it at a service center, the employee should see the same status, the same events, and the same restrictions—not another version that starts from zero.
To achieve this, technical linkage between channels is not enough. A governing rule must be imposed on entities: no service should be created for one channel only. It should first be created as a “national logic” of statuses and stages, and then its interfaces should be applied to different channels according to the characteristics of each channel. In this way, the state preserves the unity of the experience even when screens multiply, and the user does not feel that each channel has another state behind it.
From Passive User to Partner in Designing the Experience
The final usability challenge—yet the one with the deepest long-term impact—is that the user remains in the position of a “passive recipient” of an experience designed for them without their participation. The state, no matter how aware its experts may be, cannot encompass every detail of the lives of those it serves. Therefore, relying solely on a centrally designed experience deprives the system of one of the deepest sources of improvement: the experience of users themselves.
If the “protocol programming environment” has been opened to become a marketplace of programming guides among entities, the usability dimension calls for opening a parallel space for user experience: a space where people’s observations, suggestions, and experiences on the platform are managed, and where recurring complaints are converted into “User Stories” on the basis of which services are re-engineered. Participation can even go beyond opinion into the realm of building, through secure programming interfaces that allow community initiatives—whether startups or academic teams—to provide supporting tools on top of “Sahel” itself: tools for explanation, interactive assistance, or adaptation to the needs of specific groups, all within the framework of protocol, governance, and data sovereignty.
In this way, the user moves one step forward from the position of recipient to the position of partner. The experience no longer becomes a project imposed on people, but a path formed with them and through them, benefiting from their collective intelligence just as it benefits from the state’s institutional intelligence.
The Usability Dimension: Where the Reality of the Smart State Is Revealed
This reading makes clear that the usability axis is not a layer of “decoration” added at the end of the road, but the space in which every preceding layer is tested: structure, protocol, technology, and governance. The absence of data sovereignty appears in repeated forms; weakness of protocol appears in contradictory messages; governance shortcomings are seen in exceptions that the user feels before reading them in a report; and technical imbalance is reflected in a fragmented and unpredictable experience.
When these layers align together, it becomes possible, in the usability axis, to answer questions that seem simple on the surface but are profound in their effect: can any citizen or resident complete their most important transactions without constant human assistance? Is the user experience consistent, no matter how they move between entities and channels? Do they feel that the state truly knows them through the data it already holds, so it does not burden them with what it already knows? Can they understand—simply—what is happening to their transaction, when it is happening, and who is responsible for it? And do they feel reassured that every minute spent on the platform is less than a minute they would have spent in a queue yesterday? These questions, in the end, are not questions of interfaces, but questions of the state: what image does it want to present of itself in the eyes of those it serves? Does it want to remain a heavy apparatus seen from behind offices, or become a “clear and just service” held in the palm of the hand?
In the sixth and final part of this series, we will leave the space of details and move into the space of the “conceptual axis.” There, we will not ask how the platform is built or managed, but what kind of state we want to build through these tools: what is the image of the citizen, what is the meaning of public service, and what is the place of the human being in a state built on data and automation? There, the direction of the path is decided: will digitization become a tool for completing the humanity of the state, or a means of favoring the machine over the human being?
O Allah, ordain for this nation a matter of right guidance.