We live in an increasingly complex world surrounded by a seemingly never-ending amount of information. I think the growth of UX can be partially attributed to this complexity. UX practitioners (or the various other related specializations such as interaction designers, information architects, content strategists, etc.) have a unique capacity for complicated problem solving. We’re able to frame complex problems, distill them down to simple parts, and organize, categorize, and communicate them—an attractive skill set in complex times.
But even with these skills, we can be guilty of creating complexity. Enter the need for plain language.
A Bit of Background
The plain language movement came about in the early 1990s when group of U.S. government employees began meeting to try to spread the use of plain language in government communications. It has since spread to other professions notably the legal and medical fields.
Why plain language
Content written in plain language can help users find what they need, understand what they find and use what they find to meet their needs.
Plain language can be a useful focus for copywriters tasked with improving the search engine optimization (SEO) and conversion rate for a series of product pages on a website. By writing in the language of their users, copywriters end up with better search relevancy for the keywords they’re targeting, thus making it easier for users to find the site in search engines. Likewise, the search feature within the site will provide more accurate results and people will be more likely to locate information they need. This value can be further enhanced by researching the plain language and keywords site visitors are most likely to use (Google’s Keyword tool is a helpful resource) and discovering words and phrases that are similar keywords and are commonly searched for.
Once the user has clicked through to a site, rather than making him expend a lot of effort to understand information, well-written, plain language copy can help him to quickly and easily scan and understand your offering or value proposition. Writing that’s broken up into short, concise blocks, and that uses bulleted lists and headings to break up and group related content and facts is much easier to read, and this, in turn, can improve site engagement and even conversion rates.
If the user is reading site copy in search of particular information, well-written and simply structured content will help him locate information quickly. For those doing online sales, this could be the difference between a customer who leaves and a customer who buys.
No one technique defines plain language; rather it is defined by the result of something being easy to read, understand, and use.
For me, plain language really is about simple, clear writing that communicates the information needed and not much more. It’s natural and easy to read (you don’t have interpret words so you tend to read faster), more friendly and approachable and it’s also easier to write.
Where Plain Language Can Be Used in UX User Experience Our Jobs
Plain language can improve communication between project teams and stakeholders. It helps ensure everyone has the same understanding of documentation and other deliverables, simplifies and demystifies your legal content, and improves how you talk about UX within your team.
I worked on a large intranet project a little over a year ago. At the start of the project, we held a workshop with some of the key stakeholders and walked them through examples of each of the various deliverables they would see during the project, and shared example material from past projects. The goal was to connect the deliverable to the context in which it would be used by our team and theirs.
For example, a wireframe would be used by our team to illustrate how the navigation worked, how various pages may be laid out, how interactive elements on the page like accordion menus and content switchers would work, and what kinds of content might appear in those areas. For their team, they could use the wireframe to understand how the site would be structured and how the larger information architecture would be represented and navigated. They could see how, like a blueprint, the wireframe helped guide the eventual design.
Plain language in describing project deliverables
- Explain and provide context as to what each deliverable is, how it is relevant to the stakeholders’ problem and how it can be interpreted.
- Use metaphors and analogies to help stakeholders form an accurate conceptual model. For example: “Wireframes are like a building blueprint.”
- Before you send a deliverable, run it past someone else. I like to use my administrative assistant or my father, who has no idea what it is I do). If they can’t understand it, rewrite it.
Plain language use in the deliverables themselves
- When creating deliverables, look for opportunities to communicate in simple, plain language. Not only is this good usability, but it also ensures that our documentation can be effectively reviewed, digested, shared, and, most importantly, understood. Consider adding a legend or appendix for terminology to help those who might not be familiar with the project or deliverables gain context. I like to include this at the start of a document.
- Think like a content strategist about how to make things as simple and clear as possible. Use the terminology of your audience and consider their roles and expertise and skills.
- Structure your documents with headings and shorter blocks of copy so information is easy to scan.
- If you have numerous concepts to show, structure your deliverables so that you progressively disclose information. Use chapters and sections to break information into smaller pieces. This will help people explore your deliverables while doing the least amount of work possible.
Plain language use in contracts and agreements
Freelancers and agencies should look for opportunities to make documents and agreements simple and easy to understand. In most cases this is simply about avoiding jargon or domain-specific language and terminology. I’m always reminded of this example from 37 Signals:
I remember the tail end of our time as a web design company. When we started we did 20 page proposals. I remember pulling all nighters getting a proposal ready. Pages and pages of stuff. What a waste of time.
Towards the end we were doing one page proposals. It didn’t seem to matter. We were going to get the job or we weren’t. Over six years I never saw a connection between length and detail of proposal and winning a job.
Same thing with contracts. Sometime we hire an outside contractor or specialist to give us a hand on a project. Our contractor agreement used to be 8 pages long. Lawyers wrote it. Our current contractor agreement is one page long. I wrote it then showed it to our lawyers. They said it was fine. Done.
I recommend starting by reviewing existing legal agreements with a lawyer or seeking out a lawyer with experience in the use of plain language. One option that has worked for me is to first write out what I’d like to say in plain language, and then work with my lawyer to come up with something that covers risk while still retaining the core of what I’ve written. In my experience, a few small edits by a lawyer are often all that is needed.
Plain Language Use in the UX Community
One of the biggest barriers to entry into the UX field can be our own use of complex language. Weighty descriptors (my current favorite being “content strategy”) can confuse newcomers and close the door to those trying to learn about and understand the UX field.
When I first began working as an IxDA mentor, I met many new and prospective information architects and designers who were looking for work. In our one-on-one conversations, I would ask them to describe some of the methods they used to complete their work, and sometimes even having them sketch out what they do. Often, I would find they knew about various techniques but called them by different names. In other cases, all they needed were some anchor points from which to begin their exploration of the topic.
By intentionally seeking opportunities to speak in plain language, we can find that many other people share our ideas, but just talk about them differently.
