Singapore product critiques: distinguish saving a draft from submitting a request

The problem

A Singapore product manager receives feedback that a form’s final action is confusing, but the team debates button wording without agreeing whether the action saves editable work or sends a request to another party.

Define the action before debating the word

Write what the control actually does in the service you are reviewing. Make six entries: starting state; information acted on; action activated; resulting state; recipient or process reached; and what the person can edit afterward. Use the actual behaviour or mark it unconfirmed. A team agreeing that a button looks like a final step does not establish whether it stores editable work, sends a request or starts another process. If that behaviour is undecided, record the product question before choosing polished wording. Establish the successful action’s meaning before checking a failed entry and correction. Inspect any dependency the environment cannot exercise as its own evidence gap.

Keep storage, submission and later processing separate

Two actions can both store information while giving it different status and recipients. Identify whether information remains with the person as editable work or has been sent under the service’s actual process. Then state what any later processing or approval would require. A displayed acknowledgement does not by itself prove that another party has reviewed or accepted the request. Do not infer editability, withdrawal or processing rights from a familiar label; read the service’s actual requirements. Keep this review scoped to the action you can establish. When the environment does not implement the relevant recipient or integration, mark that part untested rather than filling it from the success screen’s appearance.

Use a fictional pair of controls to expose the difference

These controls are invented and describe no real service. Control A stores an editable draft for its author and sends nothing to the fictional processing team. Control B stores the same entered values, sends a request to that team and makes the submitted version uneditable in the example. Both can truthfully show that information was stored, but only B establishes the example’s sent status. Neither establishes a review result. If both controls say “Done” and both confirmations merely say “Saved”, a reader may be unable to distinguish the intended outcomes. The useful critique concerns what each person would expect and do next, not a universal rule that every saving or submission control has these behaviours.

Use the dated label guidance within the actual flow

SGDS v2 content guidance favours clear language and action-specific labels over vague acknowledgements. It is a dated v2 reference, not a latest-version or compliance certification. Apply its narrow principle after defining your action: the button, surrounding explanation and result should convey the same established outcome. A label suggesting a request was sent conflicts with a confirmation that describes only an editable draft. Equally, clearer words cannot implement a recipient or permission that the product does not provide. Write a proposed label and confirmation beside the state model, and mark them as proposals until evaluated. The appropriate words depend on the actual action and context; this guide does not require every final control to say Submit.

• SGDS | Content ↗ · Source checked 8 October 2026

Ask for a prediction without supplying the intended answer

In a safe prototype or authorised test example, stop before activation and ask what the person expects to happen, who would receive the information and what they could change afterward. Avoid introducing the exercise as a test of whether they understand submission; that can reveal the expected answer. Then show the supported result and ask whether it matches the prediction. Record the person’s actual words and observed task, keeping the facilitator’s explanation separate. A peer can critique this exercise without representing every intended user. Use invented inputs and state which behaviours the prototype actually implements. Do not ask someone to submit a real request, payment or personal record merely to make the public demonstration more convincing.

Locate the misunderstanding instead of combining all feedback

Sort an observation under the specific uncertainty: sending; recipient; editability; or subsequent processing. In a fictional observation, a reader correctly predicts that values will be stored but expects the processing team to receive them after Control A. That is a sending or recipient expectation gap, not proof the person failed to understand every part of the form. Another reader may expect to edit after B; that is a different question. Record whether the expectation changed only after a facilitator explained it. An explanation-assisted result is different evidence from an unaided prediction. A static screen or one participant’s comment can locate an issue without establishing that a revised flow now works for the intended audience.

Bring the state and evidence to the critique

Prepare the before-and-after model, proposed words, observation you actually have and one decision the team needs to make. Ask whether the control, help text and confirmation establish the same action, and which next observation would distinguish a wording issue from unresolved behaviour. Use the existing filled-field-context guide if the person loses a field’s meaning after typing; that is not this successful final-action problem. Choose a product or content critique whose actual format permits the example, and keep the authorised material limited to the question. A statement that peers prefer a phrase is a wording preference, not evidence that users predict the recipient, editability or later state correctly. Keep those conclusions separate in a portfolio or product note.

Verify the changed expectation at the scope actually tested

Keep three entries: proposal; implemented or supported behaviour; and observation after the change. Repeat a suitable neutral prediction and result comparison for the actual question, rather than declaring the issue solved because the new button sounds clearer. Retain any recipient or processing condition still untested. The appropriate later user research and service checks depend on your real process; event attendance does not perform them. Use Boardzip’s free product and content-design search for candidate critiques, then confirm their participant format and preparation. Free search supplies no design review appointment, implementation, user comprehension result or service approval. A useful outcome names the successful action accurately and preserves what the evidence does and does not establish.