UX Review Checklist

This checklist supports reviews of new or changed screens. It does not replace the component reference or a formal accessibility assessment.

1. Establish the technical basis

• Has the selected viewtemplate and layout been captured?
• Does the viewtemplate reference document the configuration used by the screen?
• Does the support matrix cover the intended use and configuration?
• Would another purpose or undocumented configuration benefit from a separate review?

2. Review the user task and visible information

• What task can users complete on the screen?
• Are the visible fields and records focused on that task?
• Does the information order support the next action?
• Is related information reachable when needed?
• For data entry, do fields, validation, and messages provide sufficient guidance? See Forms and validation.

3. Review labels, navigation, and actions

• Are names for menus, contexts, views, and dashboards clear?
• Do action titles and icons follow the wording conventions?
• Are recurring fields, actions, tabs, and status representations consistent across comparable contexts?
• Is the next action identifiable ?
• What does the action flow look like in the client, including its resulting screen?
• For each business-critical action, have result, confirmation, and error feedback been captured?

4. Review visual presentation

• Does the screen work with the central theme rather than a separate color system?
• Does normal-size custom text reach a contrast ratio of at least 4.5:1?
• Are status, priority, and errors understandable without color alone?
• Does the viewtemplate fit the data scope?
• Are displayed dates, numbers, currencies, and units clear and consistent wherever they represent the same business value?

5. Desktop, tablet, and mobile use

• Which device variants and orientations does the screen support?
• Has each supported variant been reviewed? The current approach assumes landscape for tablet and portrait for mobile.
• Do information and actions remain usable in each orientation?
• Does the actual configuration work on tablet and mobile, rather than only on desktop?
• The device-specific design reference describes the technical test procedure.
• Has WebContent or other non-standard content received a separate review? See Custom and embedded content.

6. Review accessibility-related behavior

• Is enableA11y enabled for the review user when required?
• Do keyboard operation, visible focus, labels, and non-color cues work as expected?
• How do actions, errors, and status changes behave with the required assistive technology?
• Have limitations of the viewtemplate or configuration been captured?
• Have the roles and permissions used by the project been reviewed? See Permission-aware interfaces.

See Devices and accessibility for the relationship between this review and WCAG and BITV.

7. The review outcome

For each reviewed screen, the following information is useful to retain in the project:

Item	Record
Screen	context, view, and business task.
Components	viewtemplate and layout.
Configuration	Relevant fields, actions, navigation, and device settings.
Test scope	Device variant, browser, orientation, and accessibility setting.
Result	Confirmed behavior, open limitation, or required follow-up.

One screen or configuration cannot support a general device or accessibility claim.