UXit Documentation
Guidelines

Writing Criteria

Write clear, objective criteria that become guideline conditions.

Overview

Criteria are the standards your team wants to evaluate. In the Guidelines workspace, each saved criterion is added as a Condition inside a category.

A good condition should be objective, specific, and answerable during an Evaluation. The evaluator should be able to look at the design, prototype, page, or flow and decide whether that condition passes, fails, or does not apply.

Use Organizing Categories & Conditions for the mechanics of adding, moving, excluding, or deleting conditions. Use this page when you are deciding what the conditions should actually say.

Writing Strong Conditions

A strong condition is:

  • Specific and testable.
  • Focused on one idea.
  • Observable in a mockup, wireframe, prototype, page, or flow.
  • Easy to judge as Pass, Fail, or NA.
  • Written as a factual check instead of an opinion prompt.
Not clear: "Is the design good?"
Clear: "Primary actions are visually distinct from secondary actions."
Too broad: "Are buttons clear and accessible?"
Better: "Primary buttons are clearly distinguishable from secondary actions."
Better: "Interactive elements meet minimum touch target size requirements."
Too vague: "Is the spacing adequate?"
Better: "There is at least 16px spacing between form fields."

If the evaluator has to guess, debate, or interpret the wording too much, the condition should be tightened.

Keep Conditions Concise

Keep each condition short enough to scan quickly during evaluations. Long, paragraph-style conditions slow the review down and make scoring less consistent across evaluators.

If a condition needs more explanation, split it into separate checks or use the surrounding category structure to provide context.

Condition IDs

Each condition receives an auto-assigned ID based on its category. These IDs make it easier to reference specific findings in tickets, design reviews, Analytics, and Handoff notes.

For example, a team might call out ACC-012 or USA-008 instead of repeating the full condition text every time.

Accessibility
├── ACC-001 Text meets minimum contrast requirements.
├── ACC-002 Interactive elements meet minimum touch target size requirements.
└── ACC-003 Text remains readable when zoomed.

Usability
├── USA-001 Primary actions are visually distinct from secondary actions.
├── USA-002 Navigation labels are clear and consistent.
└── USA-003 Form inputs provide clear labels and states.

For reordering, moving, excluding, or deleting existing conditions, use Organizing Categories & Conditions.

Best Practices

  • Write conditions as checks an evaluator can answer without debate.
  • Place each condition in the category that best reflects the issue it measures.
  • Keep conditions stable over time when you want cleaner trend comparisons in Analytics.
  • Duplicate or version a Guideline Set before major rewrites.
  • Aim for a practical sweet spot. Too few conditions can limit the value of Analytics, while too many can make evaluations slower and harder to maintain.

On this page