The typical style guide is stored somewhere in a folder on the shelf, or it’s gathering dust in a file directory. The truth is that many style guides aren’t used at all. Why is that? Because often some important points were left out of the style guides. To avoid this happening to you, read this blog post to find out what you should never forget.
This may surprise you, but many style guides are created without it being clear in advance what the purpose of the style guide is: “Let's write down all of our grammatical rules” or “Let's pick out all the rules from the tekom guide that we need”. Those who do this create a set of rules. Such sets of rules are about as attractive as the house rules of an apartment building. It’s certainly not a good basis for successful implementation.
Instead, ask yourself what problem your style guide should solve. Should cooperation with those who offer technical input be improved? Do you want to unify the various approaches in your technical writing department? Are there stylistic errors in your manuals? Or should the style guide become a checklist for quality assurance? Depending on which goal you set, this will have an impact on the content, design, and media implementation of your style guide.
While you’re determining the goals, you should consider once again who your style guide is aimed at. After all, this also influences the contents of your style guide and how you will present this. For example: Does your target group have a good level of grammatical knowledge? Can they really recognize a “modal verb”? Even people who have completed a university degree often find this difficult.
You’ll have to design your linguistic rules differently depending on the target group. What may be quite self-evident in your technical writing department may be beyond colleagues working in development. In this case, perhaps you’ll have to work with rules of thumb or else add a little technical explanation to your style guide so that the content is understood. You also shouldn't underestimate the emotional aspects of a style guide. Those who are not copywriting professionals may sometimes consider it a personal attack if rules are imposed on their writing style, so it’s also important to approach the target group with sensitivity.
When a style guide is created, it’s usually clear who the team is that made it. But it often isn’t clear who takes care of the style guide once it’s released. This, however, is extremely important, as a guide is a living thing; it has to address new topics, modify existing ones, and take on board its readers’ feedback. That’s why every guide needs a responsible person with enough time to maintain it. It’s also important that it’s clear in the guide who maintains it and, when this person changes, this should be noted in the guide.
Linguistic rules are often abstract and difficult to understand for a layperson, so every guide should contain meaningful examples. These should make it clear in each specific case where the problem lies with certain formulations and why the alternative is better. Examples should always come from the everyday work of your writing department, ideally from your company. Incidentally, if you really don’t want to think of an example for one of the rules, or if you can't find one in your manuals, then the rule probably isn't very relevant.
One last important point so that your style guide is not just a set of rules: in a style guide, information belongs to the writing process. How much time is there for technical QA? What are the conventions for naming files? How should a correction be made? In which formats should the raw text be delivered? There is lots of information beyond pure style specifications that your users need, as only a complete style guide is a useful style guide.