Style Guide Questionnaire for Internal Teams

Style guide builder for internal documentation

Part A: Setup

About 10 minutes. The basics: who you are, where your docs live, and what this guide needs to fix.

A1. Your team or company name

Feeds §03, §06

A1. Name

A1b. Common mistakes to avoid (for example, "Acme inc," "ACME," or "AcmeCo")

Why it matters: Your own name is the word your docs use most. If it's written three different ways, readers notice. In internal docs, those readers are also writers. They'll copy the mistake into everything they write, inside and outside the company.

A2. Style guide owner

Feeds §03, §12

A2. Name / role

A2b. Best way to reach them (for example, email or a Slack channel)

Why it matters: A guide with no owner goes stale. A name (or a role, if people change) gives questions somewhere to go.

A3. Who decides, and by when

Feeds §12

A3. People helping make decisions

A3b. Final sign-off

A3c. Target date for the first version

Date: ________________________________________________

Why it matters: Style guides stall when everyone has an opinion and no one has the final word. Set a date for a "good enough" first version. You'll improve it later.

The target date is for your planning. It won't appear in the guide.

A4. Where your docs live

Feeds §04, §05

A4. Check all that apply:

Pick any.

☐ Confluence

☐ Notion

☐ Google Docs / Google Drive

☐ Microsoft Word / SharePoint / OneDrive

☐ GitHub, GitLab, or other Markdown files

☐ Slack or Teams channels (pinned posts, canvases)

☐ WordPress or another CMS

☐ Other: ________________

A4b. Which one is the source of truth when docs disagree?

Why it matters: Your tools change the rules. For example, Confluence can show an inline link with the page's icon and title, and some teams prefer that format for every link. If your docs live in several places, the template's Documentation Map (§05) helps everyone find the right one.

A5. What this guide will cover

Feeds §03, §05

A5. Check all that apply:

Pick any.

☐ Internal knowledge base / help articles

☐ Processes and procedures (SOPs)

☐ Onboarding docs

☐ Reports

☐ Company, project, or team updates

☐ Meeting notes and decisions

☐ Other: ________________

Why it matters: Scope keeps the guide focused. Anything not on this list doesn't have to follow the guide, which saves arguments later.

A6. Doc types you write most

Feeds §05

A6. Check up to three:

Pick up to 3.

☐ How-to / step-by-step guides

☐ Reference (settings, specs, policies)

☐ Troubleshooting

☐ FAQs

☐ Process / SOP

☐ Explainers (concepts, "how this works")

☐ Other: ________________

Why it matters: The template includes a starter skeleton for each doc type. Your top three get the most attention.

A7. Your top 3 doc pain points

Feeds §01

A7. What bugs your readers (or you) most about your docs today? Check up to three:

Pick up to 3.

☐ Can't find the right doc

☐ Docs are out of date

☐ Formatting is inconsistent

☐ Steps are unclear or missing

☐ Too long; the answer is buried

☐ Too much jargon or too many unexplained acronyms

☐ Voice and tone are all over the place

☐ Nobody knows who owns what

☐ Other: ________________

Why it matters: These answers decide what goes on your Quick Rules card (§01), the one page most people will actually read. Fix the pain points first.

A8. Now, later, or skip

Feeds all sections

A8. You don't have to adopt every section at once. Ship a first version, then grow it.

Part B: Audience & voice

About 10 minutes. Who reads your docs, and how your docs should sound to them.

B1. Who reads your docs

Feeds §03, §06

B1. Check all that apply:

Pick any.

☐ Everyone in the company

☐ New hires

☐ Engineering / IT

☐ Support / customer success

☐ Sales / marketing

☐ Leadership

☐ Contractors or partners

☐ Other: ________________

B1b. Do different readers use different parts of the docs?

Pick one.

☐ No, everyone reads all of it

☐ Yes

B1c. If yes, which readers use which docs? (For example, "Support uses the troubleshooting articles; new hires use onboarding.")

B1d. How technical are most readers?

Pick one.

☐ Mostly non-technical

☐ A mix (Recommended)

if unsure: write for this one

☐ Mostly technical

Why it matters: If you write for experts and a new hire reads it, they get lost. Write for the least experienced reader you expect, and the experts will skim.

B2. Readers who speak English as a second language

Feeds §09

B2. Readers who speak English as a second language

Pick one.

☐ Many of our readers

☐ Some of our readers

☐ Very few or none

☐ Not sure

treat this as "some"

B2b. Do people use translation tools to read your docs?

Pick one.

☐ Yes

☐ No

☐ Not sure

Why it matters: Short sentences, plain words, and no idioms help everyone, and translation tools handle them much better.

B3. US or UK English

Feeds §06

B3. US or UK English

Pick one.

☐ US English

spelling: Merriam-Webster

☐ UK English

spelling: Oxford

☐ Other: ________________

Why it matters: "Color" or "colour," "organize" or "organise." Pick one so spell-check and your writers stop fighting.

B4. Overall tone

Feeds §06

B4. Overall tone

Pick one.

☐ Professional and formal

☐ Professional but friendly (Recommended)

☐ Conversational and casual

Why it matters: Tone is the mood of your writing. Friendly-but-professional works for most internal docs: easy to read, still trustworthy.

B5. How you talk to the reader

Feeds §06

B5. Address the reader as:

Pick one.

☐ "You" (Recommended)

"Click **Save**."

☐ Third person ("The user clicks Save.")

B5b. Use "we" for your team or company?

Pick one.

☐ Yes (Recommended)

☐ No

Why it matters: In internal docs, the reader is part of the "we." It builds a sense of belonging, especially in onboarding. (Customer-facing style guides often avoid "we" because there, it means the company talking *at* the reader.)

B6. Contractions

Feeds §06

B6. Contractions

Pick one.

☐ Yes, use them (don't, you'll) (Recommended)

☐ No, spell them out (do not, you will)

B7. Emoji, GIFs, and humor

Feeds §04, §06

B7. Emoji, GIFs, and humor

Pick one.

☐ Never

☐ Sparingly (Recommended)

☐ Freely

Why it matters: A little personality makes docs friendlier. Too much distracts readers, and strings of emoji are hard for screen readers and for people with visual processing difficulties.

B8. Your reference style guide

Feeds §06, §13

B8. Main reference:

Pick one.

☐ Microsoft Writing Style Guide (Recommended)

free online

☐ Google developer documentation style guide

free online; best for developer docs

☐ Other: ________________

B8b. For grammar and punctuation questions the main reference doesn't answer:

Pick one.

☐ The Chicago Manual of Style (Recommended)

subscription required

☐ AP Stylebook

☐ Other: ________________

Why it matters: No team guide can cover everything. Naming one tiebreaker ends arguments fast. Free guides are easier for everyone to check. You can also search online for a rule even if you don't own the reference, for example, "How do I handle serial commas in Chicago style?" Chicago's own Q&A pages are free to read.

It's okay to use two references. For example, most docs can follow the Microsoft Writing Style Guide while engineers and other highly technical writers follow Google's (or another one). Just note which docs follow which.

B9. Existing brand or voice guidelines

Feeds §03, §06

B9. Do you already have brand guidelines (voice, logos, colors) that internal docs should follow?

Pick one.

☐ Yes, follow them. Link

☐ Yes, but they're for marketing. Internal docs can be more relaxed.

☐ No

Why it matters: Marketing voice and internal-docs voice are cousins, not twins. Decide whether internal docs follow the brand guide strictly or just borrow from it.

Part C: Formatting

About 15 minutes. The small, everyday decisions that make docs look like they came from one team.

C1. Capitalization for titles and headings

Feeds §04

C1. Page titles:

Pick one.

☐ Sentence case: "How to reset your password" (Recommended)

☐ Title Case: "How to Reset Your Password"

C1b. Headings inside a page:

Pick one.

☐ Sentence case (Recommended)

☐ Title Case

☐ Same as page titles

Why it matters: Mixed capitalization is one of the first signs of an unreviewed knowledge base. It's picky but it does matter, because sentence case is easier to read and easier to get right.

C2. Lists

Feeds §04

C2. End punctuation in list items:

Pick one.

☐ Periods only when items are full sentences (Recommended)

☐ Always use periods

☐ Never use periods

C2b. Start each item with a capital letter?

Pick one.

☐ Yes (Recommended)

☐ No

✔ Always included: Numbered lists for steps in order. Bullets for everything else.

C3. The serial comma

Feeds §06

C3. "Docs, slides, and spreadsheets"

Pick one.

☐ Yes, use it (Recommended)

Microsoft, Google, and Chicago all use it

☐ No, skip it

AP style

Why it matters: It's the most-argued comma in English. Decide once, and nobody has to argue about it in comments again.

C4. Bold and italics

Feeds §04

C4. Bold and italics

Pick one.

☐ Bold for UI labels and key warnings; italics for titles of other works (Recommended)

☐ Our own rule

Why it matters: If everything is bold, nothing is. Save it for the things readers must not miss.

C5. Numbers

Feeds §06

C5. Numbers

Pick one.

☐ Spell out zero through nine; use numerals for 10 and up (Recommended)

Microsoft and AP

☐ Spell out one through one hundred

Chicago

☐ Always use numerals

a good fit for technical and developer teams

C5b. Ranges:

Pick one.

☐ En dash: "5–10" (Recommended)

for polished docs; Chicago

☐ Hyphen: "5-10"

easiest to type; common in technical docs and Markdown

☐ Words: "5 to 10"

C5c. Units of measure your docs use often (for example, GB, MB, px, ft, kg):

Why it matters: There's no single "correct" number style. The rule that works is the one your team actually follows every time.

Either way, technical values like versions, pixels, ports, and measurements are always numerals.

C6. Dates, times, and time zones

Feeds §06

C6. Dates:

Pick one.

☐ November 13, 2026 (Recommended)

for US English

☐ 13 November 2026

common in UK English

☐ 2026-11-13

ISO; good for file names and technical docs

C6b. Times:

Pick one.

☐ 12-hour: 3:00 PM (Recommended)

for US English

☐ 24-hour: 15:00

C6c. Time zones:

Pick one.

☐ Always include a time zone (Recommended)

for remote or distributed teams

☐ Only when it matters

Why it matters: "The meeting is at 3" means different things to different people on a remote team.

✔ Always included: Avoid all-number dates like 11/12/2026 in running text. Half the world reads that as November 12 and the other half as December 11.

C7. UI elements, code, and keyboard keys

Feeds §04

C7. Button names, menu items, and other on-screen labels:

Pick one.

☐ Bold: Click Save (Recommended)

Microsoft

☐ "Quotes": Click "Save"

C7b. Keyboard shortcuts:

Pick one.

☐ Ctrl+C (Recommended)

☐ Ctrl + C

☐ Our own style

Why it matters: Readers scan for what to click and what to type. Consistent formatting is how they find it.

✔ Always included: Use code formatting for commands, file names, file paths, and variables, like `config.yml`.

C8. Callouts: notes, tips, and warnings

Feeds §04

C8. Which callout labels will you use? Check all that apply:

Pick any.

☐ Note

☐ Tip

☐ Important

☐ Warning

for anything that could lose data, break something, or create a security risk

☐ Other: ________________

C8b. Does your tool have built-in callout boxes (like Confluence panels or Notion callouts)?

Pick one.

☐ Yes, use them

☐ No

Why it matters: When every other paragraph is a "Note," readers stop reading them. A short, fixed set keeps warnings meaningful.

C9. Links

Feeds §04, §13

C9. Linking to outside websites:

Pick one.

☐ Fine, when the source is reputable (official vendor docs, standards bodies, or sources listed in §13) (Recommended)

☐ Approved sources only. List or link

☐ Ask the guide owner first

C9b. Does your tool have a special link style (like Confluence smart links with the page icon and title)?

Pick one.

☐ Yes, use it for internal links

☐ No, or plain links are preferred

✔ Always included: Descriptive link text ("see the onboarding checklist"), never "click here."

C10. Images, screenshots, and video

Feeds §04, §07, §10

C10. Screenshots:

Pick any.

☐ Crop to the relevant area (Recommended)

☐ Add highlights or arrows. Color or style

☐ Maximum width: px

C10b. Preferred file formats (for example, PNG for screenshots, GIF or MP4 for short demos):

Why it matters: An uncropped screenshot makes readers hunt. An unblurred one can leak a customer's email.

✔ Always included: Alt text for every meaningful image, captions or a transcript for video, and blur or crop anything sensitive in screenshots (see §10).

C11. Color

Feeds §04, §07

C11. Do internal docs need to use brand colors (for highlights, tables, or diagrams)?

Pick one.

☐ Yes. Colors or link

☐ No, the tool's defaults are fine (Recommended)

✔ Always included: Never use color as the only way to show meaning (for example, "the red items are urgent").

C12. Citations and sources

Feeds §06, §13

C12. When docs quote or borrow from another source:

Pick one.

☐ Link to the source inline (Recommended)

for most internal docs

☐ Formal citation style

☐ APA

☐ MLA

☐ Chicago

☐ Other: ________________

Why it matters: Most internal docs need a link, not a bibliography. Research-heavy teams (legal, science, healthcare) may need a formal style.

Part D: Content policies

About 10 minutes. The rules that protect your readers, your customers, and your company.

D1. Accessibility

Feeds §07

D1. Accessibility target:

Pick one.

☐ Follow the basics of WCAG 2.2 Level AA (Recommended)

☐ We have our own accessibility policy. Link

☐ Not sure

use the recommended option

D1b. Do any of your readers use assistive technology (screen readers, screen magnifiers, voice control)?

Pick one.

☐ Yes

☐ No

☐ Not sure

D1c. How will you check docs for accessibility? Check all that apply:

Pick any.

☐ Our tool's built-in accessibility checker

☐ A free checker like WAVE

☐ Manual review using the checklist in §02

☐ Not yet decided

Why it matters: Accessible docs are easier for everyone to read, not just people with disabilities. And "not sure" is a common answer. Many teams don't know who's using a screen reader until someone asks.

D2. Inclusive language

Feeds §08

D2. Do you already have inclusive language guidelines?

Pick one.

☐ Yes. Link

☐ No. Follow our main reference's guidance (Recommended)

D2b. Terms your team has retired, and what to use instead (for example, whitelist → allowlist; master/slave → primary/replica):

Why it matters: Inclusive language is clear language. It keeps any reader from feeling like the docs weren't written for them.

✔ Always included: Use "they" when you don't know someone's gender, and avoid idioms that are violent or ableist (like "kill two birds with one stone" or "sanity check").

D3. Sensitive information

Feeds §10

D3. What counts as sensitive information for your team? Check all that apply:

Pick any.

☐ Passwords, API keys, and other credentials

☐ Customer names and data

☐ Employee names

☐ Employee personal information (like personal email addresses, home addresses, or phone numbers)

☐ Financial information

☐ Health information

☐ Security details (server names, IP addresses, internal URLs)

☐ Unreleased product or business plans

☐ Other: ________________

D3b. Where do secrets live instead (for example, your password manager)?

D3c. Who answers questions about where sensitive information should live (for example, customer addresses or phone numbers)?

D3d. Who should people contact if something sensitive gets posted by mistake?

Why it matters: Internal docs feel private, so people paste things they shouldn't. But internal docs get shared, exported, screenshotted, and searched. Treat every doc like it could leave the building.

✔ Always included: Never put passwords, API keys, or other secrets in docs. Use placeholders like `YOUR_API_KEY` in examples.

D4. Legal and regulatory requirements

Feeds §03, §10

D4. Do any of these apply to your docs? Check all that apply:

Pick any.

☐ Privacy laws (for example, GDPR or state privacy laws)

☐ Health information rules (for example, HIPAA)

☐ Financial regulations

☐ Security audits or certifications (for example, SOC 2 or ISO 27001)

☐ Government contracts

☐ None that we know of

☐ Not sure

ask your legal or compliance contact before publishing the guide

D4b. Required labels or notices (for example, "Confidential: Internal use only"):

Why it matters: A style guide can't replace your legal team, but it can remind writers when to check with them. And your legal team will appreciate the chance to weigh in on when that is.

D5. AI writing tools

Feeds §11

D5. Does your company have a policy on AI use for internal purposes already?

Pick one.

☐ Yes. Link

☐ No

D5b. Can writers use AI tools for docs?

Pick one.

☐ Yes, with human review (Recommended)

☐ Only approved tools

☐ No

D5c. What can AI help with? Check all that apply:

Pick any.

☐ Drafting

☐ Editing and proofreading

☐ Summarizing long docs or meetings

☐ Translating

☐ Other: ________________

D5d. Should docs say when AI helped write them?

Pick one.

☐ Not required, as long as a person reviewed it (Recommended)

☐ Yes, add a note

☐ Follow our company AI policy

if you have one; see above

Why it matters: Most teams are already using AI tools, with or without a policy. A clear rule keeps sensitive data safe and makes sure someone is accountable for what gets published.

✔ Always included: Never paste sensitive information (see D3) into an AI tool your company hasn't approved. A person reviews and owns every doc, no matter who or what drafted it.

Part E: Maintenance

About 5 minutes. A style guide is a living document. These answers keep it alive.

E1. Who contributes to docs

Feeds §12

E1. Who contributes to docs

Pick one.

☐ Anyone on the team, with review (Recommended)

☐ Specific people only

☐ Only the docs team or guide owner

E2. How changes get approved

Feeds §12

E2. Small fixes (typos, broken links):

Pick one.

☐ Anyone can fix them right away (Recommended)

☐ They still need review

E2b. Bigger changes (new docs, rewrites, new rules for this guide):

Pick one.

☐ The doc owner or guide owner approves (Recommended)

☐ Any teammate can review

☐ Other: ________________

E2c. What counts as a bigger change? (For example, anything that changes steps, a policy, or a rule in this guide.)

Why it matters: If fixing a typo takes a ticket and two approvals, nobody fixes typos.

E3. How people suggest changes to this guide

Feeds §12

E3. How people suggest changes to this guide

Pick any.

☐ Comment on the guide itself

☐ Post in a channel

☐ Contact the guide owner directly (see A2)

☐ Open a pull request or issue

for docs in GitHub or GitLab

☐ Other: ________________

E4. Review schedule

Feeds §12

E4. How often will someone review this guide?

Pick one.

☐ Every 6 months (Recommended)

☐ Once a year

☐ Only when something changes

E4b. Show a "Last reviewed" date on docs?

Pick one.

☐ Yes (Recommended)

☐ No

Why it matters: Outdated docs are worse than no docs, because people trust them. A visible review date tells readers how much to trust what they're reading.

E5. Retiring old docs

Feeds §12

E5. When a doc is out of date and nobody will update it:

Pick one.

☐ Archive it (Recommended)

☐ Add an "Outdated" banner and leave it up

☐ Delete it

E5b. Who decides?

E6. Sharing the guide

Feeds §03

E6. Where will the finished guide live?

E6b. How will people find out about it? Check all that apply:

Pick any.

☐ Team announcement or meeting

☐ Part of onboarding for new hires

☐ Pinned in a team channel

☐ Linked from doc templates

☐ Other: ________________

Why it matters: A guide nobody knows about can't help anybody. Put it where writers already are.