What to Include in a Learning-Content Development Brief

1. Start with the project context

Explain why the content is needed and who will use it. A short, specific explanation is more useful than a long background document.

• Learners, roles, departments and professional context.
• Sector, business environment and the reason for commissioning now.
• Existing client or programme requirements, problems with current materials, and whether this is a new programme, extension or redesign.

Example. Instead of “We need a Business English module”, try: “The client needs a short module for B1–B2 operations teams who regularly give updates, clarify delays and agree next steps across departments.”

2. Define the learning requirements

Describe what learners should be able to do by the end of the programme, module or session.

• CEFR or approximate language level, learning objectives and workplace outcomes.
• Priority skills or language areas and expected progression.
• Programme length, number and duration of sessions, and assessment requirements.

Example. Make “practise language for meetings” more specific: contribute clearly to a cross-functional meeting, clarify responsibilities and confirm next steps.

3. Explain the delivery environment

Delivery conditions affect the design from the start. Specify online, in-company, phone or blended delivery; trainer-led or self-study; group size, session length, frequency and platform. Include individual, pair or group work expectations and practical constraints trainers face.

Example. A 60-minute online session for six learners needs a different design from a four-hour workshop for twenty participants.

4. Share the inputs that already exist

Useful inputs include an existing syllabus or programme map, approved outcomes, current materials, terminology, workplace situations, brand guidance, learner or trainer feedback and assessment criteria. Explain which sources provide context and which should appear in the finished materials.

• Share only material you are authorised to use.
• Agree how confidential information, proprietary material and third-party licensing will be handled before development starts.

5. Specify the deliverables

Name the materials the project needs, rather than assuming that “a module” means the same thing to everyone.

• Learner deck, trainer guide or facilitator notes, and participant materials.
• Scenarios or role cards, reading and listening materials, and language support.
• Answer keys, assessments or rubrics, and course or module overviews.

Example. Ask what the trainer needs to deliver confidently and what the learner needs to participate.

6. Add the production requirements

Agree branding and templates, final file formats, editable or source files, LMS or platform requirements, accessibility needs and multimedia specifications. Explain who will make future updates so the handover supports that work.

7. Agree the project rules

Set out how the work will move from an agreed brief to approval.

• Timing: delivery date, milestones, review points, any pilot and launch or teaching dates.
• Review: who reviews, who consolidates feedback, how many rounds are included and who approves the final work.
• Ownership and use: final materials, editable files, permitted reuse and third-party licence restrictions.
• Confidentiality: restricted information, anonymisation and approvals. Share only what development needs.

8. Define what “done” means

Before production starts, agree which files will be delivered, in which formats, which must be editable and who gives final approval. Specify what trainers need to deliver without further development, what participants receive and whether testing or piloting is needed before handover.