Design the responsibility around the workflow

I ask users to explain what they believe has happened after they complete a task. A successful click sequence does not establish that they understand the result. In treasury software, a prepared request, an internally approved proposal and an instruction sent through a separate banking channel are different states. My team uses realistic scenarios and asks participants to describe the next action without prompting. We record uncertainty as well as completion. Findings are then discussed with implementation and commercial colleagues, because terminology that works in a research session must also survive a demonstration and a support conversation. I do not treat a small usability sample as a population estimate. Its value is in exposing a misunderstanding clearly enough that we can change the proposition and test it again before asking clients to rely on it.

A workflow can display an approval accurately and still mislead if the proposal has changed since the approval was given. I work with client process owners to define which changes require renewed review and how the earlier version remains visible. Product design then has to make the relationship understandable without forcing a user to reconstruct an event history. That means showing the version under review, the material amendment and the status of the previous decision. The institution owns its policy and delegation; our software must support that policy faithfully rather than invent authority. I assess the resulting experience with approvers and preparers together. Their needs differ, and an efficient preparation flow is incomplete if it leaves the reviewer uncertain about what they are being asked to accept.

Commercial packaging is part of product design when it determines who can see a workflow. A named-seat model may look simple while encouraging a client to ration access to people whose review makes the process useful. I examine the roles that create, approve and read the work before recommending a charging unit. At Sarnovel we moved one proposed package towards an institution-and-workflow subscription with read-only reviewers included. That reduced the annualised value of four offers, so the decision required a clear account of cost and expected adoption rather than a claim that free access always pays for itself. Finance and commercial leaders remain responsible for their approvals. My contribution is to make visible how the price structure changes the way the product is likely to be used.

Some requests appear to extend an existing screen but would create a different responsibility for the supplier. A treasury planning tool can display a value supplied by an institution without being capable of producing and defending that valuation itself. I ask what methods, specialists, evidence and continuing maintenance the proposed feature would require. The answer may be that we should integrate a qualified external source, narrow the promise or decline the opportunity. I have turned down a substantial prospective contract where the requested valuation engine exceeded our product competence. The useful discipline is to describe the obligation before estimating the development work. A delivery schedule cannot resolve a capability gap, and a customer willing to pay does not by itself establish that we can support the product responsibly over its life.