Role and authority display is a broader design problem than what menus are shown to a person. Who can see which record, which action can be taken, and when a change will take effect should be defined together. The interface makes these rules understandable; Security control should be implemented by server-side authorization. Hiding a button is not access control.
Prepare processing matrix before drawing screen
Let's consider three roles in a hypothetical quote management product: sales worker, team manager, and system administrator. This example is not an actual customer result. Instead of guessing everyone's authority based on role names, list concrete actions.
- The sales employee can create his own quote and edit it while it is in draft status.
- The team manager can review the proposals of his own team; Which transactions it approves is determined by the product rule.
- System administrator can manage user access; The commercial approval authority of this role is decided separately.
For each rule, type action, record scope, and condition. The phrase “may edit proposals” is missing: all proposals, own records, drafts only? The authority matrix makes this ambiguity visible before the screen design.
Role, record scope, and status are separate decisions
The same role can see different records in different teams. Additionally, changing a completed record may be prohibited, even if the user has editing authority. Combining these statuses into a single “you are not authorized” message hides the source of the problem.
For example, the message “This proposal cannot be edited because it has been approved” and the message “You do not have access to this team's proposals” lead to different next steps. The first may include a new versioning path; In the latter case, an access request may be required. Determine with security and product contacts what information can be displayed. It may not be desirable to explain the existence of a secret record that the user cannot access with an error message.
Hide or disable?
Not displaying an administrative tool that is irrelevant to the user's work can simplify the display. On the other hand, the action that the user can normally perform, but cannot complete in the current situation, can be disabled by explanation. There is no single universal rule here; user task and information security are evaluated together.
Don't leave the reason for the disabled button to a mouse-only explanation. Provide status text that can be understood by keyboard and touch device. If the user is waiting for a confirmation, explain who they are waiting for a response from and at what stage the process is, with information that is appropriate to share.
Show the result in advance when changing roles
Imagine a manager changing another person's role. The confirmation screen just says “Are you sure?” It should explain which accesses will be added or removed. Whether the effect will occur immediately or upon re-entry should be specified according to the technical behavior of the product.
Show selected number of people and scope in bulk change. If the operation fails for some users, do not give a successful message to all of them. Separate successful and unsuccessful records; Be clear what trying again will do. Product rules should be defined separately for critical situations such as deauthorizing the last administrator account.
Do not submit only success status in the design file
The screen list to be transferred to the developer should consider at least the following situations:
- Authorized user and successfully uploaded records.
- Empty list with no users added yet.
- Standby status while authorization change is in progress.
- The server rejects the operation or the session ends.
- Partially completed batch process.
- Changing the user's access by another administrator while the screen is on.
In each case, specify the text to be displayed, the actions available, and the path the user can return to. For example, when saving a form that remained open with the old authorization, the server may reject the request. The interface should explain this and honestly show whether the data entered is protected.
Check with the task, not the role name
“Is the sales role working?” instead of “What happens when a salesperson tries to edit another team's offer?” Use concrete scenarios such as: Design evaluation is not a substitute for server authorization tests; They should both be based on the same rules.
When planning UI/UX design work with Selçuk Aker, you can share the process and recording scopes as well as the role list. This way, situations and delivery expectations can be determined before the number of screens is discussed.
Frequently asked questions
Is it necessary to design a separate screen for each role?
Not always. Common components can be used; however, visible transactions, recording scope, and statuses must be clearly defined. Significant differences should be shown in the design file.
Does hiding the button prevent unauthorized operation?
No. It is necessary to validate the transaction request on the server side. Visibility in the interface tells the user what actions are available; It does not create a security boundary.
With whom should the authority matrix be prepared?
Product and business managers, designers and the development team should work together. Rules that require security evaluation should be checked by the relevant technical officers.
