When to use ‘You’ in business documents… and when not to

Proposal writing might be easier if English had the equivalent of ‘usted’ in Spanish. Many languages have a formal and informal way of addressing people that’s not available in English. Maybe in the past, in olde English, ye served this purpose. I’m not sure. If you know, drop me a line.

smart-casual

So, is there a way to write formal documents, show respect but avoid sounding too stiff?

While there is no direct replacement for usted, you’ve probably noticed that formal business documents now use the sometimes too chummy ‘you’ when talking to the reader. Personally, I think it’s fine in user documentation, for example, user guides, but tend to be careful in more formal business documents, such as proposals, grant applications or white papers.

Saying that, as someone who reviews business proposals, I see ‘you’ phrasing used more frequently. When used correctly it reads well and establishes a closer bond to, you, the reader. But you can get it wrong. And when it’s used incorrectly, it undermines the rest of the content. It appears that the writer is trying too hard for you to like them.

Let’s look at some ways to use ‘you’ in business documents without offending the reader, sounding too familiar, and hopefully hitting the right tone.

  • Consistency – if you’re writing as part of a team, make sure everyone is on the same wavelength. Discuss tone, phrasing, and voice before you and your colleagues starting writing. Share examples that have worked well so they have a reference point.
    This avoids a ‘patchwork’ document where the voice, tone, and phrasing change from chapter to chapter. Aim for consistency.
  • Frequency – if someone constantly uses your name in a conversation, it can seem contrived or forced after a while. Likewise in business communication be selective when adopting a more familiar tone with the reader. How?
  • Print it out and read it aloud. This will tell you if you’re overdoing it. Somehow you’ll hear it before you see it. Likewise, getting someone to read it for you – someone who is not afraid to give an honest opinion – is another way to determine if you’ve got it right.
    Another point to consider: see if you can rephrase sections and avoid using you altogether.
    Why?
    If you use the term selectively, it will have more impact when you do use it. Overuse dilutes the impact.
  • Location – what I mean here is where in the document should you use – and avoid – using this phrasing? For example, you may want use slightly more formal language in the Executive Summary, and then shift into more business casual English.
  • Make sure the transition is smooth. Don’t jump from cold, formal, stiff sentences to short, snappy buddy-buddy chatter.
  • Tone – the point of using you instead of us, our or we isn’t to trick the reader into a false sense of trust. They’ll see through that. Instead, it’s to cultivate a more open relationship, one that places them at the center – I’m writing to you – and not fixed on your abilities – we believe that we can etc..

Where possible, write in the active voice and use the second person (you, your, and yours), and reduce the first person (I, me, mine, we, us, and ours). This shifts the focus from what you offer to what they need.

Finally, it takes practice. When you read something that works, save the page, or use a tool like Evernote to clip it for reference.

Photo: peterphotographic

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