Turn an Approved Treatment Brief Into a Fillable PDF

The brief is already approved. That's the part people skip past, and it's the part that decides everything else. Your job is not to improve the questions, tighten the wording or decide what a vague line probably meant. Your job is to build a container that holds those questions and returns answers that still say what the person meant. Four controls, four names, one return trip — and the container either preserves the brief or quietly changes it.

The short answer: keep the approved wording as the source of truth, choose each control by how the answer behaves rather than how tidy it looks, give unrelated questions unrelated field identities, and test the whole handoff — fill, save, close, reopen, print — in the viewer your recipients actually use. A form that looks finished in the editor preview has proved nothing about the answer that comes back.

Freeze the question set first

Before you place a single field, write the approved text out in one place and treat it as frozen. Note which responses are optional. Note how the brief wants unknown or undecided answers recorded — sometimes that's an explicit "not yet decided" option, sometimes it's simply leaving the field blank, and those are different instructions.

Then resist three temptations. Don't add a question because the form would be more complete with it. Don't reword a question because it would fit a label better. Don't resolve an ambiguity by choosing the reading you prefer. If the approved brief contains something unresolved — a question nobody has settled, a choice list that's still provisional — mark it for the person who owns it. A form that silently answers an open question is worse than a form with a gap, because the gap is visible.

Defaults deserve their own warning here. Adobe's Acrobat field-properties documentation, which I checked in the desktop help pages on 18 September 2026, describes default values as a settable property on form fields. That's a technical fact with an editorial consequence: a preselected default means the returned form can look answered before anybody answered it. On a treatment brief, an empty field that reads as empty is more useful than a pre-filled one that reads as a decision. Leave defaults empty unless the approved brief itself says otherwise.

Match the control to the behavior of the answer

Three behaviors cover nearly every brief question.

Pick exactly one. If the alternatives exclude each other — live action, illustration-led, archive-led — that's one single-choice group. Radio buttons are the usual control. A dropdown can also work when the list is long enough that radio buttons would swamp the page, and it's still a single-choice control as long as only one value can be recorded.

Pick any that apply. If several answers can be true at once — which sections the first draft should include — those are independent checkboxes. Each one stands alone. Selecting "Soundtrack" must not unselect "Casting note."

Write something. If the answer needs explaining, a text field is the only honest control. Short fixed answers — a name, a date, a running time — can sit in a single-line field. Anything with a sentence in it needs a multiline one.

The matching is not cosmetic. Build an exclusive question as checkboxes and the form will happily accept two contradictory answers, which means the returned brief contains a decision nobody made. Build a "check all that apply" question as a radio group and the second true answer becomes impossible to record — the form has just narrowed the brief. The control has to match the grammar of the question, not the tidiness of the layout.

Field identity is not decoration

Radio buttons that share a field name are one group. That's a mechanic, not a preference, and it's the single most consequential thing to understand before you start naming things.

So if your brief has two unrelated single-choice questions — one about the opening approach, one about who reads the first draft — and you name both radio groups something generic like Choice1 and Choice2 in the order the wizard offered them, or worse, name both Choice, you no longer have two questions. You have one group with six options in it. Choosing an answer to the second question clears the answer to the first. Nothing on the page announces this. The two questions still sit under their own headings, still look separate, still get filled in by someone who believes they answered both.

Visual separation does not establish functional independence. Adding a rule between the groups doesn't do it. Moving one to a lower part of the page doesn't do it. Neither does changing the on-page label, because the label and the field name are different objects; the grouping follows the name.

Name radios after the question, not after the widget. finish_approach and first_reader announce what they hold. Inside a group, each choice keeps its own distinguishing value so the returned file tells you which alternative was picked. Apply the same discipline to checkboxes: each independent option should be independently recoverable, and two options that share an identity can stop behaving like two options.

Make the writing space carry the real response

The long-answer question is where forms most often betray the brief, and it fails in three separate places that look like one.

First, capacity. Multiline text fields have length options, and a field can be configured so it stops accepting input. If the brief genuinely invites a paragraph, the limit should be generous enough that nobody composing a real answer hits it mid-sentence.

Second, visibility on screen. Adobe documents scrolling options for text fields, which is useful and also a small trap: a scrolling field can hold more text than it shows. The answer is in there. The person filling the form can scroll and read it. Everything looks correct.

Third, and this is the one people miss, the printed or exported result. A saved value and a readable printout are two different acceptance checks. Text that survives in the file can still print as whatever fits inside the box, with the remainder simply absent from the page. If your recipient reads the printed brief rather than opening the file, the overflow — often the most interesting part, the hesitation and the "still undecided" note at the end — never reaches them.

Give long-answer fields real height, and then test with a genuinely difficult answer. Not a polite two-line one. Write the answer a real collaborator would write: the director's takeaway in a few sentences, then two open points, then a caveat. Then check what the page actually shows.

Labels get the same treatment. Test with the approved wording, not Q4. A label that's too long for its space gets truncated in a tab order or a printout, and a truncated question changes what was asked.

The return trip is the actual test

The editor preview confirms that fields exist. It does not confirm the handoff. The handoff has its own sequence, and every step in it is worth doing once, deliberately, before you send anything out.

Fill every control. Include the optional ones you'd normally skip, because blank fields are a behavior too. Tab through the form in order — does focus land on the next question, or jump somewhere that makes the reading order confusing? Save the file, close it, and reopen it. Do the values come back, including the long answer and both radio groups? Then print or export through the exact route you're going to ask people to use, and read the result the way a recipient would.

If your collaborators don't all open PDFs the same way, test in a second viewer. Desktop readers, browser viewers and phone viewers are not interchangeable, and a form that fills correctly in one can behave differently in another. Record which application and version you tested, and the date. That note is what lets the next person reproduce your check instead of guessing.

One boundary worth stating plainly: running this sequence demonstrates that the form preserves these answers under these conditions. It does not certify accessibility, and it does not certify secure submission. Those are separate pieces of work with their own testing and their own expertise, and adding fields to a document doesn't produce either one.

A worked example: four questions, two deliberate failures

The following brief is fictional, and the wording is invented for the exercise. It's the shape of the thing, not a real studio's document.

1. Which finishing approach should the treatment lead with? (choose one) Live-action photography / Illustration-led / Archive-led

2. Who reads the first draft first? (choose one) The brand team / Their agency / Both together

3. Which sections should the first draft include? (choose all that apply) The insight / The world / Casting note / Soundtrack / Endline

4. What should a reader take away, and what is still undecided? (long answer)

Build this with questions 1 and 2 as radio groups, question 3 as independent checkboxes, and question 4 as a multiline text field about four lines tall with scrolling enabled and a generous limit. Set no defaults on 1, 2 or 4.

Failure one: shared identity. Name both radio groups Choice. On the page, questions 1 and 2 look like two questions with three options each. In the file they are one group of six. Fill in "Live-action photography" for question 1, then pick "Their agency" for question 2, and the first answer clears. The person filling it in may never notice, and the returned brief now looks like they declined to answer question 1. Renaming the groups to finish_approach and first_reader separates them, and the two questions become independently recoverable. This follows from how radio groups work — the documentation describes the name-based grouping — but confirmation is yours to produce: fill both, save, reopen, and look at both answers.

Failure two: invisible overflow. Type a real answer into question 4. Something like: the takeaway is the sense of a place that's already changing before the story arrives, and the two things still undecided are whether the second sequence is interior or exterior and whether the endline is fixed. That's a normal length for this question. On screen, the field scrolls and the whole thing is there. Print it. What reaches the page may be only the visible portion. So the acceptance test for question 4 is not "the text is saved in the field." It's "the answer survives to the page my collaborator reads."

And the defaults. With nothing preselected, an empty question 1 tells you the approach is genuinely undecided. With a default, it tells you what the form builder set, which is not information about the treatment at all.

When the form is the wrong container

Some answers don't fit in a field, and pretending otherwise damages them. A response that should run to a page. A collaborator whose viewer mangles form fields, or whose environment won't reliably save them. A question that really needs an attachment behind it.

For those, provide a plain-text route and say so on the form itself — not buried in the email that carried it. Sending the approved questions as ordinary text alongside the fillable version costs you almost nothing and means the brief survives even when the form doesn't. The form is a convenience for returning answers, not the only record of what was asked.

What you should have at the end

Three artifacts, kept separately: the approved questions, unchanged, saved as text; a blank form you have filled and cleared yourself, with every control exercised; and one deliberately difficult filled test — the long answer, the two-radio coupling you fixed, the print output you actually read.

Then judge failures for what they are. An answer that disappears, a choice that clears an unrelated choice, a paragraph that prints as three lines — none of those are layout preferences. Each one alters what the returned brief means, and the person who filled it in had no way to know. Treat them as defects in the construction, and the form stays what it was supposed to be: a container that keeps the brief's questions intact and gets real answers back.

Frequently asked questions

What should be frozen before building a fillable PDF from an approved treatment brief?

Freeze the approved question set and treat its wording as the source of truth. Note which responses are optional and how the brief wants unknown or undecided answers recorded—blank and an explicit 'not yet decided' option are different instructions. Do not add questions, reword for layout, or resolve an ambiguity by choosing a reading. Mark unresolved items for the person who owns them. Leave defaults empty unless the approved brief says otherwise, because a preselected default can make a returned form look answered before anyone answered it.

How do I match controls to brief questions?

Match the control to how the answer behaves. If alternatives exclude one another, use one single-choice group, usually radio buttons or a dropdown when the list is long. If several answers can be true at once, use independent checkboxes. If the answer needs explaining, use a text field—single-line for short fixed answers like a name or date, multiline for anything with a sentence. Building an exclusive question as checkboxes can record contradictory answers; building a check-all question as radios can make a true second answer impossible to record.

Why is naming radio groups carefully important?

Radio buttons that share a field name are one group. Two unrelated single-choice questions named generically—such as both called Choice, or Choice1 and Choice2 in wizard order—can become one group, so choosing an answer to the second clears the first. Visual separation, a rule between groups, or a different on-page label does not establish functional independence; grouping follows the field name, not the label. Name radios after the question, such as finish_approach and first_reader, so each is independently recoverable.

How should long-answer fields and labels be tested?

Test capacity, screen visibility, and the printed or exported result. A multiline field can be configured to stop accepting input, and a scrolling field can hold more text than it shows. A saved value and a readable printout are different acceptance checks; text that survives in the file can still print as only what fits in the box. Give long-answer fields real height, test with a genuinely difficult answer a collaborator would write, and check what the page shows. Test labels with the approved wording, not Q4.

What does the return-trip test include, and what does it not certify?

Fill every control including optional ones, tab through in order, save, close, reopen, and print or export through the exact route recipients will use. Test in a second viewer if collaborators open PDFs differently, and record the application, version, and date. That sequence demonstrates that the form preserves these answers under these conditions. It does not certify accessibility or secure submission; those are separate work. For answers that do not fit a field—or when a viewer mangles fields—provide a plain-text route and say so on the form itself.