In an internal application, “process a case” is rarely a straight path from A to B. One person creates it, another adds documents and a third approves the next step. Information may be missing, someone may be covering for a colleague or the case may sit untouched for several days. A design showing only the ideal path leaves the important working questions unresolved.
Describe the case across roles
A real business process with anonymised example data helps you understand the decisions behind the interface. It reveals who may act at each point and what information they need. Visible roles then need to match actual permissions, because hiding a button alone does not technically prevent access.
A material request might begin with employees describing what they need, followed by a workshop manager reviewing the request and purchasing placing the order. Each role has different questions: did my request arrive, is there a follow-up question, can I still change the quantity, and has the order actually been placed or merely approved?
NN/g’s guidance on complex applications includes nonlinear workflows and handovers between roles. The design therefore needs to make interruptions and handovers as tangible as the initial input.
Give states a business meaning
A small state overview reveals decisions still missing from the flow. If “Open” includes drafts, questions and approved cases, the next person cannot tell what to do from that label. A useful state name therefore explains what is settled and who can act next.
| Example state | Next responsible person | What remains possible |
|---|---|---|
| Draft | Request creator | Edit or discard the details |
| Submitted for review | Workshop manager | Approve or ask a question |
| Approved for ordering | Purchasing | Prepare the order; resolve changes under the agreed rule |
Adapt these states to your own business rules. A designer should not have to infer who may approve an order from a requested arrangement of buttons.
Design for returning and exceptions
After an interruption, people need a recognisable state. In the material request, they should be able to see whether someone has asked a question, approved the request or placed an order since their last action. Show who needs to act next as well. For long lists, appropriate filters and returning to the previous position belong to this task.
Unresolved rules become particularly visible when two people work on the same case: one changes the quantity while the other approves it. For the interface to explain that conflict clearly, development first needs to establish whether the edit is blocked, reloaded or merged. That decision therefore belongs in an early discussion with developers.
Testing only with the person who explained the process does not yet show the everyday handover. When each role performs its own tasks, you can observe whether the visible state tells people when to act and when editing is no longer possible.
A complete case, including a follow-up question and handover, gives UX decision support a concrete starting point. Naming the action each role is permitted to take helps distinguish an unclear presentation from a missing underlying rule. The guide to customer portal roles and permissions explains the technical enforcement of those rights.
