Describe the work without the current screens

People naturally explain a process through the software in front of them: open this screen, click this tab, copy this field, pick this option. Capture the demo, then restate each action in terms of what it's for.

"Open the customer page" might become "confirm which account owns the request". "Export the weekly report" might become "find accepted records that haven't reached the accounting system yet". The restated version survives a change of interface, and it shows you the information or decision the new design has to support.

Be careful not to go too far, though. Abstract it enough and you end up with "improve efficiency" or "manage customer data", which gives a delivery team nothing to build. A useful statement names who's acting, on what, and what changes. Something like: "The coordinator assigns an unowned request to a service queue and records the reason for urgent priority."

Keep the current constraints next to the restated work. If the existing product only allows one owner, note that as a software limit and hold off calling it a business rule until someone confirms it. If staff process records in batches because an external service has a daily cutoff, that might stay a real constraint. You want discovery to stop old limitations sneaking in as requirements, but you can't pretend the systems around you are endlessly flexible either.

I'd keep two views. One shows what happens now, duplication and awkward steps included. The other records the proposed future flow once decisions are made. If you tidy the current-state view until it looks clean, you lose the evidence that justified the replacement in the first place, and later nobody can tell whether a step was dropped on purpose or just missed.

Treat the current interface as evidence rather than a template. Note field definitions, validation, permission checks, generated outputs and integration behaviour, plus the fields nobody trusts, the reports people routinely correct and the labels different teams read differently. Something can exist in the old product and still make a poor requirement.

Before you move into design, ask the people involved to read the plain-language version. They should recognise their own work without needing the old screen names. If they can't, the restatement has probably lost a condition or merged actions that need to stay separate.