Bullet Lists: Writing Rules, Structure and Examples
Use bullet lists to make parallel, independent points easy to scan and extract while preserving the reasoning, hierarchy, and argument that give them context.
A bullet list is an unordered set of related, independent points. It lets a reader recognize the category once, then scan each member without extracting it from a paragraph. Use bullets only when the items belong at the same logical level and their order does not change the meaning.
- Start every item in the same grammatical form.
- Keep every item within the same length band.
- Introduce the set before the first bullet.
- Return to reasoning after the final bullet.
That rendered example is a true list: four peer rules, all phrased as imperative sentences, none dependent on position. The paragraph above establishes the category; the sentence below explains what the set proves. The bullets improve access to the argument without replacing it.
Why this element matters
Readers do not scan a paragraph as a bag of sentences. They look for a claim, follow the relationship between ideas, and decide whether the explanation deserves attention. A bullet list changes that reading behavior. Its vertical rhythm signals, “these points are peers; you may inspect them one at a time.” That lowers the effort needed to find a relevant requirement, option, symptom, or characteristic.
The same boundary improves machine extractability: the ability of a search engine, AI system, or content transformer to isolate items while retaining their shared context. A semantic unordered list exposes the collection and its members explicitly. Parallel opening words also help a machine infer that the items perform the same role. “Requires admin access,” “Requires a verified domain,” and “Requires an active subscription” form a clearer set than three items that alternate among questions, fragments, and commentary.
Bullets are not automatically clearer than prose. A paragraph expresses cause, contrast, qualification, sequence, and conclusion through sentences and transitions. Converting it into bullets can erase those relationships. The list then looks easier while communicating less. This is the central risk of the element: visual scanability can disguise lost reasoning.
The element writing rules take precedence. Identify what the passage does before choosing its appearance. A summary of conclusions belongs in key takeaways , even if that element renders bullets. Ordered instructions belong in a step list . A bullet list is the correct element only when its purpose is to present an unordered set of peer items inside the surrounding argument.
When to use it
Use a bullet list when one lead-in can accurately govern three or more items and each item remains useful when read independently. Strong uses include requirements, characteristics, examples from one category, non-sequential options, failure symptoms, inclusion criteria, and compact recommendations of equal priority.
Run three tests before converting prose:
- Peer test: Can every item answer the same implied question?
- Order test: Can two adjacent items swap places without changing the instruction or conclusion?
- Context test: Does the lead-in supply enough context for every item without forcing each one to repeat it?
If all three pass, bullets probably help. If the order test fails, use numbered instructions or chronological prose. If the peer test fails, split the material into separate paragraphs or headings. If the context test fails, each point needs its own explanation.
Near misses deserve particular attention:
- A set of actions is not a bullet list when one action unlocks the next; it is an ordered procedure.
- A set of claims is not a list when the second qualifies the first and the third draws a conclusion; it is an argument.
- A set of products is not necessarily a list when readers need criterion-by-criterion evaluation; use a comparison table .
- A set of completion gates is not merely informational when readers must verify each one; it is a checklist.
- Two alternatives rarely justify bullets. Write “Use X when …; use Y when …” unless each requires substantial explanation.
Do not use bullets to rescue an overlong paragraph before diagnosing why it is long. The paragraph may contain several claims, missing headings, or an undeveloped causal chain. Fix that structure first. Bullets are not a universal cleanup operation.
Where to place it
Place a bullet list immediately after a complete lead-in that names the set and explains why the reader needs it. “The migration requires:” is grammatical but weak because it does not establish consequence. “Collect these four inputs before migration so the rollback can restore the original state:” tells the reader what the items are and why they matter.
Place interpretation immediately after the list when the items support a decision or claim. The closing paragraph should identify the pattern, priority, exception, or next action created by the set. A list may end a small reference section when the purpose is purely enumerative, but it must not leave an argument suspended.
Exact position rules:
- Put the lead-in and list in the same section; never make readers cross a heading to discover what the bullets enumerate.
- Keep evidence beside the claim it supports. Do not insert a list between a claim and its citation, calculation, or qualification.
- Do not place an unordered list directly beside an ordered list without a transition that explains the change in meaning.
- Do not stack two bullet lists back to back. Add interpretation, merge true peers, or give each collection a descriptive subheading.
- Do not place a generic bullet list immediately below a key-takeaways box when both summarize the same material.
- Do not put a call to action inside the final bullet. Close the collection, explain the conclusion, then present the action separately.
The element may appear several times on a long page, but prose must carry the relationships between those lists. When every section becomes a heading plus bullets, the page has developed the orphan list failure: collections exist, but nothing explains how they connect.
Anatomy
A complete bullet list has five semantic regions:
- Context: the preceding claim or explanation that makes the collection relevant.
- Lead-in: a complete sentence that names the shared category.
- List container: one semantic unordered list that establishes the item relationship.
- Items: peer statements with parallel grammar and a consistent detail level.
- Interpretation: the following sentence or paragraph that reconnects the set to the argument.
The marker, indentation, and spacing make hierarchy visible, but they do not define it. The source structure must remain an unordered list when styles, scripts, and visual markers are absent.
Design examples
The design system supports three variants. Their content contract stays the same; only density and layout change.
Default
Use the default single-column variant for complete statements and most editorial content. It gives each item enough separation to scan while keeping the set visually connected.
Compact
Use compact spacing for labels, short requirements, or values of 3–12 words. Compact is not permission to compress reasoning into fragments; the surrounding prose still supplies context.
Two-column
Use two columns only for six to ten short, independent items that remain understandable in the renderer’s reading order. At narrow widths, the layout must collapse to one column. Do not use it for explained points, manual cross-column ordering, or items whose sequence suggests a ranking.
No variant may replace native list semantics with decorative icons and unrelated containers. Visual customization must preserve one collection and one item per statement.
Parameters
The limits below prevent lists from expanding until they should be sections. “Source” identifies where the canonical value is authored.
| Name | Type | Required | Min/max | Default | Source |
|---|---|---|---|---|---|
variant | Enum | No | default, compact, or two-column | default | Directive or shortcode attribute |
title | Plain string | No | 2–8 words; 60 characters | Omitted | First heading in the body, only when the post type requires a titled block |
leadIn | Plain Markdown | Yes | 8–35 words; one sentence | None | Body before the list |
items | Markdown list | Yes | 3–10 items; target 3–7 | None | Body |
item | Plain Markdown | Yes | 3–45 words; one selected length band per list | None | Each body list item |
item.link | Root-relative or HTTPS URL | No | 0–1 primary link per item | Omitted | Inline body link |
interpretation | Markdown | Required when the list supports an argument | 10–80 words; one paragraph | Omitted for purely enumerative reference lists | Body after the list |
The renderer does not infer a title from the lead-in. A title names a reusable or post-type-defined block; the lead-in completes the sentence-level relationship between surrounding prose and items. Most inline lists need no title.
Syntax and code examples
All three mappings preserve the same lead-in, items, variant, and interpretation. The portable directive is canonical. The Hugo and WordPress examples describe platform adapters; they do not authorize page-specific styling.
Portable Markdown directive
:::bullet-list{variant=default}
Check these conditions before publishing:
- The claim names its scope and time period.
- The source supports the exact wording used.
- The page explains any material limitation.
Together, these checks keep a defensible claim from becoming an overstatement.
:::
Hugo shortcode
{{< bullet-list variant="default" >}}
Check these conditions before publishing:
- The claim names its scope and time period.
- The source supports the exact wording used.
- The page explains any material limitation.
Together, these checks keep a defensible claim from becoming an overstatement.
{{< /bullet-list >}}
Until a project registers that adapter, render the content as ordinary semantic Markdown rather than inventing a local shortcode. The source still satisfies the editorial contract.
WordPress
<!-- wp:amicited/bullet-list {"variant":"default"} -->
<p>Check these conditions before publishing:</p>
<ul>
<li>The claim names its scope and time period.</li>
<li>The source supports the exact wording used.</li>
<li>The page explains any material limitation.</li>
</ul>
<p>Together, these checks keep a defensible claim from becoming an overstatement.</p>
<!-- /wp:amicited/bullet-list -->
If no custom block exists, native WordPress List and Paragraph blocks are the correct accessible fallback. Preserve the wrapper’s variant only when the theme supports it.
Examples
Good: parallel publication checks
Before approving a comparison, verify that every option receives the same treatment:
- Apply the same evaluation criteria to every option.
- Use evidence from equivalent time periods.
- State material limitations beside the affected claim.
- Separate measured facts from editorial judgment.
These items work because they answer one question—what makes the comparison fair—and each begins with an imperative verb followed by one object. Their lengths are similar, their order is interchangeable, and the closing sentence explains the common standard.
Bad: an argument broken into bullets
- Readers scan pages.
- Because scanning is common, lists are useful.
- But lists remove transitions.
- Therefore, use lists carefully and test accessibility, which also matters for screen readers and has several implementation details.
This is bad because the items are not peers. They form a premise, inference, qualification, and conclusion, so moving them changes the argument. Their grammar and length also drift. Recasting the passage as bullets has removed the connective reasoning while retaining transition words that reveal the hidden paragraph. Write it as prose: readers scan pages, so lists can help them locate peer points; however, lists remove transitions, which means the author must preserve reasoning before and after the set.
Schema markup and accessibility
An ordinary bullet list does not need standalone schema markup. It remains visible content within the enclosing Article, TechArticle, product description, or other page-level type. Do not create ItemList markup merely because HTML contains a <ul>; structured data should represent a meaningful entity collection, not every visual enumeration.
An ItemList may be appropriate when the list itself is a principal, finite collection—such as a declared set of included locations or ranked products—and every visible item maps to a real ListItem. For an unordered collection, do not invent ranks or imply preference through position. The schema output must match the visible count and names. Most editorial bullets feed no schema property directly.
Accessibility starts with <ul> and one <li> per item. Do not type bullet characters into paragraphs, insert line breaks to imitate items, or use a series of <div> elements only because CSS can draw markers. Screen readers announce native list boundaries and item counts, which gives users the same category signal visible readers receive.
Keep nesting to one level and only when every child belongs to its parent. A nested list needs at least two items; a single indented item is usually another sentence. Ensure custom icons have no competing accessible name when they are decorative. Links must describe their destination, and meaning must not depend on marker color, shape, or column position. Two-column output must preserve a predictable source and keyboard reading order.
Writing rules
Choose one of three item length bands and use it throughout a list:
- Scan labels: 3–12 words. Use for tools, requirements, symptoms, or compact category members.
- Complete statements: 8–25 words. Use for rules, benefits, criteria, and recommendations that stand alone.
- Explained points: 20–45 words. Use when each item needs one reason or qualification; move longer explanations into prose or subsections.
Use three to seven items normally. Two items fit a sentence or contrast. Eight to ten items require a clear reason, deliberate grouping, and usually the compact or two-column variant. More than ten forces readers to build their own categories; split the set or introduce subheadings.
Parallel construction is mandatory. Begin every item with the same part of speech and maintain the same implied subject. Good sets use imperative verbs (“Confirm,” “Record,” “Test”), nouns (“Access,” “Evidence,” “Ownership”), or complete declarative sentences. Do not start one item with a verb, another with “You should,” and a third with a question.
Match tone, tense, punctuation, capitalization, and detail. Use sentence case. End complete sentences with periods; omit periods from short fragments. Put the differentiating words early instead of repeating a long identical opening. Bold may identify a short label followed by an explanation, but every item must use the same label pattern.
Never put these inside an ordinary bullet list:
- Required ordered actions whose sequence affects the result.
- Several paragraphs, multiple headings, or an independent mini-article per item.
- Tables, forms, video players, testimonials, or promotional cards.
- Unqualified claims that rely on context outside the item to remain accurate.
- A mixture of requirements, examples, conclusions, and calls to action.
Avoid the orphan list failure. It occurs when nearly every paragraph is converted to bullets, leaving no prose to establish cause, conflict, evidence, or conclusion. A practical review signal is three consecutive sections that each contain a short lead-in and a list but no interpretive paragraph. Restore the strongest claim to prose, combine overlapping collections, and keep only the lists that pass the peer, order, and context tests.
Post types that use it
The rows below are driven by the postTypes frontmatter. “Use” describes the role of bullets, not a requirement to force them into every page.
| Post type | Use | Position |
|---|---|---|
| Ultimate guide | Usually, for peer characteristics, examples, requirements, or compact section summaries. | Inside the relevant teaching section, after context and before interpretation. |
| How-to guide | Sometimes, for unordered prerequisites, supplies, outcomes, or troubleshooting symptoms. | Before ordered steps or inside supporting explanation; never as a substitute for the procedure. |
| Listicle guide | Usually, for consistent features or criteria within each entry. | Inside each entry after its verdict, using the same item pattern for every entry. |
| A-versus-B comparison | Sometimes, for peer strengths or constraints that do not require cross-option scanning. | Below a criterion explanation; use a table when readers must compare rows directly. |
| Checklist article | Sparingly, for context or examples that are not completion gates. | Outside the checkable set, with a transition that makes the semantic difference explicit. |
| Troubleshooting guide | Usually, for symptoms, possible causes, or evidence to collect when order is irrelevant. | After the symptom description and before ordered diagnostics or repairs. |
| Documentation article | Usually, for requirements, accepted values, permissions, and non-sequential options. | Beside the feature or setting it qualifies, not between a command and its result. |
QA checklist
Before publication, verify every item:
- The lead-in names one category and explains why the set matters.
- Every item answers the same implied question and sits at the same logical level.
- Reordering items would not change the instruction, chronology, or argument.
- All items use parallel grammar, tone, tense, capitalization, and punctuation.
- Every item stays inside one chosen length band and the list contains 3–7 items, or a justified exception.
- The list uses semantic
<ul>and<li>output rather than decorative bullet characters. - Nested items stop at one level, while columns retain a predictable reading order.
- Links are descriptive, verified, and limited to one primary destination per item.
- The paragraph after the list states the interpretation when the set supports an argument.
- The list does not duplicate a typed summary, checklist, step list, table, or other purpose-specific element.
- The page contains enough prose to carry reasoning between collections and avoids the orphan list failure.
- Portable Markdown, Hugo, and WordPress mappings preserve the same items and meaning.
FAQ
How many items should a bullet list contain? Use three to seven normally. Group or split longer sets instead of making the reader categorize them unaided.
How long should each bullet be? Pick one band for the whole list: 3–12, 8–25, or 20–45 words. Consistency matters more than reaching the maximum.
Should bullet items end with punctuation? Use periods for complete sentences and no terminal punctuation for short fragments. Apply the choice consistently.
Can bullet lists contain links? Yes, but use descriptive anchors and normally no more than one primary link per item.
When should bullets become numbered steps? Use numbers when order affects the outcome. Unordered bullets promise that sequence does not matter.
Bullet lists work when they expose a real collection and let prose keep doing the reasoning. The goal is not to maximize scanability at every line; it is to make peer points easy to find without destroying the relationships that make them meaningful.
More tutorials in this section
Ready to put it into practice?
Free check · 7-day trial · no credit card