How to Write Your Own Processes from a Writer’s Perspective

If you look into the average job description of a process writer, whether under the title “Technical Writer” or otherwise, it all seems straightforward until you get to the “degree” section or the “experience” section. Most businesses require experience and qualifications which are not writing-heavy, I’ve noticed. They require a lot of other things–like project management, product management, or a business degree. But is this necessary? 

If you’re writing processes for a field that is fairly regulated, like healthcare, that is almost certainly going to be what you need. But in other fields, as long as you already have the people in the business with the knowledge, you just need someone who can take their knowledge, put it into order, ask clarifying questions, and make the flow logical for anyone who has to use the process. 

In short, you need someone who is a writer—not even one who is a tech junkie. 

What do you really need to write a process? 

For most businesses out there, you don’t need someone with any technical knowledge beyond what you would need to work on a computer. Seriously. Does a process writer need to be familiar with all the different types of code? Only if they’re writing a process on how to code or something which actually involves coding in a specific language. 

You need a better understanding of specific actions than you do the technology behind everything because you are writing for human beings, not computers, and ultimately you’re explaining to human beings how to use something.

Because what is writing ultimately for? The audience. And unless you are writing for a very experienced audience, then you don’t need to be experienced yourself. 

This means it’s almost better if you are new to the program or product yourself. Having the outsider perspective is something that will make the final written product better—because you could have been part of the target audience. 

In theory, anyone who has skill with writing can write a process. And writing instructions or work processes is possibly one of the easiest writing pieces to practice. 

The elements of a well-written process are simple and finite. 

A well-written process has some very specific but basic elements. 

• Engaging and understandable language
• Simple sentences 
• Easy to follow and use
• A specific end goal 
• A defined structure
• Should be intuitive

If your process doesn’t follow any of these guidelines, or cannot for industry reasons (ship repair is one example, healthcare another), then find ways of breaking down the information so that you can make the instructions as clear as possible. 

Goodness only knows, you won’t help anything with page-long paragraphs on top of everything else. 

You also need to make sure that your instructions are intuitive. What is the most natural way of doing the task you’re describing? If you keep your process to what most people will automatically think to do in the first place, then you have a better chance of success. 

It also makes the process easier to write. 

Writing engaging processes doesn’t always mean what you think. 

I’ve mentioned this before, but grouping pieces of like information together is enormously helpful and can help you see patterns of information. How you arrange your information is probably the most important factor in whether your writing is engaging. 

One thing I’ve noticed when I’m working on a business document is readability scores can be high as long as you are careful in where you break your paragraphs, and how you use other tools like subsection headings and bullet lists. If you include block after block of text in any document, you are automatically going to have a less engaging document. 

What does this mean for a process? Well, processes automatically have to be in chronological order, but that doesn’t mean you are out of the woods. You still have to include other details, like what certain things look like when you’ve completed the next step (which is very important when you’re cooking, by the way), what pop-ups should appear, etc. 

Some processes, government processes especially, have to include explanatory paragraphs in them for what to do if a step doesn’t work. Recipes will often have this, although they’re not always written out in neat little numbered points. 

Julia Child’s cookbooks and recipes are laid out this way, which is part of the reason why she’s still so popular. If you were to write down a recipe as she presents it on one of her cooking programs, you will end up with one step in the recipe having at least two more scenarios, depending on what happened in the previous step.

If you’re a neophyte cook, this is exactly what you want: you want a failsafe in case something goes wrong. So, when you are writing a process, be it a recipe or no, consider if you could have different scenarios during each step. And then make sure you adjust your formatting to reflect that. 

This means you may need more subheadings (going down into H3 or H4 territory, if you’re in HTML-speak), additional sub-points, or consider numbering your paragraphs or steps. 

Ambiguity is your enemy in process writing.

If the people who are supposed to use your process can’t understand it, then it’s a waste of time, energy, and money. On this same token, if you cannot write it clearly and concisely, then you need to hire a writer to do so for you. 

Some of the worst processes I’ve ever read also had some of the worst sentence structure outside of a painfully accurate translation of a medieval text. Summa Theologiae is not an easy read partly because of the sentence structure differences between English and Medieval Latin, but it’s still easier to read than some processes which are at work in today’s business world.

I know, because I’ve sat there and actually done a comparison. Thomas Aquinas is far easier to read.

And that’s the sad truth of it. We seem to go straight for passive voice, lots of prepositional phrases, and lots of vague words when we write processes and I don’t understand why. Correction, I do understand why, at least in part, but I don’t understand why we think ambiguity is the answer to it. 

Passive voice is sometimes called for, true. If you do not have a specific subject in mind, then passive voice is ideal for some sentences. But the more you use it, the less readable your writing becomes because it introduces more ambiguity. Ambiguity in a process, or any other kind of work instruction, isn’t what you want. 

As for the rest, we seem to always be in fear of being too specific because we’re afraid of people taking those specifics seriously and then using them against us. I can understand why this is a concern, but it shouldn’t have a place in your process unless you really are putting an element in there for legal reasons. 

Otherwise, leave the ambiguity behind. You will accomplish more. And the naysayers, well, they are naysayers. Even Mother Teresa had her critics, after all.

The more specific you are, the better your chance of success. 

Processes, policies, and work instructions all need to be specific—painfully specific. Anything less and you are setting up yourself and anyone using your processes for failure. Ever try to put together something with badly written instructions? Then you know exactly what I’m talking about. 

Anything you write needs to be specific, whether you are writing for employees or customers. 

Complete training isn’t always possible in some industries. Consider retail. If you have a new hire whose first day is one of the business shopping days of the year, then are you really going to have time to train them? Probably not. 

If you’re hiring, overworked, and already short-staffed, training may have to be partially self-administered. This too is why you need specificity. They should be able to sit down with a process, find what they need, and be able to complete the entire task from start to finish with minimal input from you or anyone else. 

The same goes for processes you write for customers, such as checkout instructions, assembly instructions, or sign-up instructions. If your customer cannot easily use your product or service or navigate your shopping experience, then you are already fighting a losing battle. And that is something you do not want. 

Give yourself time to test the process and always be open to revision. 

This is perhaps the most important aspect of process writing. You need time to test and revise. You may think you have everything covered, but I can almost guarantee there’s something you’ll have missed.

What if you’re writing a process and your audience uses the app version of a program instead of the online or the desktop? That can change everything. If you use Microsoft Outlook for instance, the app versions do not have the option to use color categories like the desktop and online versions do. 

Processes will have to change. You may hire a new employee who figures out a better way of doing things, the technology you use may go out of date, or you may have to move your online site. So, even if you’ve spent hours perfecting what you think is a fool-proof way of doing things, you need to be open to the idea there may be a better or simpler way out there. 

When those changes happen, however, make sure that you document what you changed specifically in your process so that you can backtrack if needed. Believe me, it happens more than we’d all like to admit. Also, it gives you a way of measuring your success on the administration side of your business. Did the business improve before or after you made the change? 

That’s a question you cannot answer unless you have the data to prove it. 

Be as detail-oriented as a detective. 

If you’re a Sherlock Holmes or Hercule Poirot fan, then this will be right up your street. Every process has dozens of tiny details which have to be considered, even if they don’t actually make it into the language of the process itself. 

Details such as the context in which the process will be used and by whom. Does the program appear differently from a Mac to a PC? Does it work better with Firefox as the browser or Chrome? If you write a process that includes using certain computer programs, also make sure that your instructions will align with the desktop version, the online version, and the app version. Each one may have slight differences. 

Just look at Microsoft Office. Some functions appear differently between all three versions. 

Another detail you need to consider is word definitions. You may think all the words in your process have fairly standard definitions, but it’s a good idea to include definitions of words that may have several meanings. This allows your audience to know what that word means in the context of your process. 

A lot of processes I ran into working in ship repair have definitions in them. For some industries, you need evidence that the word used in the process has a very specific meaning. Which, if you consider how global everyone is these days, is a pretty good idea regardless of the industry. 

You might as well just define what you mean right from the get-go. That way there’s little confusion. Unless someone doesn’t bother reading the definitions. But that’s not on you as the writer. Your job is to present the reader with the information they need. 

Your goal is the task at hand, and your writing should reflect that. 

The goal of a process is to accomplish one specific task. It’s not to solve the world’s problems or to impart some nebulous “company culture.” It’s to accomplish one specific task. Your “culture” or “brand” isn’t worth pittance if your instructions don’t work. 

Or your employees become too frustrated with the processes to either follow the instructions or get any work done. 

Again, don’t be ambiguous or circuitous in your language. Use short, declarative sentences. Use simple words you know your audience will understand. Break up larger passages with bullet points and give definitions of words that have a specific meaning in your process. 

What is your desired result for your process? Is it for your employees to use your cash register properly? Is it to simplify the accounts payable process or to more evenly distribute the workload in a particular department? 

This should be what you have in mind. A process is just like a flowchart. You must have a very specific goal. This goes beyond just keeping your audience in mind. Your audience could be very broad, depending on what the process is for. 

This means your process just needs to have the plain facts laid out. Whether your audience understands the facts themselves is not for you to know. That’s what customer service is for. Not the writer. I know that goes against the grain to say for something that’s a part of content writing, but there you have it. Processes tell you how to get from point A to point B in the clearest, most precise terms possible. 

If your writing is clear and precise, then the rest will follow.