How to brief a template designer for your annual report (and why the brief matters more than you think)
Most annual report template projects start with a PDF.
Someone sends through the approved design, explains the page count, mentions the deadline, and asks how long the build will take. That is a reasonable starting point. It is also missing about half of what a template designer actually needs to do the job properly.
The brief you give at the start of a template project shapes everything that follows: what gets built, how it holds up under real use, and whether the finished template actually solves the problem it was supposed to solve. A good brief is not a formality. It is the difference between a template that works and one that works until the eighth contributor opens it.
Here is what a thorough brief for an annual report template actually contains, and why each piece matters.
The document itself
Page count is the obvious starting point. But what matters more than total pages is how those pages are structured. How many distinct section types are there? How many contributors will be working in the document simultaneously? Are there sections that should be locked down because they contain sensitive or regulated content? Are there sections that need to be completely editable and flexible?
An annual report with 12 contributors working across 8 defined sections is a fundamentally different brief from one where a single communications manager is building the whole document. The former needs contributor-level permissions and section protection. The latter needs a clean, well-structured template that one person can work through efficiently.
The platforms and machines
Where will contributors be working? If the organisation runs Microsoft 365 in the cloud, the template behaviour is different from an on-premise Office installation. If some contributors are on Mac and others on PC, font rendering and spacing need to be tested across both. If the template needs to produce a print-ready PDF at the end of the process, the build needs to account for that from the start.
These are not questions that come up naturally in a PDF handover. They come up when the template goes into use and something does not behave as expected.
The compliance requirements
Does the document need to meet WCAG accessibility standards? Is it going to a public audience, a regulated body, or a government entity with specific requirements? Does the organisation have an existing accessibility policy that the template needs to align with?
Accessibility built into a template from the start takes a fraction of the time that retrofitting it takes later. It also produces a better outcome, because the accessibility is structural rather than applied as an afterthought.
The brand assets
Approved fonts, colour values, logo files in the correct format, and any brand guidelines that specify how those elements should be used in documents. This sounds obvious, and yet a significant number of template projects begin with a design file that uses a brand font not yet licensed for desktop use, or a colour palette specified in print values rather than screen values.
The pre-build design review catches these issues before the build begins. But the brief is where you flag them upfront so everyone is working from the same information.
What success looks like
This is the part of the brief that gets skipped most often and matters most.
What does a successful annual report template actually do for your organisation? Is it primarily about speed — the template should make document production significantly faster than the current process? Is it about consistency — every section should look identical regardless of who produced it? Is it about compliance — every document produced from it should meet WCAG 2.2 Level AA? Is it about resilience — the template should hold up when ten people are working in it simultaneously under deadline pressure?
The answer is usually some combination of all of these. But knowing which matters most to your organisation shapes the specific decisions that go into the build, and it gives you a clear measure for whether the finished template is doing its job.
The brief as a diagnostic
There is a useful side effect of writing a thorough brief: it often reveals that the problem you thought you were solving is not the only problem worth solving.
Organisations that come to us asking for a template rebuild sometimes discover through the briefing conversation that the real issue is a version control problem, or a contributor training problem, or a design file that was never intended to be used in Word. The brief surfaces these things before the build starts, which is a much better time to find them than after.
If you are planning an annual report template project and you would like to talk through what the brief should cover, book a time with Tim. We will work through it together before any build begins.