The Volokh Conspiracy

Mostly law professors | Sometimes contrarian | Often libertarian | Always independent

Word Processing for Lawyers


I never thought that teaching my law students basic word processing principles would be part of my professorial duties; but since I started my First Amendment Amicus Brief Clinic, I realized that, if I didn't teach them this, it would ultimately mean more work and hassle for me. So I've put together a talk on the subject, which I'm giving again this year.

Here is the rough outline of my recommendations, geared towards Microsoft Word users; do you have others you can suggest? Also, do you have suggestions of especially good training videos that help show some of the trickier features, such as the Table of Authorities feature?

[* * *]

Legal Writing—Basic Word Processing Principles

In legal writing, neatness counts. Material that looks sloppy or inconsistent reflects badly on you. If you don't know how to optimally format your writing, that will mean more work, headache, or embarrassment for you. It will also mean more work, headache, or embarrassment for the partners, judges, or professors for whom you work; and pain rolls downhill.

When you're in practice, much of the work might be done by paralegals or secretaries. But you might end up working in a government job, or in a small firm, where such help isn't easily available. Or you may be on an urgent project, with no time to ask someone for help. That's why it's good to know how to do things yourself.

Before we get to the details, it helps to understand three basic principles of effective document design:

  1. Unconscious consistency: The document should be configured so any additions or changes are consistent with the other material in document, without any further conscious effort. That's why we define the proper Styles for normal text, for block quotes, for headings, for tables, and the like, and then just have all the text appear in that style. For instance,
  • Good: Define the normal paragraph style to have the first line of each paragraph indented 0.25″. Bad: Manually add a tab at the start of each paragraph.
  • Good: Define the heading style to be single-spaced, with a 1-line space afterwards. Bad: Manually set each heading to single-spacing, and then add blank lines after each heading.
  • Good: Define the block quote style to be single-spaced and indented 0.25″ on the left and on the right, with a 1-line space afterwards. Bad: Manually change the indentation for each quote, set the style to single spacing, and then add blank lines.
  1. Robustness: When you make a change in one part of the document, this shouldn't make other parts look bad. For instance,

  • Good: Use a page break to go to a new page. Bad: Use multiple paragraph breaks, which means that the pagination will get broken if you add or delete text before those breaks.
  • Good: Configure your heading styles so they keep headings from getting split across pages, or appearing at the very bottom of a page. Bad: Use multiple paragraph breaks to move the heading to the next page.
  • Good: Use standard heading styles for headings, which lets you generate an automated Table of Contents. Bad: Hand-create a Table of Contents, which you'll then need to change every time a heading is changed, added, or deleted, or even every time added or deleted text causes a heading to move from one page to another.
  • Good: Use Table of Authorities tags, which lets you generate an automated Table of Authorities. Bad: Hand-create a Table of Authorities, which you'll then need to change whenever the pagination changes.
  • Good: Use bookmarks or Insert / Reference to insert page number cross-references (as in see supra __). Bad: Hand-enter the page number, which you'll then need to change whenever the pagination changes.
  • Good: Define the proper styles for Table of Contents or Table of Authorities entries, so that each entry has the right spacing and the right margins. Bad: Hand-fix the spacing and margins, which you'll then need to redo whenever the table is recreated.
  • Good: Use tables (with borders suppressed, as necessary) for two-column text (such as on the front page of a brief). Bad: Hand-format the text using tabs, which will require substantial changes whenever you need to add or delete a line in one column but not another. Also Bad: Using text boxes or multiple columns, which are harder to alter.

More broadly, if you're working with others on a brief, use the same word processor as the others (e.g., don't switch from Word to Google Docs). Switching word processors risks losing important formatting elements.

  1. Attention to detail: As with proofreading the text, including for subtle errors (such as two spaces between words instead of one), you should proofread the formatting. Formatting glitches can make the document look less professional and thus less authoritative. For instance,
  • Good: Make sure the page numbers in the footers are in the same font as the rest of the document.
  • Good: Make sure centered page numbers have no first-line indentation, so they really do appear in the center of the line.
  • Good: Watch for text that seems to be have a subtly different size, font, or spacing than other text around it.
  • Good: Watch for straight quotes when the rest of the document uses curly quotes.
  • Good: Watch for ragged-right-margin blocks within an otherwise even-right-margin brief (or vice versa).
  • Good: Watch for pinpoint page cites in the Table of Authorities.
  • Good: Watch for inconsistencies in the Table of Authorities and the Table of Contents (e.g., same-level headings having different capitalization styles, cases with the same terms being abbreviated differently, etc.).