Brief the relationship, rather than prescribing another screen

A useful brief states what someone needs to establish and why the current product leaves doubt. For a bilingual document workflow, that might be the relationship between a replacement file and an earlier review.

Describe the starting and receiving views

Use a fictional request. Identify what the customer sees, what staff receive and what the next colleague needs. Include editions, language and permission where they affect meaning. State the expected outcome as a task someone can demonstrate.

Identify the owners

Who approves service facts and business authority? Who reviews Arabic? Who owns source, hosting and provider accounts? List the relevant advisers without treating development as their approval. Note unresolved access or data-handling decisions.

Define the first useful phase

Separate investigation from implementation. Choose a normal acceptance case and an important exception, such as replacing material during review. Include operator instructions, migration and recovery if the phase changes a live dependency.

Explain the event driving the requested timing and the consequences of missing it. A desired date is not yet a commitment. Leave room for findings that justify a smaller repair or different sequence.

Keep private records and credentials out of the brief. Read the engagement sequence or send the question with a public link and an anonymised description.