Best Practices
These examples are useful where the component reference leaves room for a design decision.
A table that is easy to scan
Consider a table in which users need to identify a record, assess its status, and decide what to do next. A recognisable name or identifier followed by the few values that support that decision keeps the focus clear. Filling a table with every field available on the entity can make it harder to scan.
For a status, text such as Open, Approved, or Action required conveys the
meaning alongside a coloured dot, check mark, or warning icon. An icon can make
the column easier to scan, but it cannot be the only way to understand a value.
Column titles that explain what a value means reduce ambiguity. For example,
Created on, Last changed, and Due date are clearer than Date. Units help
users interpret a number where they are relevant.
A form for one task
When users create or change a record, task-relevant inputs and related field groups help them focus on that step. Internal IDs and calculated values are best kept out unless they support the task. Where a calculated value is useful, presenting it clearly as information avoids confusion with editable input.
A mandatory marker is meaningful when the record cannot be created or changed without the field. When validation fails, user-facing correction guidance is easier to act on than an internal field or rule name.
Actions that fit the screen
On a record screen, routine actions are easier to use when users can find them
quickly. A title such as Approve request is clearer than a generic title or
an icon without a text alternative. An icon-only presentation is best reserved
for cases where the documented component provides an appropriate tooltip.
An action provided by the entity is not necessarily helpful on every screen. For example, an action that starts an administrative process can distract from the actions users need for routine record work. Consistent wording and grouping across contexts and views creates a more predictable experience.
Review a realistic workflow
Reviewing the configured screen with representative data and relevant roles helps reveal the real experience. A sequence such as finding a record, checking its status, changing a value, and completing the next action provides useful evidence; the Designer configuration alone does not show the complete flow.
Review each device variant used by the project. Tablet and mobile may benefit from a different information order or a smaller set of actions. The UX review checklist provides a place to record the tested configuration and known limitations.