NOTE 01Map the work people actually do
A process diagram is most useful when it follows a real request. Identify where information arrives, who checks it and where the next person learns that work is ready. Include informal spreadsheets and messages: these often reveal gaps between the documented process and daily reality. A short observation session can expose duplicated data entry that a new dashboard would otherwise leave untouched.
NOTE 02Treat access as a design decision
Shared accounts and undocumented ownership make systems harder to support. Give people the access they need, keep recovery routes under business control and review permissions when roles change. Never share passwords or API keys through a general enquiry form. A consultancy brief should state which systems may be inspected, what information can be exported and who approves changes to a live service.
NOTE 03Define what finished means
Acceptance criteria make a technical project reviewable. Instead of promising a fast website, agree which journeys must work, how content is updated and which accessibility and performance checks apply. Record browser assumptions and data migration responsibilities. A launch plan should include rollback, monitoring and handover. This concept offers planning information and does not claim security certification, guaranteed uptime or an existing support team.
