A working brief records the job-level decisions the studio and client need to keep current: what the work is for, which products are included, what the visual direction means, what files are required, who can make decisions, and how the final handoff should work.
The brief is not the first message from the client. It is not the client agreement, the reusable style guide, or the per-output shot list.
It is the reviewed record for this job.
Start with the right document
Five records can exist around the same product photo job.
The project request collects initial facts before the studio decides whether to create the job.
The client agreement controls scope, fees, rights, payment, acceptance, and other legal obligations.
The job brief records the current job-level goal, products, direction, review process, and delivery requirements.
The photography style guide records reusable account-level visual rules.
The shot list records one product, variant, and required view or asset per output row.
A useful brief points to the agreement, style guide, and shot list rather than copying all three into one long document.
What belongs in the brief
A brief should contain enough detail for a studio user and an authorized client reviewer to understand the current job without reconstructing it from email.
The fields below are a starting point. Remove fields the studio does not use. Add a field only when it changes a real decision.
1. Job identity
Record:
- Job title
- Client or brand
- Studio contact
- Current brief version
- Brief date
- Current status
Use a title that identifies the work.
Spring serum PDP refresh
is more useful than:
Photo project
The version matters when requirements change. A comment or confirmation should identify which version it covers.
2. Job goal and intended use
Record the purpose in plain language.
Examples:
Create the approved product-page image set for three new serum SKUs.
Update packaging images for six existing products after the label redesign.
Create a new hero and detail set for the current Shopify product template.
Avoid vague goals such as:
Make it premium.
The brief can record the intended channels and placements, but current channel requirements should come from the client or official source.
Do not turn a remembered platform rule into a studio default.
3. Products and variants
Record:
- Product name
- Client SKU or product identifier
- Relevant variant
- Included quantity or pack
- Known sample condition
- Product substitutions
- Missing items
Use the client's stable identifiers.
A SKU does not automatically require its own complete image set. The current job and shot list determine which products, variants, and views need files.
When several variants intentionally share an output, name the included identifiers.
Do not use:
- all colors
- standard products
- spring range
when the studio needs a specific list.
4. Decision makers
Record:
- Person who confirms the current scope
- Person who approves the final proof or set
- Person who receives final files
- Person who manages the destination upload
Those roles can belong to one person or several people.
The person who submitted the first request is not automatically the final decision maker.
The client agreement defines legal authority. The brief records the working decision path.
5. Reusable visual standard
Reference the current photography style guide when one exists.
Record only the job-specific direction and exceptions in the brief.
Examples:
- Use Account Style Guide version 3.
- For the gift set only, use the approved seasonal surface reference.
- No lifestyle treatment is required for the refill SKU.
Do not rewrite the full account guide into every job brief.
6. Job-specific visual direction
Record:
- Background or environment
- Lighting reference
- Composition or crop
- Product orientation
- Props or styling
- Must-show details
- Must-avoid details
- Approved references
State what each reference demonstrates.
- Reference A shows crop and product position.
- Reference B shows shadow softness.
- Reference C shows the approved label orientation.
A moodboard link without explanation can support several interpretations.
7. Required outputs
Keep the brief at the job level.
Record:
- Output groups
- Products covered by each group
- Current destination
- Required alternate crops or formats
- Priority products
- Known exceptions
Put one independently required view or asset on each shot-list row.
The brief can say:
- Every serum requires the approved front, back, and dropper-detail package.
- The bundle requires one additional group image.
The shot list then contains the separate rows.
8. Retouching and product-truth boundaries
Record the intended treatment.
Examples:
- Remove temporary dust and fingerprints.
- Keep permanent package texture.
- Do not alter label text.
- Do not change product color without an approved reference.
- Do not imply that an accessory is included when it is not.
A phrase such as:
Clean it up
does not define the intended result.
Retouching instructions should preserve an accurate representation of the approved product.
9. Technical and delivery requirements
Record:
- Required dimensions
- Aspect ratio
- File format
- Color profile when specified
- Transparency
- Compression or file-size rule
- Client-facing naming pattern
- Manifest requirement
- Delivery method
- Final handoff date
Use the current approved client or destination requirement.
Do not publish one universal JPG, PNG, white-background, sRGB, or aspect-ratio rule.
The source file, review proof, and final delivery file can use different names when the mapping remains reliable.
10. Review and approval process
Record:
- What the client reviews
- Where comments belong
- What action records a requested change
- What action records approval
- Feedback due date when agreed
- Current included revision boundary from the agreement
- Person who consolidates client feedback
A comment is not automatically a requested change.
A requested change is not automatically new scope.
The client agreement defines what is included and the legal effect of approval.
11. Open questions, assumptions, and accepted exceptions
Keep uncertainty visible.
Use separate labels:
- Open question
- Studio assumption awaiting confirmation
- Client decision needed
- Accepted exception
Do not hide an unknown value by writing a confident guess.
An accepted exception should identify:
- Affected product or file
- Requirement that changed
- Decision maker
- Date
- What will be delivered instead
Copyable product photography brief template
Use this as a starting point.
Remove fields that do not affect the job.
- JOB
- Job title:
- Client or brand:
- Studio contact:
- Current brief version:
- Brief date:
- Current status:
- GOAL AND USE
- Primary goal:
- Products or launch covered:
- Intended channels or placements:
- Final handoff date:
- Priority products:
- DECISION MAKERS
- Scope decision maker:
- Final proof decision maker:
- Destination upload owner:
- Final-file recipient:
- PRODUCTS
- Product or SKU source:
- Products included:
- Variants included:
- Known exclusions:
- Sample condition or substitutions:
- Open product questions:
- VISUAL DIRECTION
- Current style guide and version:
- Approved references:
- Background or environment:
- Lighting direction:
- Composition or crop:
- Product orientation:
- Props or styling:
- Must show:
- Must avoid:
- Job-specific exceptions:
- OUTPUTS
- Required output groups:
- Products covered by each group:
- Alternate crops or formats:
- Known output exceptions:
- Shot-list version or link:
- RETOUCHING AND PRODUCT TRUTH
- Approved cleanup:
- Color reference:
- Texture treatment:
- Label or package rules:
- Geometry rules:
- Composite or synthetic elements:
- Prohibited changes:
- TECHNICAL AND DELIVERY
- Dimensions:
- Aspect ratio:
- Format:
- Color profile:
- Transparency:
- Compression or size:
- Delivery filename pattern:
- Manifest:
- Delivery method:
- Final-file access rule:
- REVIEW AND APPROVAL
- Proof or set reviewed:
- Feedback location:
- Requested-change action:
- Approval action:
- Feedback due date:
- Feedback owner:
- Included change boundary:
- New-scope process:
- OPEN QUESTIONS AND EXCEPTIONS
- Open questions:
- Assumptions awaiting confirmation:
- Accepted exceptions:
- Decision record:
Illustrative example
A studio is preparing a job for three skincare SKUs.
The brief records:
- Goal: Create the approved product-page image set for three serum SKUs.
- Products: Bottle and box for each SKU. The refill pouch is outside this job.
- Style guide: Use the current client guide for white balance, crop, shadow, and label orientation.
- Outputs: Front, back, and dropper detail for each SKU. One group image for the collection.
- Retouching: Remove temporary dust and fingerprints. Keep label text, package geometry, and material texture accurate.
- Review: The ecommerce manager consolidates comments. The brand director records the final decision.
- Delivery: Client-approved dimensions and format. Final names follow the current SKU and view pattern.
The shot list contains separate rows for every required front, back, dropper-detail, and group output.
Review the brief before client confirmation
Ask:
- Can every included product be identified?
- Can every required output be traced to the shot list?
- Does each reference state what it demonstrates?
- Are open questions visible?
- Are the scope and final-file decision makers named?
- Does the technical requirement come from a current source?
- Does the retouching instruction preserve product truth?
- Is the current version visible?
- Are accepted exceptions recorded?
A brief is ready for confirmation when the studio can distinguish:
- current requirement;
- open question;
- assumption;
- accepted exception.
It does not need to predict every production decision.
For the full sequence this template fits into — from the original request through versioning later changes — see the complete guide to creating ecommerce product photography briefs.
What does not belong in the brief
Keep these in their own record:
- Contract language and electronic signature
- Detailed studio pricing calculations
- Every account-level style rule
- Several independently delivered views inside one shot-list row
- Internal margin or staff-only notes
- Raw client credentials
- Payment-card data
- Private access links
The brief can reference the client agreement and the current style guide.
It should not replace them.
How this fits in Lenso
Lenso can keep the request or studio-entered referral, working brief, SKU and shot rows, references, proof history, client comments, requested changes, approval, optional invoice, and final files attached to the same job.
Lenso does not provide a contract or electronic-signature system.
The studio reviews every request before it becomes a job.
Clients use project-specific access and do not consume paid studio seats.
Questions about product photography briefs
Should the client or studio write the brief?
Either can provide the first information. The studio should review and shape the working record because the studio is responsible for interpreting the current requirement.
Is the brief the same as the shot list?
No. The brief explains the job. The shot list explains the independently required product outputs.
Is the brief the same as the client agreement?
No. The agreement controls the legal and commercial terms. The brief records the current operational requirement.
How long should the brief be?
Long enough to record the decisions the job needs and short enough to review. There is no universal page count. A large catalog can need a short job brief and a much larger shot list.
Can the same brief be reused?
Use an earlier brief as a starting point. Review every reused value. Products, channels, decision makers, references, and outputs can change.