Ask about the desired change

Invite the client to describe the current situation, the people affected and what they want to work differently. Ask about timing, dependencies and existing material. Avoid a form dominated by technical choices the client may not understand. A good brief leaves room for discovery and makes uncertainty visible. It should not imply that an early estimate or preference is already an agreed requirement.

Separate essentials from later detail

Identify which answers are required for an initial response and which can follow after a discussion. Give examples of the kind of information you need without steering the client toward a particular answer. Summarise the brief back to them before proposing a scope. This helps uncover misunderstandings while changes are still easy to make. The document should support dialogue rather than replace it.

Imagine this

Hypothetical example

A hypothetical client requests a new profile system but cannot specify every feature. The brief asks who will use it, what currently causes friction and what information must remain controlled. Those answers give the delivery team a stronger starting point than a checklist of unfamiliar tools.

Make it practical.

Use this checklist as you read. Checks are not stored.

Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.