by Chelsea Fulton

Consumers of technical content are hardly a captive audience. Typically, our readers need help setting up a product and troubleshooting errors. Rarely, if ever, do technical content consumers browse our websites and white papers for entertainment. Our consumers are purpose-driven. Therefore, technical content creators must be accurate, explicit, concise, and consistent.

• According to Demand Metric, consistently presented brands are 3 to 4 times more likely to experience brand visibility.
• A study by Marq determined that consistently presenting a brand can increase a company’s average revenue by 10-20%.
• BBC News found that one spelling mistake can cut online sales in half.​ 

The bottom line is that consistency and quality matter.

Consistency is one of the fundamental differences between technical writing and other writing styles. Effective technical communication is uniform. The margin of interpretation for technical content should be next to non-existent. So, how does a team of 15 technical writers tasked with creating and maintaining hundreds of documents write in a way that is indistinguishable to an untrained eye?

An internal style guide, that’s how.

According to the Society for Technical Communication’s (STC’s) Technical Communication Book of Knowledge (TCBOK):

Does your team currently use a style guide?

Maybe your team has a style guide, but many internal processes are not codified. Maybe your team faithfully uses the internal style guide, but other teams within your company do not. Or maybe you are currently a team of one, hope to onboard new writers soon, and want to stay ahead of the style guide game.

Getting started is often the most challenging part of any project, and creating a new style guide from scratch can be daunting. Use the processes below to get the ball rolling.

My team does not have a style guide. How do I create one?

Step 1: Review popular style guides and choose a base style to work from

To create a style guide for your team, review existing style guides and choose a default guide as a starting point. For example, on the Introduction page of my company style guide, we explicitly mention:

With some exceptions, our primary style format follows suggestions from the Microsoft Manual of Style for Technical Publications Fourth Edition (MMSTP). For clarification on any style issue not found in the Style Guide, please reference the MMSTP or the Merriam-Webster Dictionary.

Review the following list of the most popular style guides and determine which fits your team’s content best.

• Associated Press (AP) Stylebook
• Chicago Manual of Style
• Modern Language Association (MLA) Handbook
• The Elements of Style
• Microsoft Writing Style Guide
• Apple Style Guide
• Google developer documentation style guide
• American Psychological Association (APA) Style
• American Medical Association (AMA) Manual of Style

Step 2: Determine the best way to host your style guide

A good style guide is easily accessible and easy to use. To ensure style guide adherence, consider all of the following criteria.

• Where should you host your style guide?

Host your style guide in a space accessible to all current and future users. For example, I host my company style guide on the web. All users attempting to access the website from an internal network can access the website directly (via safe-listed IP addresses). All users attempting to access the website from an external network must enter a user name and password provided by a style guide administrator.

• Can you easily import/export data?

I recommend using a format in which you can easily import/export data. This has come in handy more times than I can count. 

• Is your style guide searchable?

A style guide is only as successful as its search capabilities. Build your style guide with straightforward searchability, and users will be more likely to use it.

• What if something changes?

Ensure you can change/add entries as new information is required. A good style guide ebbs and flows with industry trends and standards. Think about words like “Internet” or “e-mail”. Over time, the industry standard has changed¾we no longer capitalize “internet” and have dropped the hyphen in “email.” You’ll want a style guide that can easily accommodate such changes.

Step 3: Add company/team-specific guidelines

• Branding guidelines: Including all company logos, taglines, product and service names, color palettes, typography (for example, font name, font size, and font color), imagery, internal materials (for example, office templates and email signatures), and stationary

• Terminology and usage: Including commonly misused words or phrases (for example, hyphenated verbiage), language-specific spellings, and synonym usage guidelines

• Company-approved acronyms: Including all company-specific and industry-specific acronyms

• Team processes: Including content formatting guidelines, internal and external linking guidelines, media (for example, screenshots, images, icons, tables, and videos) formatting guidelines, reusable content (including snippets and placeholders) guidelines, workarounds, and temporary processes

Step 4: Implement a style guide request/update process

As mentioned in step 2, style guides must be flexible. Maybe your team has implemented a new process, updated industry-specific verbiage, or deemed existing guidelines obsolete – style guide edits are inevitable. Consider how users can communicate these updates and additions. Also, who is responsible for researching requests and determining if the style guide must be updated?   

Step 5: Determine an outreach strategy

Your team aside, what other teams at your company could benefit from using a style guide? What would be the best way to approach each team about using your style guide? We focused on teams responsible for creating customer-facing documentation and communications. Some teams to consider:

• Teams that create external communications (for example, Marketing, Public Relations, and Legal teams)
• Teams that create company-wide internal communications (for example, Human Resources, Project Management, Product Management, Partner Services, and Executive teams)
• Design teams (for example, Graphic Designers and Product Designers)
• Teams responsible for user interface development and documentation (for example, Developers, Computer Engineers, Technical Writers, and Localization teams)
• Teams with direct customer interactions (for example, Technical Support and Sales teams)

Step 6: Create an onboarding process

Simply providing access to your style guide could suffice here. In the past, my team has put together presentations. However, we found that, more often than not, a style guide presentation was not necessary. I suggest emailing all new users a welcome-type email and including the following items,

• How to access the style guide (see step 2)
• How to submit style guide updates (see step 4)
• Links to a few frequently used pages (for example, glossary and acronym pages)
• Whom to contact for questions or technical issues

Step 7: Put your style guide to work!

Reference your style guide during every step of the content creation life cycle. Remember to request feedback from your style guide users, update the style guide as needed, and onboard new members when appropriate.

My team has a style guide. How do I leverage an in-line writing assistant to make the writing and editing process more efficient?

Step 1: Select a tool

Things to consider when researching and selecting an in-line writing assistant:

• Cost and scalability: Leverage free trials to see which tool works best for your team. Consider who in your organization needs the tool the most. Determine what your initial seat count will look like, and create a plan to increase it as needed.
• Platform support: Is technical support for the tool provided? Does the company allow customers to submit feature requests? Browse any available technical documentation for the tool¾what questions do you have?
• Out-of-the-box features: Prioritize available features with your organization’s needs.
• User and guideline customization: Review customization restrictions. Can the tool support your minimum required number of guideline entries? Are multiple style guides supported? Can you create various user groups?
• Analytics: Analytics are helpful when determining user adherence and entry relevance. If tool analytics are provided, verify that all reports can be exported and that report parameters are clear to readers.
• Tool integration: Verify that your selected tool will fit seamlessly into existing workflows.

Step 2: Implement the tool

This step varies according to the tool you choose to implement. Things to think about:

• What is the most efficient way to import your style guidelines?
• What out-of-the-box features must/can be tweaked to fit your company’s needs?
• Will you start with a test group? If so, determine who your testers are and what feedback you want from them.
• Are specific user groups necessary?
• Are different style guides required?

Step 3: Implement a style guide tool request/update process

Style guide tools must be flexible. Maybe your team has implemented a new process, updated industry-specific verbiage, or deemed existing guidelines obsolete – style guide tool edits are inevitable. Consider how users can communicate these updates and additions. Also, who is responsible for researching requests and determining if the style guide tool must be updated?  

Step 4: Determine an outreach strategy

Your team aside, what other teams at your company could benefit from using an in-line writing assistant? We focused on teams responsible for creating customer-facing documentation and communications. Some teams to consider:

• Teams that create external communications (for example, Marketing, Public Relations, and Legal teams)
• Teams that create company-wide internal communications (for example, Human Resources, Project Management, Product Management, Partner Services, and Executive teams)
• Design teams (for example, Graphic Designers and Product Designers)
• Teams responsible for user interface development and documentation (for example, Developers, Computer Engineers, Technical Writers, and Localization teams)
• Teams with direct customer interactions (for example, Technical Support and Sales teams)

Step 5: Create an onboarding process

Simply providing access to your tool could suffice here. In the past, my team has put together presentations. However, we found that, more often than not, a presentation was not necessary. I suggest emailing all new users a welcome-type email and including the following items:

• How to access the style guide (for reference) and the in-line writing tool (see step 2)
• How to submit tool updates (see step 3)
• Links to a few frequently used style guide pages (for example, glossary and acronym pages)
• Whom to contact for questions or technical issues with the tool

Step 6: Put your tool to work!

Reference your in-line writing assistant during every step of the content creation lifecycle. Remember to request user feedback, update the style guide and tool entries as needed, and onboard new members when appropriate. Use any available user analytics to update guidelines and user groups.