Writing a programme design brief
Everyone has opinions about the agenda, and nobody has yet written down what the programme is meant to achieve.
The short answer
A programme design brief is a one- to two-page document that settles what the programme must do before anyone drafts a timetable: the audience, what they should leave knowing or able to do, the time and room constraints, the session mix and who approves each part.
It sits between the event project brief and the detailed agenda. Write it first, then use it to judge every session idea against the same criteria.
What the brief must decide
The brief records choices that shape every later page of the programme. It does not list sessions; it sets the rules for choosing them.
Keep it short enough that committee members read it before the first programming meeting.
Eight decisions to put in writing
| Decision | What to write | Example question |
|---|---|---|
| Audience | Who attends, their experience level and what they already know | Are we writing for beginners, mid-career members or senior decision-makers? |
| Outcomes | What attendees should know or be able to do afterwards | Which three things would make the day worthwhile? |
| Time window | Number of days, daily start and finish, and fixed commitments | Is there a fixed opening or closing that cannot move? |
| Room and format limits | Number of rooms, main room format, breakouts, hybrid or in person | Does the venue support the layouts we want? See rooms |
| Session mix | Plenary, panels, workshops, networking and breaks, in rough proportion | How much of the day is listening and how much is doing? |
| Breaks and practicalities | Meals, networking, and prayer or rest times to be confirmed with the audience | What do attendees expect, and who is consulted? |
| Speaker approach | How speakers are sourced and who approves | Is it an open call, invitation only or a mix? |
| Approval route | Who signs off the brief, the draft programme and changes | Who has the final say if the committee disagrees? |
From brief to timetable
- Circulate the brief to decision owners and ask for corrections by a stated date.
- Turn each outcome into session objectives using a session objective map.
- Allocate time to content using the content-to-time allocation.
- Test the draft with the programme duration checker, then build the run-of-show.
Typical gaps
- The programme is drafted before anyone agrees who the audience is.
- Outcomes are phrased as topics ("digital trends") instead of changes in what delegates can do.
- Time constraints are discovered after sessions have been promised to speakers.
- No one is named to approve changes after the programme is published.
- The brief does not say what is already fixed, such as a sponsor session or an existing keynote.
Worked example · Fictional example
A national association planning a two-day member conference
Fictional organisation and figures, written to show the level of detail that is useful.
A fictional professional association plans a two-day conference for about 300 members. Its programme committee argues over sessions for three meetings, until the secretariat writes a one-page brief. It names mid-career members as the audience, lists three outcomes and sets two rooms plus a main hall.
The brief also records that one keynote is already agreed with the president, that attendees need generous break times and that the programme chair signs off the draft. The committee then reviews each session idea against the outcomes and drops four that do not fit.
Use this yourself
Programme design brief template
Copy this into a document and fill in what you know. Write Not decided, with an owner and a date, for anything still open.
- Event name and dates (or window):
- Audience: who attends, experience level, roughly how many:
- Outcomes: three things attendees should know or be able to do afterwards:
- Time window: days, daily start and finish, fixed commitments:
- Rooms and formats available or being considered:
- Session mix: plenary, panel, workshop, networking, breaks (rough proportion):
- Breaks and practicalities to confirm with the audience (meals, prayer and rest times, networking):
- Fixed items already promised (keynote, sponsor session, award):
- Speaker approach and who approves speakers:
- Approval route for the brief, draft programme and later changes:
- Open questions, each with owner and decision date:
Handle it in-house, or bring in help?
Your team can usually handle this when
- The committee already agrees on audience and outcomes.
- A single person owns the programme and holds the pen.
- The format is familiar from earlier years.
Outside planning help earns its fee when
- Several committees or members want different things from the same programme.
- The format is new, hybrid or multi-day, and the timetable keeps changing.
- Finance or leadership needs a documented rationale before approving the programme.
Want the programme brief turned into a working plan?
An Event Blueprint can take your programme design brief and set out scope, timeline, responsibilities and supplier requirements in one planning pack, so your committee reviews against a single plan. Send what you have so far, even if parts say Not decided.
Questions organisers ask
How is a programme design brief different from the event project brief?
The project brief covers the whole event, including budget and suppliers. The programme design brief focuses on what the programme must do and the rules for choosing sessions. Write the project brief first, then this one.
How long should it be?
One to two pages. If it grows longer, it is probably becoming the agenda. Keep session lists and timings in separate documents.
Can the brief change after the programme is drafted?
Yes, but record each change with a date, reason and approver. Changes to audience or outcomes usually mean the draft needs review.
Who should write it?
The person who holds the programme, usually the secretariat head or programme chair, with input from the committee. Others review and approve.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.