Question board — resolution confirmation design and QA handoff
Example: a fictional public question board with existing member identity. One selected answer per question. No rewards, anonymous questions or moderator confirmation on behalf of the author.
Purpose: distinguish receiving a reply from the question author confirming resolution. A first reply, silence or a comment lock never confirms resolution.
Presentation: no answers / answers received, awaiting confirmation / resolution confirmed by the question author. Comments allowed or locked is an independent dimension.
Actor: only the question author selects a currently visible answer to that question. Recheck access and question-answer ownership on the server. Moderators may clear confirmation with a reason or lock comments, but cannot confirm on behalf of the author.
Confirmation: the question must currently be unresolved. Question body revision, selected answer body revision and resolution-state revision must match the viewed values. Check them with visibility, access and membership in one atomic operation, then save the selected answer and confirmed revisions.
Changes: any body edit, hiding or deletion of the question or selected answer clears confirmation, including typo edits. Other answers and comments do not affect it. Restoring content or visibility never restores confirmation automatically.
Clear or replace: author withdrawal and moderator clearing both check the current selection and state revision. Keep the answer and any comment lock. To select a different answer, clear the old confirmation and then review the new answer.
Lock: a comment lock prevents new comments. Author confirmation and withdrawal remain available for visible content. A hidden question or answer is not a comment-lock state.
Concurrency: two different answers selected from the same initial state produce one winner. Show the current result to the losing request without overwriting. Racing confirmation and body editing must never leave an old confirmation attached to changed text.
Retries: the same member's same operation must not create another change, history event or notification. Return the original operation result separately from current state. A later body edit means an old successful request must not revive the resolved badge. Reapply current access to the returned view.
Interface: do not show success before server confirmation. Distinguish success, changed conditions and loss of access. Announce textual results to assistive technology without unnecessary focus changes. Link to the selected answer and offer withdrawal.
Record: question-answer relationship, confirmed revisions, before/after state, actor, time, clearing reason, duplicate-request handling and notification outcome. Do not leak hidden text in errors or notifications. Check retention against the existing policy.
Handoff: planning owns alternatives, permissions and invalidation; design owns states and feedback; engineering owns revisions, atomic changes and retries; QA owns starting states and request order; operations owns clearing reasons and notification failures.
QA: test first answer, inactivity, wrong actor, another question's answer, valid confirmation, edit/hide/delete/restore, unrelated comments, competing selections, edit race, lost-response retry, withdrawal with a retained lock and confirmation while locked. Record actual state and history.
Before reuse: redesign services with multiple resolvers or staff closure. These are a design contract and fixed interface examples, not completed integration tests of a live board.
Example sequence: no answers → first-answer display with one answer → second answer added before competing-selection QA. Additional QA: reject stale withdrawal/moderator clearing after a new choice; do not expose content after hiding/access loss before a retry; notification retries preserve state and do not create duplicate jobs. Compare all 15 acceptance rows with the article.