Start with the awkward part
Ask someone to show you the last time they completed the task. Not the official process: the actual sequence. Notice where they switch tabs, copy information, wait for an answer or keep a private spreadsheet. These moments are evidence of a mismatch between the tools and the work.
Name the decision, not just the screen
“We need a dashboard” describes an interface. “We need to decide which enquiries to call first” describes a job. The second statement makes it easier to choose the information, timing and controls that belong in the product. It also makes it easier to recognise when a dashboard is unnecessary.
Make a small map
Record what starts the task, who performs it, what information they need and what completion means. Include exceptions: missing details, changes of ownership and work that arrives outside normal hours. A process that only works on the happy path is not ready to be automated.
Test the change before expanding it
A prototype can show whether the next step is clear. A small pilot can show whether the data and integration behave as expected. Decide what you need to learn from each before building more. A narrow, useful first release is easier to improve than a large system built around an untested assumption.
A better first brief
Write the brief in one sentence: “Help this person complete this task, with this information, under these constraints.” Add the current difficulty and the evidence you will use to judge improvement. That is a stronger starting point than a long feature list.