| UI or UX | UI + UX - Routed decision workflow for requests that require authorized approval | UI + UX - Final editable answer summary before committing a transaction | UI + UX - Guided workflow for regaining or routing around missing access | UI + UX - Invitation lifecycle for granting another person access | UI + UX - Consequential alert decision | UI + UX - Searchable and exportable record of system, user, or administrative events | UI + UX - Durable user-opened notification history and action drawer |
| UI guidance | Render approval workflow as a routed request record with requester, object, requested action, approver eligibility, required rule, current gate, due date, decision controls, comment history, and outcome consequences. | Render a single review page immediately before commit with a clear title, grouped answer sections, readable key/value rows, per-answer or per-section Change actions, skipped optional answers when meaningful, and a primary button whose label names the committed action. | Show a recovery workspace after denial with the current account, current role, requested role, safe owner or admin destination, request reason, policy limits, status timeline, and original blocked task. | Render invite user as an access-granting workflow with recipient identity, role or permission, team or channel scope, optional message, delivery method, expiry, pending status, resend, edit, cancel, and acceptance outcome. | Render an alert-style modal decision with a specific title, consequence description, safe cancellation, and a destructive action label that names the object or scope. | Render activity logs as evidence-oriented records with event time, actor, action, object, source system, scope, result, and technical context such as IP address or location when available. | Provide a persistent notification entry point, usually a bell or inbox control, with a count that represents new unseen notifications rather than every unread item forever. |
| UX guidance | Make the approval route understandable over time: who has the request, what decision is needed, what happens on approval or rejection, what blocks self-review, and where the requester can revise or withdraw. | Use review before submit to give users one final chance to verify and correct captured answers before a transaction is sent, paid, published, applied, or otherwise committed. | Use permission recovery when users can take a concrete step to regain access, use another identity, request a different role, escalate a policy block, or continue with a safe fallback after an authorization denial. | Use invite user when an authorized person needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object. | Help the person reach a clear task outcome. | Use activity log when users need to investigate, audit, verify, or troubleshoot actions across accounts, objects, systems, settings, or security boundaries. | Use a notification center when users receive enough asynchronous system or collaboration updates that they need a durable place to review, triage, and act later. |
| Good UI | A production deployment request shows requester, service, environment, change summary, required reviewer group, self-review restriction, wait timer, Approve and Reject with reason controls, and a timeline of route changes. | A claim review page has Applicant, Contact details, Evidence, and Declaration sections; each row shows the captured answer and a Change link with hidden context such as Change email address. | A restricted report recovery panel shows alex@northwind.example lacks Finance viewer access, lets the user request Viewer or Editor with a reason, names Priya as the approver, shows request ACC-2048 as pending, and returns to the report after approval. | A workspace invite form accepts maya@example.com, labels the invite as Workspace member, shows default channels, explains billing impact, lets the inviter add a message, and shows the pending invite with resend and cancel actions. | Delete Research archive? explains that 14 notes and shared links will be permanently removed, offers Keep archive, and labels the danger action Delete archive. | An organization audit log table shows timestamp, actor, action, target object, app, IP address, result, and a Details drawer with before and after fields. | A bell opens a drawer with Unread and All filters, showing comment mentions, approval requests, export results, and background-job failures in newest-first order. |
| Bad UI | A stale email approval applies to a request version that has changed. | Change links lack context, so assistive technology users hear a list of identical Change links. | A blocked report only has Retry, so the user repeats the same denied request. | A user gets admin or organization-wide access because the invite defaulted to the broadest role. | The red destructive action is enabled immediately and sits where users expect the routine primary button. | An export button downloads a different date range and timezone than the on-screen filtered log. | Users ignore the center because duplicate low-value messages inflate the badge. |
| Good UX | A finance approval requires both manager and controller approval; the first approval advances the sequence, a rejection stops downstream processing, and the requester sees the exact rejection reason and revise action. | A user changes their phone number from review, lands on the phone page with the old value pre-filled, saves, and returns directly to review with other answers preserved. | A user requests Finance viewer access with a reason, sees the request is pending with Priya, receives approval, opens the report from the same recovery panel, and lands back on the original report. | An admin invites an external contractor as a single-channel guest, sees the one-channel limit, adds a note, sends the invite, then extends it when it is still pending after 30 days. | Cancel, Escape, and Keep archive leave the archive unchanged and return focus to Delete archive. | An admin filters to failed SSO events, expands one entry, copies the event ID, exports the filtered range, and sees that records older than 180 days require a different archive. | Opening the notification drawer clears the new-notification badge while unread items remain available for later triage. |
| Bad UX | The first approver clicks Approve and the system marks the whole request approved even though policy required everyone to approve. | A user selects Change address, edits one field, then has to repeat every later page before finding the review page again. | A user repeatedly clicks Retry on a permission denial because the UI treats authorization as a transient load failure. | A user gets admin or organization-wide access because the invite defaulted to the broadest role. | Every archive, filter, and dismiss action opens the same confirmation until users click through automatically. | A user marks a notification read and the corresponding activity evidence disappears from the only log. | Users mark all notifications read and lose the only record of an export job they still need to download. |
| Best fit | A submitted request needs authorized approval before a deployment, purchase, access grant, publication, content change, policy exception, financial action, or workflow step can proceed. | A user has provided multiple answers and should verify them before a consequential submit action. | A denied user can request access, switch accounts, ask an admin, join a group, or use a safe fallback to continue. | An authorized user needs to bring another person into a workspace, organization, project, channel, repository, team, tenant, or shared object. | The action is destructive, irreversible, costly, security-sensitive, privacy-affecting, or externally visible. | Users need to inspect recorded user, admin, system, security, or integration events. | Users receive multiple asynchronous updates across objects, jobs, collaborators, approvals, or reminders. |
| Avoid when | The user only needs to check their own answers before submission. | The task is a single low-risk field with clear inline validation and an obvious submit action. | The user is unauthenticated and the next step is sign-in or session extension. | The current user is creating their own account or profile. | The action is routine and easily reversible. | The goal is only to show a readable milestone history for one case or process. | The product has only occasional current-action feedback that a toast or inline status can handle. |
| Required state | Draft or submit-ready request handoff state | Initial review state with grouped captured answers, relevant sections, and explicit submit action. | Recovery start state with original blocked task and current account. | Recipient entry or directory lookup state | Pre-action state with an explicit consequential trigger. | Default log state with event records, result count, visible timezone, retention window, and permission scope. | Closed entry-point state with zero, new-unseen, and unread-but-seen counts. |
| Accessibility burden | Use labelled request summary, approver, status, due date, decision, comment, and history regions. | Use headings that make the review task explicit, such as Check your answers before sending your application. | Move focus to the recovery heading when the workflow opens from a denial. | Use labelled fields for recipient, role, scope, team, channel, message, and expiry. | Use alertdialog semantics or platform equivalent when the decision is urgent and requires a response. | Use table or structured list semantics so actor, action, object, timestamp, result, and scope are perceivable together. | Announce new notification arrival with status semantics when appropriate, but avoid interrupting users repeatedly for low-priority center items. |
| Common misuse | Treating the first approval as final when the rule requires more approvers. | Labelling the final commit button Continue. | Offering Retry for an unchanged authorization denial. | Treating invitation sent as if the user is already a member. | Asking users to confirm every routine action until they stop reading. | Using vague activity labels that omit actor, action, object, timestamp, or result. | Treating the badge count, unread count, and total notification count as one number. |