The verb on the button is part of the promise

A product demonstration often ends at the moment a screen confirms success. The audience sees a clean sequence, a decisive action and a reassuring result. That is a useful way to explain software, but it can conceal an important question: what does the user believe has happened outside the screen? In treasury workflows, the difference between preparing a request and sending an instruction matters. If the product supplies only the first, a confident verb can accidentally promise the second. I have learnt to examine the user's interpretation as carefully as the sequence of clicks.

Ask what happened after the click

Our deposit-inventory product included a control labelled Renew. It prepared material for the client's separate banking process. It did not transmit an instruction to the institution holding the deposit. During moderated research, eleven of twenty-four participants said they believed the action had already reached the bank. They had followed the workflow correctly. The misunderstanding was not evidence that they had failed a training test; it was evidence that our product had made a stronger promise than the service could fulfil.

We could have added an explanation elsewhere and kept the attractive action. That would have preserved the demonstration, but it would also have asked users to reconcile contradictory signals. The most prominent instruction said one thing while supporting material qualified it. I preferred to change the action itself. Prepare renewal request described the result we actually produced. The subsequent screen showed the document and made the external submission step visible. We also removed a completion message whose tone suggested that the whole task was over.

The commercial objection was understandable. A qualified verb can make a product look less capable. Experienced users may also find an explicit boundary repetitive. Those costs deserve acknowledgement because they affect adoption and sales conversations. But the alternative was to benefit from an impression we could not substantiate. Product leadership sometimes requires making the proposition appear smaller so that it becomes accurate. That is a commercial choice as well as a design choice, and it should be discussed with the people responsible for both.

A later session with a different group of twenty-four participants found two who still believed the request had reached the bank. I kept that limitation in the report. The two groups were not a paired experiment, and a small usability exercise does not establish a universal misunderstanding rate. It did show that the original issue was less common in that later session and that some ambiguity remained. We examined the remaining responses and revised the explanation rather than treating an improved number as permission to stop listening.

The useful research question was open-ended: what has happened, and what would you do next? Asking whether a participant understood a warning would have made the desired answer too obvious. Watching a completed task would have missed the issue entirely. We needed the person's own account of the state they believed the workflow had reached. That account could then be compared with the service boundary and the client's actual operating process.

Give approval a version to belong to

The same discipline applies to approval. A badge can accurately report that someone approved something and still mislead about what they approved. In another workflow, a treasury proposal retained its Approved status after edits. The history showed the amendment, but the main view did not make the relationship between the old decision and the new proposal clear. A reader could reasonably assume that the displayed content was the content that had received approval.

We examined forty scripted amendment scenarios. Nine retained earlier approval after a change that client process owners considered material. That exercise did not establish a live financial loss. It exposed a defect in the meaning communicated by the product. Preparers wanted to avoid repeated review for minor corrections, while approvers wanted their decisions attached to identifiable proposals. Both positions were reasonable. The product needed a way to distinguish a harmless presentation correction from a change that could alter the decision.

The institution owned that policy. Our role was to support it in a way users could understand and reviewers could examine. Material amendments created a new version with an awaiting-approval status. The earlier approved version remained available, and the reviewer could see the relevant changes. This added work. We did not claim that every control could be introduced without friction, because fresh consideration was part of the intended behaviour. A faster route would have been less useful if it preserved an approval whose object was no longer clear.

Versioning is often discussed as a technical feature, but the product question comes first. What exactly is the decision about, and which changes should invalidate the assumption that the decision still applies? Engineering can implement the relationship, but it cannot choose the institution's delegation policy by inference. Product teams need to bring process owners, preparers and approvers into the discussion before a status is treated as a universal truth across clients.

Carry the distinction beyond the interface

A corrected screen can still be undermined by an old demonstration script. If a salesperson says the product renews a deposit while the interface says it prepares a request, the customer receives two different propositions. Implementation colleagues may then be left to explain the gap under time pressure. We therefore changed training and demonstration material alongside the workflow. The purpose was consistency in what we offered, not a larger set of disclaimers attached to an unchanged promise.

I also ask teams to examine the artefacts that leave the system. A downloaded document, notification or email may be read by someone who never saw the original screen. Does it describe a draft, an internal approval or a completed external action? Can the recipient tell which version it concerns? Product meaning must survive that handover. Otherwise the system may be clear to the operator while confusing the manager or colleague who relies on its output.

These questions change how I assess release readiness. I want evidence about interpretation at consequential boundaries, not only evidence that the software performs its functions. That does not mean testing every word with every possible user. It means identifying the points where a mistaken belief would change what someone does next, then examining those points with realistic scenarios. The findings should be available to the people approving the proposition, including commercial leaders who will carry it into the market.

For a board, the relevant question is broader than any particular label. How does management know that customers understand the service they are buying and the responsibilities they retain? A director should not become the copy editor of a product. But directors can ask whether research, contracts, demonstrations and support materials describe the same boundary, and whether evidence of misunderstanding can delay a release. That is a question about the integrity of the proposition.

I began my career reconciling commercial schedules with service milestones. A record marked complete could leave someone else still waiting for acceptance. The technology has changed, but the underlying lesson remains useful: a status has meaning only in relation to the work and authority it describes. I want our products to make that relationship visible. A precise verb may look less impressive in a demonstration, yet it gives the user a more dependable basis for the next decision.