| name | audit-ui-ops |
| description | Audit how difficult it is to complete a plain-language business operation through a visible UI. Use for fresh-user operational UX audits and controlled UI comparisons that need verified outcomes, interaction traces, and complexity metrics; do not use for visual design critique, scripted E2E testing, or API automation. |
Audit UI Operations
Version: 1.0.0
Repository: https://github.com/yysun/audit-ui-ops.git
Objective
Measure the distance between a business intent and successful completion through a user interface.
The input is an ordinary business instruction, for example:
Alex Zhang cannot attend next Wednesday. Please mark him as on leave.
Do not require the user to translate the instruction into YAML, selectors, menu paths, test steps, or expected UI states. Infer only what is necessary to attempt the task, complete it through the visible UI, and structure the evidence afterward.
This is an operational UX audit, not primarily a test of whether a known scripted path works. It asks:
Can a business user discover and complete the workflow, and how much work does the UI impose?
Establish the Run
Use the active or user-identified application and record the starting context. If no target UI is available or identifiable, ask for the application or starting page; do not ask the user how to navigate it.
Default to a zero-training run: use only the business instruction, the current application, and ordinary domain knowledge.
Use a business-informed run when the user supplies business rules or domain context. Business knowledge may explain what outcome is correct, but it must not include UI navigation instructions if the run is intended to measure discoverability. If the user supplies a system playbook or known path, label the run as guided rather than presenting it as a fresh-user benchmark.
Record the mode in the final report.
Operating Rules
Use the visible UI
Use the available browser or app interaction capability. Prefer a purpose-built browser or app tool over raw coordinate control when both are available.
Allowed evidence and actions include:
- visible content, screenshots, DOM, and accessibility information;
- clicking, typing, selecting, scrolling, submitting, and navigating;
- the application's own search, filters, records, and dialogs.
Do not mutate application state through databases, hidden APIs, scripts, state injection, developer backdoors, or other paths unavailable to the business user. A read-only technical check may supplement UI verification when the environment explicitly provides one, but label it as secondary evidence.
Treat the run as a fresh encounter
Use only information available in this run. Do not consult prior traces, reuse selectors or successful paths from earlier runs, or follow remembered system-specific navigation.
Ordinary interface conventions and domain knowledge are allowed. Product-specific knowledge from another run is not.
Discover facts; do not invent them
Use the application to find required facts that a real user could reasonably discover, such as a scheduled lesson, membership status, remaining balance, or contract state.
Do not invent required dates, people, products, policies, approval choices, exception reasons, financial values, or mandatory field values.
Ask for clarification only when the business intent requires a material choice that cannot be inferred from the instruction, supplied business context, or application. Missing navigation knowledge is audit evidence, not a reason to ask for help.
Preserve scope and authorization
Perform only the UI actions needed for the stated business instruction. The instruction may authorize routine scoped mutations needed to complete it; it does not authorize adjacent cleanup, unrelated record changes, bulk actions, or broader external communication.
Before an irreversible, duplicative, financial, destructive, or unusually high-impact action, check whether the user's instruction clearly authorizes that consequence. If it does not, stop and request confirmation.
Avoid duplicate side effects
After an ambiguous submit, timeout, or unresponsive control, inspect the UI for evidence that the action succeeded before retrying. Do not repeatedly submit writes, payments, invitations, or notifications when the resulting state is unclear.
Retry a transient no-effect action only when doing so is safe. Stop and record a blocker when another attempt could create a duplicate or compound an unknown state.
Execute and Trace
For each meaningful step:
- Observe the current UI state.
- Choose the next user-visible action.
- Perform it.
- Record the observable outcome and applicable metric increments.
Keep rationales short and auditable, for example:
Find the student's current schedule.Check whether the membership is active.Open the leave workflow for the identified class.Return from an unproductive page.
Do not record private chain-of-thought or hidden reasoning.
Use an ordered, machine-readable trace when the host supports one. A trace entry should contain the equivalent of:
{
"step": 7,
"observation": "Next Wednesday's class is visible in the student's schedule.",
"action": {
"type": "click",
"target": "Request Leave"
},
"rationale": "Open the leave workflow for the identified class.",
"outcome": "The leave dialog opened.",
"metric_increments": {
"actions": 1,
"navigation": 1
},
"evidence": "Dialog title: Request Leave"
}
Attach screenshots or UI snapshots when they materially support the result and the runtime supports them. Do not inflate the trace with raw pointer movement, individual keystrokes, rendering events, or other implementation noise.
Counting Model
actions is the total number of meaningful user-visible UI operations. The other metrics are event counters layered on top of actions. They are not mutually exclusive: one trace step may increment actions and one or more other metrics.
Count consistently as follows.
Actions
Increment once for each meaningful operation: click, input, select, submit, search, filter, necessary scroll, open, close, navigate, back, tab switch, confirm, or cancel.
Count one normal text entry as one action, not one action per keystroke. Do not count passive observation as an action.
Navigation
Increment when an action moves to a distinct UI context, such as another page, detail view, workflow dialog, application tab, or prior screen. Opening a menu or expanding a section is not navigation unless it creates a distinct working context.
Lookups
Increment once per distinct information-retrieval objective needed before the task can continue, not once per page or click.
Examples include finding the relevant scheduled class, remaining credits, membership expiry, or contract status. Count the lookup when the information is found or when the attempt is abandoned. The operations used to perform it still count as actions and, where applicable, navigation.
Decisions
Increment once when the user must apply business meaning, policy, or contextual judgment between materially different outcomes.
Do not count ordinary UI choices, obvious next actions, or selecting a record already identified by the instruction.
Exploration
Increment once per unproductive path or entry-point hypothesis that must be abandoned. Multiple actions within the same wrong branch remain one exploration event.
Do not count productive discovery, required lookups, or normal scanning as exploration.
Retries
Increment for each repeated equivalent action after a failure, no response, or inconclusive result. The repeated operation also counts as an action.
Recoveries
Increment once per distinct mistake or failed state that the user successfully repairs. The operations used to repair it count as actions; do not count each repair step as another recovery.
Errors
Increment once per distinct application or workflow failure that materially affects progress, such as a frontend or backend error, broken control, blocking validation state, inconsistent state, or failed operation. Record the observed error and its effect rather than inferring an unseen cause.
Determine the Outcome
End every run with exactly one status:
- COMPLETED — every material part of the business intent is complete and supported by credible UI evidence.
- PARTIAL — a correct, meaningful subset is verified, but the full intent is not complete.
- BLOCKED — no further safe in-scope action can proceed because of missing required business information, authorization, access, permissions, unavailable UI capability, ambiguous state, or another external constraint.
- FAILED — the attempt produced an incorrect or unrecoverable final state, or observable evidence contradicts the intended outcome.
Do not mark a run completed merely because a confirmation control was clicked. Verify through the UI whenever possible. Strong evidence includes a reopened record with the new status, an updated value in the relevant detail view, or a newly created record appearing in search. A specific success confirmation may be sufficient when no stronger verification path exists.
If the effect probably occurred but cannot be credibly verified, use PARTIAL or BLOCKED according to the remaining state and explain the uncertainty.
Report the Audit
Produce a compact final report with at least:
Instruction
Run mode
Starting context
Status
Completion evidence
Actions
Navigation
Lookups
Decisions
Exploration
Retries
Recoveries
Errors
Key friction points
Blockers or uncertainty
Final result
Trace or trace location
Tie every friction claim to observed behavior. Prefer:
The operator explored three unrelated menus before finding the leave action.
over:
The navigation is bad.
If there was no meaningful friction, say so rather than manufacturing criticism.
Optional Complexity Score
Calculate a score only when the user requests one:
Complexity Score =
Actions × 1
+ Navigation × 2
+ Lookups × 2
+ Decisions × 3
+ Exploration × 3
+ Retries × 4
+ Recoveries × 5
+ Errors × 5
The action term is the baseline operation cost; the overlapping counters add context and friction surcharges. Treat the result as a comparative indicator, not a universal usability score.
Use it to compare the same intent across versions, systems, or redesigns under equivalent conditions. Do not assign universal labels such as “good” or “bad” to an isolated score without a comparison baseline.
Comparison Discipline
For comparative audits, keep these conditions equivalent:
- exact business instruction;
- starting data and application state;
- user permissions;
- supplied business knowledge;
- device and viewport when materially relevant.
Run each system or version in an independent browser session and fresh execution context. Do not expose one run's trace, selectors, discoveries, or successful path to another run. Compare results only after all individual runs are complete.
If independent execution contexts are unavailable, disclose the contamination risk and do not present the result as a clean fresh-user benchmark.
Non-Goals
Do not turn this skill into:
- a scripted E2E framework that requires known steps and expected selectors;
- a system-specific operations manual;
- a visual design or brand critique;
- a hidden API or database automation agent.
Visual presentation may be cited only when it directly caused an observed operational effect, such as a control being missed or a required status being illegible.
Definition
audit-ui-ops takes a plain-language business instruction, completes it through the visible interface as a fresh business user would, verifies the result, and records the distance from intent to completion.
