04 · Design · After reject
It turned red and stayed on the shift lead's list. The worker does not know to fix it
The interaction designer sets state, to-do, and whose hands a document returns to after a failure, so a reject can be fixed without a phone call. Station-screen viewing distance and type size belong to UI. Task order is walked first on the prototype.
Prototype: Completion is rejected by the shift lead. The document turns red and sits in the shift lead's rejected list.
Worker: How do I know to change the qty? Wait for the shift lead to call.
Interaction: A reject must do three things at once: state returns to awaiting worker edit, it appears in the worker's to-do, the reason is the sentence the shift lead just wrote. Successful shop-floor reporting no longer pops a toast that must be dismissed.
The interaction designer owns state, not brand color
The prototype proves a person can walk the path. The interaction designer has to prove they can still come back after a miss, a refusal, no privilege, or a wait. Public interaction roles usually write journeys, information architecture, and feedback. On a document system the journey is not five steps on a brochure. It is one document's state machine: who can see each state, who can edit, where failure stops, and whether success should interrupt someone whose hands are both occupied.
The handoff to the UI designer is a state table, not a visual. Only dangerous irreversible actions get a second confirm, such as voiding a paid document. Frequent correct actions do not, such as reporting completion in a row. A confirm dialog is safety in an office and a miss plus delay on a station. Empty data, loading, no privilege, and a failed query do not share "no data for now". Share that sentence and people think there is no job ticket today, when the account has no privilege on this machine.
The to-do is interaction's core object
Many systems store state on the document and never put the next step into the person's list. After the shift lead rejects, the document turns red. Color is not a notice. Interaction requires every "waiting on someone" state to create a to-do. The to-do shows the reason in the original words. Opening it lands on the editable field, not a read-only detail that makes the person hunt for edit. A to-do is done when the state leaves this person, not when they tapped "got it" once.
He also sets return. From a to-do, jump to look up WIP, and return must land on that unfinished job ticket, not home. In enterprise software, lost context costs more than a wrong color, because the person will report a second job and the old ticket becomes junk data. Which cell a scan gun types into is not designed on this page. Compatibility proves that on the acceptance device.
How the reject conversation becomes testable behavior
After a job ticket is rejected by the shift lead, the old design only changed color. The worker's list sorted by created time. The rejected ticket sank. He found out when the phone rang. Interaction writes the behavior as three lines tests can use as cases: at the moment of reject, the document leaves the shift lead's to-do and appears as the first item in the original worker's to-do; the reason shows the sentence the shift lead typed, not an error code; until the worker resubmits completed qty, this job ticket cannot be marked completion-to-stock. A successful submit only changes the top status bar. No dialog. A dialog will be dismissed by a cuff. The person will not know whether they confirmed or cancelled.
When these three lines go to frontend, interaction joins one walkthrough, using reject, not the happy path. Pass means the worker can finish the fix with nobody speaking. If not, interaction has not delivered. The UI designer may later strengthen type size and color of the reason. They may not cancel the to-do and replace it with a red dot on the detail.
The interaction designer also owns the entries to the same document. To-do, message, and list must open the same state. One entry cannot be editable while another is read-only. A read-only entry makes people think they already changed it, when the change sat on another page. The phone call comes back. Collapsing entries to one is the part of this role in enterprise systems that is easiest to skip and most valuable.