How (and When) To Use ‘Please’ in Government Forms

How can you write government documents that are polite but also firm?

For example, should you use Please on application forms?

Yes? But how often? Is it possible that you can over-do the politeness so that it clutters the page and gets in the way of the applicant?

For example, you know when somehow is simply being too polite? Everything is ‘please’, ‘thank you’, and ‘no, you first’. While it’s hard to fault good manners, excessive good manners are irritating.

Here’s an example from a driving licence application form.

Please read accompanying guidance notes before completing this form. Please complete this form in block capitals using a black ballpoint pen. Please place an X in the appropriate boxes. Please do not photocopy this form as it may reduce its quality and result in your application being delayed or rejected.

Too much, isn’t it?

What do we notice about this?

50 words.

Every sentence starts with Please.

It’s difficult to read.

It’s hard to identify the single most important instruction. This should be first. Attention fades as we scan text.

The first line may be redundant.

Passive phrasing mutes a very important point. Don’t photocopy the document!

How can we improve it?

First, to help non-English speakers and person with learning issues, explain block capitals.

Complete this form in block capitals using a black ballpoint pen.

Some readers won’t understand this. Ballpoint might trick them as well.

Starting every sentence with Please clutters up the text. It adds little value and is a bit annoying. We know they mean well, but it’s too much. Once would be enough.

Here’s another way of writing it:

Please complete the following.

Before you start, read the guidance notes.

Use BLOCK CAPITALS with a black ballpoint pen.

Mark X in the appropriate box.

Do NOT photocopy this form. Poor quality forms may delay your request.

What’s different?

It reduces the word count from 50 to 41, an 18% gain.

The reader can see, at a glance, the key points.

It’s easier to identify what should and should NOT be done.

It reduces confusion. Confused readers call contact centers, which is expensive and creates more paperwork.

It’s more immediate. We use active instead of passive phrasing (being delayed or rejected).

Should you use ‘Please’ in government documents?

Everything has it’s place. It’s nice to be polite, respectful, and courteous.

The thing is not to over-do it. In the previous example, the repetition of please obscured the message.

It’s a bit like when people try to help in the kitchen but just get in your way. Their intentions are good but it makes harder for everyone else.

Write instructions that readers can understand at a glance. Put the most important thing first. Warn them of possible mistakes to avoid. Put yourself on their side.

Thousands of templates to jump start your project

Acceptance Test Plan

Contingency Plan

Software Development Templates

Acquisition Plan

Conversion Plan

Software Requirements Specification

Action Plan

Cost Benefit Analysis

Software Testing

API Documentation

Database Design

Standard Operating Procedures (SOP)

Audience Analysis

Datasheet

Statement of Work

Availability Plan

Deployment Plan

System Administration Guide

Bill of Materials

Design Document

System Boundary

Business Case

Disaster Recovery Plan

System Design Document

Business Continuity

Disposition Plan

System Specifications

Business Plan

Documentation Plan

Technical Writing Templates

Business Process

Employee Handbook

Test Plan

Business Requirements

Error Message Guide

Training Plan

Business Rules

Expression of Interest

Transition Plan

Capacity Plan

Fact Sheet

Troubleshooting Guide

Case Study

Feasibility Study

Use Case

Change Management Plan

Functional Requirements

User Guide

Communication Plan

Grant Proposal

Verification and Validation Plan

Concept of Operations

Implementation Plan

White Papers

Concept Proposal

Installation Plan

Work Instructions

Configuration Management Plan

Interface Control Document

Software Development Templates

Acceptance Test Plan

Maintenance Plan

Software Requirements Specification

Acquisition Plan

Market Research

Software Testing

Action Plan

Marketing Plan

Standard Operating Procedures (SOP)

API Documentation

Needs Statement

Statement of Work

Audience Analysis

Operations Guide

System Administration Guide

Availability Plan

Policy Manual

System Boundary

Bill of Materials

Project Plan

System Design Document

Business Case

Proposal Manager Templates

System Specifications

Business Continuity

Proposal Template

Technical Writing Templates

Business Plan

Quality Assurance Plan

Test Plan

Business Process

Release Notes

Training Plan

Business Requirements

Request for Proposal

Transition Plan

Business Rules

Risk Management Plan

Troubleshooting Guide

Capacity Plan

Scope of Work

Use Case

Case Study

Security Plan

User Guide

Change Management Plan

Service Level Agreement (SLA)

Verification and Validation Plan

Communication Plan

Setup Guide

White Papers

Concept of Operations

Social Media Policy

Work Instructions

Concept Proposal

Contingency Plan

 

Configuration Management Plan

Conversion Plan