Write a catalogue project brief around an approved source

A written brief should preserve the business problem long enough for people in different roles to assess it. It does not need to predict every screen. It should make clear what information the project relies on, what task should improve and who can decide whether the result is right.

Give the work a concrete starting point

Describe the current catalogue, application or manual process. Link a public example where possible. Name the approved product source and the person responsible for it. If several sources disagree, record that as an investigation item instead of presenting a guessed answer as a requirement.

For a fictional distributor, the starting point could be a catalogue family whose carton quantities are stored separately from its sales descriptions. The problem is that buyers cannot tell which unit an enquiry will use. That is more useful than requesting “a modern ecommerce platform”.

State the finished task

Explain what the customer or staff member should be able to do. For the distributor, the buyer identifies a variant, sees the approved sales unit and sends a request preserving both. The office can then review the request without reconstructing its meaning from a free-text message.

Name an exception: a quantity with no unit, an obsolete reference or a document awaiting review. Explain who decides the answer and what the system should show while that decision is outstanding.

List dependencies and boundaries

Identify current systems, required providers, available exports and language-review arrangements. State which material is approved and which is expected later. Do not send credentials or private records in the brief; access and handling are separate agreements.

Write down what the first delivery does not include when that boundary changes the user's expectation. An enquiry catalogue does not necessarily accept orders. A staff comparison does not approve purchases. A translated page does not establish Polish-speaking project support.

Make acceptance observable

Describe a normal example and a difficult one that a private preview should demonstrate. Identify the reviewers, their roles and the evidence they need. A product specialist approves facts; an office user verifies the receiving task; a language reviewer checks complete wording in context.

Include ownership after release: accounts, source files, ordinary updates and support responsibilities. Timing and price depend on these decisions as well as the visible pages.

The shorter quotation worksheet can prepare an initial outline. Use this fuller brief when the discussion needs source relationships and dependencies, then contact Faith Forge Labs to assess a suitable next step.