diff --git a/docs/documentation/style-guide.md b/docs/documentation/style-guide.md
index 7f426dd1b4e7c325345cf4e54bf5aadbb535ecc1..56ff63c75be350dea0c0922b9214669a6e0f806d 100644
--- a/docs/documentation/style-guide.md
+++ b/docs/documentation/style-guide.md
@@ -5,36 +5,44 @@ high-quality "finished" [documentation](/documentation/index.md)
 about CiviCRM. This Style Guide page documents the standards we wish to
 uphold to ensure all guides maintain this high level of quality.
 
-## Parts, chapters, sections
+## General guidelines
 
-Similar to most text books and manuals, we divide our guides into "parts",
-"chapters", and "sections". In mkdocs, these blocks translate as follows:
+### Docs nomenclature {:#nomenclature}
 
--   "part" - folder
--   "chapter" - file (in markdown), also one web page with a given URL
--   "section" - heading within the page
+To streamline communication about documentation issues, we define the following terms:
+
+-   "Chapter" - folder
+-   "Sub-chapter" - a folder within a folder
+-   "Page" - file (in markdown)
+-   "Section" - heading within the page
+
+### Page names
 
 In the navigation menu (as stored in `mkdocs.yml`):
 
--   Keep the page hierarchy to the depth described above
-    (i.e. do not put folders within other folders).
--   Each chapter name should be short enough to fit nicely in the menu,
+-   Each page name should be short enough to fit nicely in the menu,
     but also long enough to stand on its own to a reasonable extent.
     The titles set here are used in the navigation menu *and* the page title
     that displays in the browser tab. The guide will be more usable if the
     reader sees two tabs titled "Using Hooks" and "API Usage" instead of
     "Usage" and "Usage".
+    
+### Introductory paragraphs
+
+Each page should start with a paragraph that explains what will be
+covered in the page.
 
-Each chapter should start with a paragraph that explains what will be
-covered in the chapter.
+### Cumulative concepts
 
 Effort should be given to arrange all content within a guide so that skills and
 concepts which build upon one another are presented sequentially.
 Although guides should not require start-to-finish reading, providing the
 option (when possible) is helpful to some readers.
 
+### Cross-references
+
 Don't use terms like "previous chapter", etc. because we may add or re-arrange
-chapters in the future. Instead, use a hyperlink to the chapter.
+pages in the future. Instead, use a hyperlink to the page, or ideally to the specific section within the page.
 
 ### Hackable URLs
 
@@ -42,19 +50,19 @@ When you organize several markdown files into one folder, it's good practice to
 
 ### Headings
 
-The first heading in a chapter should be Heading 1. All others should be
+The first heading in a page should be Heading 1. All others should be
 in H2 and H3, only where necessary.  If you find yourself wanting to use
-H4, consider if it's truly necessary and whether the chapter should
+H4, consider if it's truly necessary and whether the page should
 instead be refactored.
 
-### Capitalization
+### Title capitalization
 
-Titles for parts, chapters, and sections should all be in sentence case
+Titles for chapters, pages, and sections should all be in sentence case
 (first word capitalized), not headline case (each word capitalized).
 
-## Formatting conventions
+## Describing the CiviCRM user interface
 
-### Describing the CiviCRM user interface
+### Bold for things you click
 
 Menu selections, buttons, tabs (basically, things that the reader is
 being told to click) should be in bold.
@@ -66,6 +74,8 @@ For example:
 -   Modify event type labels by clicking **Edit** on any row.
 -   Click **Add Event Type** to create a new category for your events.
 
+### UI element capitalization
+
 Elements of the system and interface should be capitalized (e.g. the
 Events component, the Template Title field).
 
@@ -78,13 +88,19 @@ thing or technical definition (e.g. scheduled reminders, plain text).
 Use your best judgment as to what serves the reader; trying to enforce
 consistency in this arena will slow us down or drive us crazy.
 
+### Quotes
+
 Quotes should be avoided as much as possible; however, do use them when
 they seem necessary for clarity (e.g. if you are talking about setting
 or field labels that are long phrases).
 
+### Types of CiviCRM pages
+
 You can divide the CiviCRM interface into administration pages and
 public-facing pages.
 
+## Formatting conventions
+
 ### Bullets and numbered lists
 
 Bulleted lists should be used to convey short snippets of information.