What will a visitor believe is finished after pressing a button? When writing the ERP experience, I checked the state a sentence promised before deciding how persuasive it sounded.
A demonstration with no delivery mechanism should not call its action “send.” This article follows the wording before and after an action, including its result, invalid input and contact path.
Write down the expectation before the click
The staff example on the homepage shows items, quantities and suppliers. Its button says “Prepare example request.” “Example” describes the material, while “prepare” describes where the action ends. The visitor is not sending a document to a real supplier or confirming an operational order. Even a short verb needs a clearly defined execution boundary.
I reviewed the wording together with the initial state, the permitted action and the resulting state. A request starts unprepared. Reviewing the quantity and supplier and pressing the button produces supplier-grouped request drafts. Order quantity and document count are different units: two item rows can share a supplier and produce one draft without losing any units. The result message needs to make that distinction understandable rather than presenting an unexplained success count.
Name the result and its unit
The owner view’s “prepared requests” label names a different state from orders awaiting preparation. The response explains how many supplier-grouped drafts were prepared and that the owner view reflects the same status. It also says that nothing is actually sent. I did not want one success colour to stand in for several different meanings of completion.
The monthly financial cards have their own explanation because preparing a staff request does not recalculate those figures. That sentence is part of the interface copy even though it is not the button label. It closes an interpretive gap created by placing different datasets on one screen. Explaining a boundary at the point of possible confusion serves a more specific purpose than adding a long general instruction page.
An error should leave a visible way forward
Automatically replacing invalid text with a normal value can make an error disappear before the person understands it. The detailed workflow accepts a quantity string representing an integer from 1 to 20. It blocks progression outside that contract and preserves the draft text. Keeping the text visible leaves the actual thing that needs correction in front of the user.
The new revision-bound module follows the same principle. Its message asks for an integer from 1 to 20 and explains that the draft was preserved. Preparation is disabled while the draft remains visible. I describe this as a new, independent synthetic implementation, rather than a copy of the existing experience. It isolates the relationship between wording and state so readers can inspect and reuse that decision.
Even “reset” needs a scope
Resetting the detailed workflow does not change the separate monthly financial example on the page. The resulting message explicitly names both parts: the workflow was reset, and the monthly figures are unchanged. Without that distinction, “start again” would make the visitor infer whether the entire page or just the current order had returned to its beginning.
Copying a synthetic state into page memory also differs from saving a record on a server. In the new shared module I call the action “Copy to page memory” and explain that it disappears on reload. A successful copy is not a durable business backup. Restoring it means reading the example copied earlier in this page session; it does not mean that company records have been recovered.
Opening an email is a different event from receiving one
The contact link on the detailed page prepares an email around the problem the visitor selected. Its wording says that an email will be written, with nearby text explaining that the visitor reviews and sends it in their email app. Preparing a draft and receiving a message belong to different stages. Being precise about that boundary makes the contact path easier to understand.
The measurement explanation follows the same rule. An email-draft click can indicate contact intent, but it cannot be labelled a received enquiry. I do not claim that this copy increased enquiries; there is no measured result supporting that statement. Interface text creates an expectation for the visitor, and an event name creates an interpretation for the operator. Both need to refer to the action that actually happened.
Reuse the state analysis before the sentence
For another screen, begin with the state before the click and the exact scope of execution. Name the resulting object and its unit. Then specify what remains when input is invalid, where the person can correct it and which action becomes available afterwards. Only then read the sentence for tone and fluency. Preparation, confirmation, transmission and receipt should not collapse into one vague completion message.
The Korean and English versions refer to the same states. A shorter translation must not turn preparation into dispatch or restoration into permanent storage. Both language demos of the shared module use the same model, and their event wiring was checked in code. This was not a new rendered-browser reading test or an assistive-technology announcement test. I recorded the narrower evidence so the next review can start from what is actually known.