Start with the business outcome
A request for a new button describes a solution, not a need. Identify the user, the task, the trigger and the exception. For example, preventing unauthorised discounts is clearer than reproducing a button from the old system.
Walk through the standard workflow
Review existing settings and process options with the business owner. Record the gap that remains after that discussion. A small process change can sometimes remove the need for custom development, but it must work for the people doing the job.
Include the maintenance cost
Custom code needs tests, documentation and ownership after launch. Evaluate dependencies, permissions, support effort and future version upgrades before approving the build. Agree how changes will be reviewed and released.
Make acceptance observable
Test concrete scenarios: an authorised user can approve the exception, another user cannot, the action is recorded and the standard transaction still works. Review those outcomes with the owner in staging.
Bring it to your next workshop
Choose one workflow, bring a representative data sample and involve the person who owns the business outcome.