Show the object and version under review
An approval without a stable target is not reviewable. Name the item, the version or timestamp, the decision policy, and the material change. If a newer version appears before submission, block the stale decision and offer the current version. Do not silently apply approval for version 7 to version 8.
For a compact screen, use a summary such as:
| Review fact | Example |
|---|---|
| Item | August client reminder copy |
| Version | 7, submitted 09:12 PDT |
| Requested by | Casey |
| Decision affects | Scheduling eligibility |
| Current reviewer role | Operations approver |
The GOV.UK check-answers pattern demonstrates a review step immediately before an important submission and recommends a submit label that names the action. The exact layout is not the point; the user needs a chance to verify what the decision will affect.
Give each outcome its own contract
Approve accepts the reviewed version and moves it to a named state. A note may be optional unless policy requires evidence.
Request changes returns work to a named person or queue. It needs an actionable change request and should preserve the current review history.
Reject ends or blocks the proposal under a defined policy. It is not a shorthand for “not yet.” If rejection can be appealed or reopened, show that path; if it cannot, say so before submission.
W3C labels and instructions guidance supports clear instructions where users must enter information. Avoid forcing a reason for every outcome by habit. A required reason should come from the workflow's accountability need, and the interface should explain when and why it is required.
Use one reviewable selection
Three always-visible radio options followed by one explicit Submit outcome control can make the selected consequence and conditional reason easy to inspect. Separate action buttons can also work. In either case:
- the accessible name must contain the real action;
- color cannot be the only distinction;
- keyboard order must preserve the screen's meaning;
- the least frequent action is not automatically the most dangerous;
- the interface must not preselect an irreversible decision; and
- visible availability must not be treated as authorization.
For a legal, financial, or important data-changing outcome in scope, W3C's error-prevention guidance calls for reversibility, checking, or confirmation. Apply that rule to the actual consequence, not to the word “approve.”
Confirm the resulting state and owner
After the server accepts the decision, show the object version, recorded outcome, resulting state, next owner, and any next step. GOV.UK's confirmation-page guidance emphasizes giving users a durable end state and useful next steps. An approval screen should similarly avoid a vague “Success” banner that leaves ownership unclear.
If the server rejects the decision because permission or version changed, preserve the entered reason where safe, state what did not happen, and route the reviewer to the current object or escalation path.
Acceptance checks
- The item and reviewed version are visible before a decision.
- Each outcome states its consequence and resulting workflow state.
- Reason requirements come from policy and are explained next to the input.
- No irreversible outcome is preselected.
- A newer version blocks a stale decision.
- The server checks current permission and allowed transition.
- Pending submission cannot create duplicate decisions.
- Success names the accepted outcome, state, version, and next owner.
- Failure preserves useful input and never implies that the decision was recorded.
These checks specify the interface contract. They do not define the organization's approval policy, separation of duties, audit retention, or notification rules; those must be supplied by the workflow owner.