Forms in Word: How to Build a Fillable Form Step by Step

Choose the right control for each question

The control you pick decides how much cleanup the returned forms need. Match each question to the narrowest answer type that still lets people answer properly.

For a vacation request form, a date picker makes the leave dates far easier to enter consistently than an open text box.

A free-text field for a yes-or-no question creates review work and gives the respondent nothing useful. Use a check box and label it so the answer still makes sense when the form comes back.

Drop-downs and combo boxes need extra testing. Check whether people can use them with a keyboard and assistive technology, not just a mouse. For public forms I'd lean towards HTML when those interactions matter, because Word controls may not work equally well for every respondent or setup.

Word is useful when people need a document they can save, complete and return. It is less suited to collecting answers from a broad audience when accessibility, consistent data or easy reporting matter. Oregon's Word accessibility guidance is worth a read before you publish anything: it says only simple elements such as fillable text boxes and check boxes can be made accessible in Word, and points you elsewhere for drop-downs and similar controls.

How to build the form from a clean template

Build in desktop Word first. The menu path below uses Word for Windows, so don't assume the same commands sit in the same place on a Mac.

1. Expose the Developer tab. Go to File > Options > Customize Ribbon, tick Developer and select OK. That gives you the Controls group.
2. Save the starting document as a Word Template (.dotx). Keep this master unprotected and create separate copies for distribution, so a returned form never becomes your next starting template.
3. Write every label and section heading in reading order. Include any instruction respondents need once they start typing, such as what to put in a project description.
4. Build a table with labels in the left column and answer controls in the right. Set sensible column widths, but let answer rows grow rather than clipping longer responses.
5. Click inside each answer cell and insert the right control from Developer > Controls. Use your question list to check you haven't missed a response location.
6. Use Design Mode to edit placeholder text, and select each control's Properties to configure it. Switch Design Mode off before testing, otherwise you're checking the authoring experience rather than the respondent's.
7. Delete the typed underscores and bracketed blanks from drafting. They aren't structured fields, even though someone can type over them.
8. Save a test copy, enter sample answers, close it and reopen it. Confirm both the answers and the control settings survive, then keep the master clear of test responses.

Set the properties that make answers usable

Inserting a control is only half the job. Its properties decide whether the returned answer is understandable and whether anyone can extract it later without guessing.

Select a control and open Properties on the Developer tab. Use Design Mode when editing the placeholder wording, then turn it off to see what respondents see.

• Title: Give the control a readable name, such as Client name.
• Tag: Use a consistent identifier such as client_name or start_date. That gives any extraction or automation something meaningful to work with.
• Placeholder text: Treat the grey prompt as an example, not the only home for an instruction. It disappears when someone enters an answer.
• Content control cannot be deleted: Use this when you want the control itself to stay in place.
• Contents cannot be edited: This stops changes to the answer inside the control. Leave it unticked wherever respondents need to type or pick from a drop-down or combo box.

How to lock the form without overpromising security

Lock the template to preserve its structure, not to protect the data. Editing restrictions are useful, but they aren't a confidentiality system.

Apply them only after the controls work:

1. Keep the master unprotected and make a distribution copy.
2. Open Developer > Restrict Editing.
3. Under Editing restrictions, tick Allow only this type of editing in the document, select No changes (Read only), then select each answer area and tick Everyone so readers can edit it.
4. Choose Yes, Start Enforcing Protection, then decide whether to set a password.
5. Check individual controls. For editable answers, leave Contents cannot be edited unticked, and use Content control cannot be deleted where you want to preserve the container.

That distinction matters. Locking a control's contents doesn't keep the question fixed while allowing an answer. It stops editing inside the control. Microsoft's own page on protecting a Word form walks through the same enforcement steps.

Test the form like a frustrated respondent

1. Use only the keyboard. Tab through the form and check that focus follows the reading order.
2. Try blank responses, short answers and the longest realistic answer in each field.
3. Paste from elsewhere. Copy text from a web page and another Word file into plain-text controls, then inspect the formatting.
4. Try an invalid date and look through every list for choices you didn't intend to offer.
5. Save, close and reopen. Confirm the answers remain.
6. Print or export a copy and check that completed answers appear rather than empty-looking boxes.
7. Test the recipient's environment. Open the file on a phone or in Word for the web if that's how people are likely to receive it.

You know what every question means because you wrote it. A respondent doesn't have that advantage, and a clean run on your own desktop doesn't show their route works.

Common failures and their fixes

Give the form to a colleague who hasn't seen it and watch without explaining. Where they hesitate is evidence, not an invitation to tell them what you meant.

Export and share without losing the form

A Word form can work on your computer and fail after export. Pick the delivery format first: a .docx to complete in a compatible Word environment, or a PDF whose interactive fields you've checked separately. Saving a Word file as PDF does not guarantee its controls become fillable PDF fields. Open the exported file and test each field before sharing.

Run Word's Accessibility Checker from File > Info > Check for Issues > Check Accessibility, or the equivalent in your version. It can flag problems such as low contrast. A clean result still doesn't confirm that someone can complete the form with a keyboard or screen reader.

Decide when Word should stop collecting responses

Word is sensible for internal forms sent to people you know, especially when you can handle returned answers by hand. Don't let that convenience turn into a submission system built from attachments.

Move to HTML or a dedicated form platform when the workflow needs any of these:

• Authenticated respondents: You need a controlled identity, not merely a typed name.
• Direct data capture: Answers must reach a database or CRM without copying.
• Approval history: You need a dependable record of decisions and changes.
• Public accessibility: Completion has to work beyond a tested internal setup.
• Sensitive-data governance: The collection process needs controls beyond document editing restrictions.

Once you're copying answers from returned files into a spreadsheet, Word is acting as file transfer rather than a collection system.

And if what you're really sending is a proposal that needs explaining, more questions may be the wrong fix. A short video walkthrough alongside the document helps when the difficulty is understanding the scope rather than entering information.

Build the master, run the test pass with a colleague, and choose the delivery route based on how they get on.