Separate the work from the current interface

People naturally explain a process through the software they have: open this screen, click this tab, copy this field, select this option. Capture the demonstration, then restate each action in terms of its purpose.

"Open the customer page" might become "confirm which account owns the request". "Export the weekly report" might become "identify accepted records that have not reached the accounting system". The restatement is useful because it survives a change in interface and exposes the information or decision the new design must support.

Do this carefully. Abstracting too far produces phrases such as "improve efficiency" or "manage customer data", which give a delivery team nothing to build. A useful statement names the actor, object and intended change. For example: "The coordinator assigns an unowned request to a service queue and records the reason for urgent priority."

Keep current constraints beside the restated work. If the existing product permits only one owner, note that as a software constraint rather than a business rule until it is confirmed. If staff process records in batches because an external service has a daily cutoff, that may remain a real constraint. Discovery should stop limitations from becoming requirements by accident, but it should not pretend the surrounding systems are infinitely flexible.

Maintain two views. The first shows what happens now, including duplication and awkward steps. The second records the proposed future flow once decisions have been made. If the current-state view is edited until it looks clean, the evidence that justified the replacement disappears. Later, nobody can tell whether a step was removed deliberately or simply missed.

Use the current interface as an evidence source rather than a template. Note field definitions, validation, permission checks, generated outputs and integration behaviour. Also note fields that nobody trusts, reports that are routinely corrected and labels that different teams interpret differently. A feature can exist in the old product and still be a poor requirement.

Before moving into design, ask the people involved to review the plain-language version. They should be able to recognise their work without needing the old screen names. Where they cannot, the restatement probably lost a condition or combined actions that need to stay separate.