01Decide what the application must change
Start with one workflow: who initiates it, what information they need, where approval happens and how the result reaches the next person. A useful discovery exercise follows a real task from beginning to end, including exceptions. Replacing a spreadsheet with a dashboard is worthwhile only when the new workflow is clearer or easier to maintain.
A customer portal might let a client check a request and supply missing documents. An internal dashboard might bring information from several systems together. These are examples of possible requirements, not a claim that every application needs accounts, payments or real-time updates.
02Specify roles, records and integrations
The scope should identify user roles, permissions, record ownership, exports and audit needs. Agree how accounts are invited, changed and removed. For connected systems, document the supported API, data direction, error handling and who owns the external account. A working demo is not enough if nobody can recover a failed synchronisation.
Privacy and security requirements belong in discovery. Use realistic test data, limit access and decide what information is necessary before collecting it. A separate operational system should not inherit unrestricted website-editor access by accident.
03Build and test a complete workflow
Wireframes and a prototype help check the journey before substantial development. Acceptance criteria should describe observable behaviour: for example, an authorised user can submit a request, the reviewer receives it, and the user can see the resulting status. Test denied access and incomplete or duplicate submissions as well as the successful path.
Break a larger application into useful releases. The first release should complete a bounded task; later features should follow evidence from use rather than a long wish list. Platforms and implementation details follow the requirements and available maintenance skills.
