Illustrative scenario · B2B permissions

Let administrators see the consequences before changing access

An administrator is about to change a colleague’s access in a fictional business tool. The labels “Standard” and “Advanced” say little about what will happen next.

Illustrative scenario. The organisation, interface and research plan are fictional. This is an explanation of our approach, not a completed client study.

The question behind the interface

Role names conceal the actions and records a person will be able to view or change. An administrator may complete the form while misunderstanding the consequence. This example focuses on comprehension of the interface; it is not a security or authorisation assessment.

A proposed direction

Compare permissions in plain language, preview affected access and provide an explicit recovery route appropriate to the underlying system.

Illustrative interface · Proposed design · B2B permissions
Fictional example

Review an access change

Dummy record: Alex moves from Viewer to Editor. They would gain permission to edit project notes.

Review affected access →
  1. Compare permissions
  2. Preview the change
  3. Confirm deliberately

Static design example. The depicted action is not an interactive product control.

How we would investigate it

Ask an administrator to give a dummy colleague a specified capability while preserving a stated restriction. Work in a prototype or isolated test environment. Observe whether the person predicts the result and notices an unintended permission.

Before recruiting, we would agree the decision the study must support, the people whose experience matters and a realistic task. The session plan would specify a safe starting state and avoid leading the participant towards the proposed solution. Relevant access needs, consent and handling of research material would be included in the scope.

The tradeoff to examine

An undo button is safe only where the underlying system can actually reverse the change. Revoking access may not retract downloaded information. Permission descriptions and recovery behaviour must be reviewed with the product’s technical owners before implementation.

What would count as useful evidence?

Prediction of access consequences, recognition of affected people or records, deliberate confirmation and discovery of a safe correction route.

Record the actions, misunderstandings and assistance required. Keep participant comments separate from interpretation and show important exceptions as well as patterns. A revised design would remain a proposal until it had been evaluated; task completion in a small qualitative study would not establish a population-wide conversion rate.

What this example leaves open

No participants were recruited for this scenario, and no improvement or commercial outcome has been measured. The screens explain an approach. In an actual engagement, the evidence could support a different recommendation, expose a constraint not visible here or show that another problem deserves priority.