I’ve only recently come across the term ‘UX writing’; it may have been around for a while. My immediate internal skeptic said “This is just plain language writing dressed up in new clothes. UX is on trend – lots more dollars available for UX writing than plain language writing.”

I think my internal skeptic is partially correct. But I also think this new description puts a healthy and helpful focus on what is happening for the user. So I’m not against the term, nor totally cynical.

First, identifying a reader as a user is helpful, especially for functional documents. Functional documents aim to get people to think, feel or do something – web content, contracts, reports, advice, disclosures, fact sheets, policies, procedures, terms and conditions, letters. Most documents written by businesses and government agencies are functional documents.

Functional documents are information products that people need to use.

Second, acknowledging the user has an experience while reading is helpful. It acknowledges that functional documents are conversation; not mere blobs of text on paper or screen.

Third, UX methods involve the user. UX implies products are tested with real users before release. Testing has always been part of good plain language methods. Unfortunately it is often omitted.

Much plain language writing becomes unstuck at this point: testing. Often there is no real testing, just internal and legal review. When everybody says it’s OK, we publish and hope for the best. That’s arrogant, irresponsible and perhaps reckless. See Publishing a document without testing