Crafting a style guide

I was the second technical writer hired for my organization, which was already in its hypergrowth phase. Soon after I joined, many writers were hired for the team — most came from a marketing or writing background but not technical writing. One of the main challenges of a new team was maintaining consistency. Our style guide was an information dump of related and unrelated things, so we spent a lot of time and energy trying to keep things consistent and agree on the same guidelines. There are many ways in which you can do the same thing, but all writers of a team should agree on the same set of guidelines. This is where a style guide comes in handy. For instance, to capitalize or not capitalize can be a bone of contention for many. And yet, for others, to use a gerund or not in a title. Simply pick one and use it consistently. Consistency helps with the reader's comprehension, and most importantly, it is easier to review others' work and maintain your documentation set.

That's when I realized we could solve most of our pain points and friction in the team by reviving and revamping our style guide.

How I approached the task ahead?

As I said earlier, our existing style guide was a mishmash of many things. To revamp it, I needed to go back to the basics.

These are the things I did to get some of the basics right:

Determine the goal

Define the goal of your style guide.
You can also do that by asking the following simple questions:

• What is its main goal?
• What are the problems it should solve?

Identify audience

Identity who this style guide is for and the end-consumers of the content written based on this style guide.

Check public style guide resources

Go through other style guides to understand the structure and what is already out there.

These are some of the good resources that helped me base my structure:

• WritetheDocs style guide article
• Google developer documentation style guide
• Microsoft writing style guide

Pick a good reference style guide

There are many good style guides. You do not have to reinvent the wheel. Base it on a good publicly available style guide and define things which are very specific for your organization or team.
For example, title capitalization is a rule that we have been consistently following. Just because I based the style guide on Google or Microsoft style guide, I didn't think it was necessary to go through 1000+ articles and update them all. That was not the goal.
Also, look at your audience and try to see for which audience the style is written for. For example, if your main audience is developers, the Google developer style guide is better than Microsoft's writing style. But if your main audience is less technical business users, Microsoft is a better option.

Create a good skeleton

Partly why the previous style guide was unusable was because we went on recording random decisions and guidelines. But nobody knew how to find something they were looking for. Make enough headings, and the structure should be easy to navigate through.
Here is the structure I created.

Define your writing style

Your style guide should outline the voice and tone of your organization, and your content should reflect them.
Tip: Formulate the voice and tone of your organization if it is not already done.

Include content formatting guidelines

Your style guide should also include guidelines for formatting. This includes font size and style, margins, and spacing.

Provide examples

Provide examples with Dos and Don'ts to make the difference clear for your users.

Review and update regularly

Your style guide should be an ever-evolving one. Review and update regularly to ensure that it remains relevant.

If you think about it, a style guide is nothing but documentation of writing style decisions so that you can refer to it when needed. Whether you are a lone writer or a part of a team, investing time in developing a style guide is what can help you maintain quality and scale your documentation.