Enterprise AI UX starts with who can do what
Enterprise UX and research
Published Updated 4 min read
An assistant drafts a convincing answer from company documents. The demonstration goes well until someone asks whether a contractor would see the same answer. Another person asks whether the assistant can send it to a customer. The room has moved from judging a response to deciding who is allowed to act.
For an enterprise AI interface, that is where the design work becomes concrete. Before choosing a chat layout, define what each user can read, propose, approve, and change. Then make those boundaries understandable in the interface and enforce them in the underlying system.
The scenario above is illustrative. Its purpose is to reveal the decisions a prototype must expose before anyone mistakes a polished conversation for a complete product.
What belongs in a permission map?
Start with a real task rather than a universal “AI assistant” role. For example, an account manager wants to prepare a renewal summary. Reading an approved contract, drafting an internal note, and sending a commercial offer have different consequences.
Use a proposed map like this during discovery:
| Task | Information available | Allowed action | Review needed |
|---|---|---|---|
| Summarize an account | Records the user can already access | Create a private draft | User checks the sources |
| Suggest an offer | Approved terms within the user’s scope | Prepare a proposal | Commercial owner reviews |
| Send the offer | The approved proposal and recipient | Send through the authorized channel | Explicit final confirmation |
The map is a design aid, not a security implementation. Engineering must enforce access on retrieval and execution. Hiding a button or asking a model to respect a role does not establish a permission boundary.
How should restricted information appear?
Designers need to distinguish information that is missing, unavailable, outdated, or outside the user’s access. These situations lead to different next steps.
A summary based on an old contract should identify the version it used. A request that needs a colleague’s approval should route to the appropriate owner. A request for inaccessible material should avoid revealing the material through an explanatory preview.
The interface also needs to show the scope of a proposed action. “Update account” is too vague if the assistant will change several fields or notify other people. A review screen should name the affected records, show the proposed changes, and make exclusions visible.
ServiceNow’s AI design guidance emphasizes transparency and human control. The practical design question is what a person needs to see to exercise that control in this particular workflow.
What happens when permission changes halfway through?
A user can lose access between asking a question and approving an action. A document can move. Another colleague can change the record while the assistant is preparing its answer.
Prototype those transitions. In the renewal example, let a reviewer change the offer while the original user has the confirmation screen open. The next action should check the current state and explain any conflict. It should not silently apply an obsolete proposal.
The same principle applies to recovery. A canceled draft may be easy to restore. A message already sent to a customer cannot be made unsent by putting an “Undo” label beside it. Microsoft’s undo pattern is useful when reversal is possible; product teams still need to define the actual limits of reversal.
Test the point where the assistant hands responsibility back to the person. Can the user tell what happened, what remains pending, and who should act next?
Which evidence should a design partner show?
For an enterprise AI project, request a walkthrough that includes restricted access, stale information, and a failed action. Ask who worked with engineering on the permission model and how the team tested the recovery flow.
A portfolio full of fluent responses can demonstrate presentation craft. It does not establish that the agency can design actions across several enterprise roles. Conversely, experience with complex internal tools does not automatically prove expertise in AI behavior. Look for evidence of both, or agree how the project will close the gap.
Humbleteam’s AI in SaaS service describes work on assistants and human review flows. Use that scope, or another candidate’s documented work, to ask for a relevant case discussion rather than accepting an “AI-native” label on its own.
The first deliverable can be small: one permission map and one prototype that deliberately encounters a boundary. If everyone can explain why the assistant stopped, what it changed, and what the user can do next, the team has something concrete to evaluate.
