Begin with the work, not the screen count
Describe one complete journey: the trigger, the person acting, the required information, the decision and the final record. Include the current workaround and why it is difficult. Ten disconnected screen names reveal less than a single real process from start to finish.
- Name the primary user and desired result.
- Explain the current process and its main failure points.
- Include approvals, exceptions and corrections.
Map access and dependencies
List roles, business locations and any separation between clients. Identify the source of each important record and the systems it must exchange data with. Distinguish an existing supported API from an integration that still needs access, documentation or commercial agreement.
- Define what each role may view and change.
- List source files and systems without sending live personal data unnecessarily.
- Identify the owner of integration access and migration decisions.
Make completion demonstrable
Choose a small set of acceptance examples that can be repeated before launch. A quote should describe scope, exclusions, dependencies and how changes are handled. Bring the brief to Narvyn’s scoping conversation so the proposed delivery fits the business rather than a generic package.
- Define the first usable release.
- Include expected volume and supported devices.
- Agree test cases, handover and support expectations.
Questions, answered
Do I need finished designs before asking for a quote?
No. Clear workflows, users and examples are often enough to begin discovery.
Should I send production customer data in a brief?
Usually an anonymised example is enough for initial scoping. Agree secure handling before sharing sensitive records.
Can the brief change after discovery?
Yes. Record changes and their effect on scope, cost and delivery rather than treating them as invisible additions.