Singapore UX workshops: examine whether users can recover from a form error

The problem

A Singapore UX researcher shows an error-state screen in a portfolio, but has not examined whether someone understands the correction or can continue without re-entering unrelated information.

Create one understandable failure

Use an invented entry that violates a known requirement, such as a missing mandatory field or an incorrect format. State the requirement and the desired successful result in your preparation notes. Do not introduce several unrelated errors at once: you need to learn whether the person can find and correct this particular problem, rather than measure their tolerance for confusion. Choose one task and name the rule the particular exercise actually supplies. Record what was entered, what happened on submission, which explanation appeared and which other fields still contained their values. A red outline alone does not describe the correction needed. An error message can explain a problem while the interface still loses unrelated work. Keep these observations distinct so a critique can address the actual recovery difficulty. State participant recruitment and review limitations separately, and keep keyboard focus and persistent field meaning as distinct interaction questions.

Keep a before-error-after record

Write six fields: task and stated input rule; original entered values; submitted state; error wording and location; other values remaining after rejection; and correction attempt with its result. Include assistance and material origin. Record “not inspected” when an unrelated field was outside the observation instead of declaring that every value survived. A screen showing an error and a later screen showing acceptance are insufficient to reconstruct the intermediate changes unless the record supplies them. Use wholly invented values or material the actual setting permits. These fields help plan a critique; they do not prescribe a production validation rule.

Test what the explanation tells the person to do

SGDS v2 guidance calls for explanatory errors beyond colour alone. In the critique, ask a participant what went wrong and what they would change before giving any hint. A message can identify the field but still fail to explain an acceptable entry. Compare the words with the field's visible label and the actual validation condition. Retain the reference’s scope: the SGDS v2 accessibility page is dated 31 May 2024 and displays a version3 notice. Its explanatory-error guidance provides historical design context, rather than a current standard or a certification of your form. Use the rejection-and-correction record to retain what changed. Obtain allowed input and acceptance rules from the actual product or exercise. Do not infer a rule from this guide’s invented number example or change somebody’s real information merely to make a submission pass.

• SGDS | Accessibility ↗ · Source checked 8 October 2026

Inspect an invented copy-count rejection

All fields, values and states in this paper example are invented. Its setup states that Copies accepts a positive whole number. The learner enters Name as Jules and Copies as 2.5. After submission, the example shows “Check Copies”, a coloured outline at Copies and an empty Name field. The message identifies a field but does not explain the supplied whole-number requirement. The empty Name state shows loss of that entered value within this example. Those are two separate recovery gaps. The record cannot diagnose why Name became empty or establish the cause of any real form problem.

Follow the recovery through the next submission

Observe whether the correction is accepted and what happens to information in other fields. If the flow removes entries or sends the person to a different step, record that consequence separately from the wording problem. A static error screenshot cannot show this sequence. Use a safe test form and never ask workshop participants to enter their personal records. Use the record to show the reviewer the particular gap: whether the person can understand the message, reach the relevant field, make the required change or continue without reconstructing unrelated entries. Ask which observation is missing before proposing a fix. “The name field became empty after rejection” describes a state; it does not identify the software cause. Confirm the real session’s permitted example, viewing and operation arrangements. A facilitator’s explanation may clarify the intended correction while leaving the interface’s preserved-input behaviour unexamined.

Distinguish an explanatory answer from a changed form

Continue the fictional exercise. A facilitator answers that the supplied Copies rule requires a positive whole number. Record that as an explanation of this toy rule. It does not add that explanation to the displayed error message or restore Jules to Name. The learner can now identify the intended input question while the interface-state gap remains. Ask the reviewer to keep the explanation, message wording and retained values in separate fields. Do not describe a helpful spoken answer as proof that the form itself supports recovery without assistance.

Trace the supplied revision without widening its result

A separate later fictional version displays “Copies must be a positive whole number” after the same 2.5 input and keeps Name as Jules. The supplied record then changes Copies to 3 and shows acceptance with Name still Jules. Under those stated toy conditions, the explanation is clearer, the unrelated Name value remains and that correction is accepted. This supplies a particular recovery sequence; it is not an executed test or a universal input rule. Retain both versions and the record’s supplied origin. Other fields, error types and actual user responses remain unexamined unless their observations are separately available.

Turn the observation into a testable change

Write the proposed correction in terms of behaviour: the person can locate the field, enter a valid value and continue with the intended information intact. Show the current and proposed paths at your selected session. Treat the dated SGDS reference as guidance and record the specific test performed; a clearer sentence alone does not establish that recovery now works. Save the original rejected state and the later permitted correction attempt with their conditions. State what was preserved and what the observed result establishes for that attempt. Do not turn one supplied accepted submission into evidence that every input, browser or user can recover. A critique can identify a bounded next task even when no operation is permitted in the room. Use Boardzip after naming that task, then confirm the actual current format, material rules and participant review arrangement. Keep any unexplained cause or untested path in the portfolio’s limitations.