Maybe you’ve heard of User Centered Design (UCD) before maybe you haven’t, but either way it’s an important tool for reaching a wider audience, an audience on a schedule, and/or an uneducated audience. Essentially UCD aims to make technical and complex articles easier for the user (or client) to understand, thus making communication much simpler and more efficient. More than anything using this type of writing style is meant to make technical jargon much easier to understand for the layperson. This is done through precise organization of the overall document, detailed indexes and glossaries, and simple sentence structures. Forget what your third grade teachers said about mixing up sentence complexities and structure, times have changed.
This article is not meant to instruct you on the intricacies of User Centered Design, you can read that for yourself on Purdue’s OWL writing resource, but instead grant ideas on how to implement this technique into your technical business writings (with a few examples). Design of any lengthy document must include page numbers, section headings, an index, and a glossary (if the writing uses words not known by the average reader). These elements make scanning through a document significantly easier. Think of presenting a business proposal to a board of directors. Each member will lightly skim the entire document, but choose to focus on separate sections. Clear headings, with a detailed index, make it easier for them to zoom in on their particular information. The COO will not be as interested in the financials as the CFO. Usability.gov also has instructions on UCD basics that are written slightly differently and in a different context if necessary.
“Does this extreme focus on readability dumb down the audience?” Potentially.John Wood wrote an article for Core77 stating “it (UCD) ignores everything outside our myopic economic reality.” Here he’s saying that a huge mistake that commons from User Centered Design is a lack of quality information. This is where precision details come into play. Simplifying a sentence’s structure by placing the subject at the beginning and the object at the end can lead to the tendency to omit certain details because it just doesn’t fit or flow well. This is where we have to assume the reader is capable of separating out descriptive phrases and finer detailed points from the overall sentence. If important details just don’t quite fit in the sentence, but you want to make it easier to read, break the single sentence into two. The quality of content cannot be sacrificed for the user’s ability to read the document. It’s a fine line of intersection of readability and detail that produces a concise successful paper. In this sense it’s important to have two separate people read the paper if possible. One on the technical side, looking for missed details, and one involved person, trying to understand what they’re reading.
Possibility of Use
It’s entirely reasonable to think at this point, “what a fantastic idea to meld both ideas, but I’m on a timetable and just wouldn’t have the time to fix a lengthy technical paper for the average person’s benefit.” That’s valid. Honestly, it is… at least at the beginning of a career. As an individual moves up in a division more and more people are involved on projects. Reports to managers, consolidating peers work, reviewing others work, and other situations arise where communicating one person’s complex ideas to a non-technical person is required. Start this process at the beginning, by always thinking through a paper with an audience in mind. “Who will possibly read this?” and “Will they understand it?” are important questions to constantly consider. As you produce more and more pieces this will become faster and easier. Being able to concisely present an idea to a room of different people is an extremely valuable skill to have, regardless of the industry. Web Accessibility Initiative also has an index of user submitted notes for further assessment if you feel so inclined.