Skip to content
9 changes: 8 additions & 1 deletion packages/styleguide/.storybook/preview.ts
Original file line number Diff line number Diff line change
Expand Up @@ -23,7 +23,14 @@ const preview: Preview = {
order: [
'Gamut',
'Meta',
['About', 'Best Practices', 'Contributing', 'FAQs', 'Stories'],
[
'About',
Copy link
Contributor

@uxemilylee uxemilylee Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@LinKCoding What do you think of the order of the sections? Would we want descending order based on priority? It looks like it's alphabetical in the left nav, and there's a mismatch between the left nav and when I'm on the About page.

'Best Practices',
'Contributing',
'FAQs',
'Stories',
'Gamut Writing Guide',
],
'Foundations',
'Layouts',
'Typography',
Expand Down
4 changes: 2 additions & 2 deletions packages/styleguide/src/lib/Meta/About.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ import { parameters as contributingParameters } from './Contributing.mdx';
import { parameters as deepControlsParameters } from './Deep Controls Add-On.mdx';
import { parameters as faqsParameters } from './FAQs.mdx';
import { parameters as installationParameters } from './Installation.mdx';
import { parameters as storiesParameters } from './Stories.mdx';
import { parameters as styleGuideParameters } from './Style Guide/About.mdx';
import { parameters as usageGuideParameters } from './Usage Guide.mdx';

export const parameters = {
Expand All @@ -32,7 +32,7 @@ export const parameters = {
contributingParameters,
deepControlsParameters,
faqsParameters,
storiesParameters,
styleGuideParameters,
brandParameters,
installationParameters,
usageGuideParameters,
Expand Down
36 changes: 36 additions & 0 deletions packages/styleguide/src/lib/Meta/Style Guide/About.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
import { Meta } from '@storybook/blocks';

import {
AboutHeader,
addParentPath,
TableOfContents,
} from '~styleguide/blocks';

import { parameters as formattingParameters } from './Formatting.mdx';
import { parameters as generalPrinciplesParameters } from './General Principles.mdx';
import { parameters as languageAndGrammerParameters } from './Language and Grammer.mdx';
import { parameters as linkingParameters } from './Linking.mdx';
import { parameters as referencingCodeParameters } from './Referencing Code.mdx';
import { parameters as storiesParameters } from './Stories.mdx';

export const parameters = {
id: 'Meta/Gamut Writing Guide',
title: 'Gamut Writing Guide',
subtitle:
'Guidelines and standards for creating consistent, clear, and effective documentation.',
};

<Meta title="Meta/Gamut Writing Guide/About" />

<AboutHeader {...parameters} />

<TableOfContents
links={addParentPath(parameters.id, [
generalPrinciplesParameters,
languageAndGrammerParameters,
formattingParameters,
linkingParameters,
referencingCodeParameters,
storiesParameters,
])}
/>
71 changes: 71 additions & 0 deletions packages/styleguide/src/lib/Meta/Style Guide/Formatting.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
import { Meta } from '@storybook/blocks';

import { AboutHeader } from '~styleguide/blocks';

export const parameters = {
id: 'Formatting',
title: 'Formatting',
subtitle: 'Standards for formatting text and content in documentation',
status: 'static',
};

<Meta title="Meta/Gamut Writing Guide/Formatting" />

<AboutHeader {...parameters} />

Consistent formatting makes documentation easier to scan, understand, and implement. These standards ensure our content is predictable and professional across all Gamut components.

## Numbers

- Use numerals for all numbers
- Use commas for thousands: 1,000

## Units of Measurement

- Use standard units: px, rem, em, %
- Include space between number and unit in prose: "16 pixels"
- No space in code: `16px`, `2rem`

## Lists

Lists help break down complex information into digestible pieces. Use them to organize features, steps, or related concepts.

### Bulleted lists:

- Use for unordered items
- Use parallel structure
- End with periods if items are complete sentences
- No periods if items are fragments

### Numbered lists:

- Use for sequential steps or prioritized items
- Start each item with a capital letter

## Code Blocks

- Use triple backticks (` ``` `) with language identifier (e.g., `tsx`, `javascript`, `css`)
- Include comments for complex examples
- Keep examples concise and focused

Example:

````
```tsx
<TextButton onClick={handleClick}> Click me </TextButton>
```
````

## Headings Hierarchy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One heading style thing that I realized while reviewing these docs is that I really don't like empty headings. If I have a heading that immediately leads into sub-sections, I always try to write a sentence that introduces the heading. It doesn't take much to add a short description to the heading (one sentence will do), but doing so improves clarity and makes the documentation feel more complete.

For instance:

❌ bad
## Nintendo characters
(no content here)
### Protagonists

- Mario
- Luigi
- Link

### Antagonists

- Bowser
- Ganon
✅ good
## Nintendo characters

Nintendo has over a billion characters across a gazillion games.
The following lists split them into two categories: good guys and bad guys.

### Protagonists

- Mario
- Luigi
- Link

### Antagonists

- Bowser
- Ganon


- H1: Page title (used once and set in the `parameters` object, not used explicitly)
- H2: Major sections
- H3: Subsections
- Maintain logical order — don't skip levels
Comment on lines +61 to +64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be more clear to say something like:

  • Start with second-level headings (<h2> in HTML, ## in markdown). The first level heading is automatically set by the title parameter.
  • Don't skip heading levels. This ensures a logical reading order.


## Whitespace

- Use blank lines to separate sections
- Don't use multiple consecutive blank lines
- Indent code consistently (2 spaces for TypeScript/TSX)
- If you prefer tabbing, then it should be set as 2 spaces
Original file line number Diff line number Diff line change
@@ -0,0 +1,47 @@
import { Meta } from '@storybook/blocks';

import { AboutHeader } from '~styleguide/blocks';

export const parameters = {
id: 'General Principles',
title: 'General Principles',
subtitle: 'Core principles for writing effective documentation',
status: 'static',
};

<Meta title="Meta/Gamut Writing Guide/General Principles" />

<AboutHeader {...parameters} />

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be good to have an introductory paragraph to this page especially, but we also might want that for every separate page. This page's introduction should be philosophical and inspirational, helping to answer "why" for subsequent style opinions.

For instance: "Great documentation improves understanding. Not just for our readers but for us, the authors. The act of writing forces us to articulate our mental models clearly so that our readers can share in our framing and understanding." (don't use this, it's just off the dome)

I'm also very partial to the Vue writing guide opening paragraph:

Writing documentation is an exercise in empathy. We're not describing an objective reality - the source code already does that. Our job is to help shape the relationship between users and the Vue ecosystem. This ever-evolving guide provides some rules and recommendations on how to do that consistently within the Vue ecosystem.

Aside from the clarity of their perspective on the point of documentation, I like their inclusion of "this ever-evolving guide" since it makes it immediately clear that their guidance isn't final.

Good documentation does more than describe — it helps people succeed. These principles guide how we write about Gamut components, with a focus on clarity, accessibility, and usefulness. Whether you're documenting a new component or updating existing content, prioritize being clear about what something does, honest about its limitations, and helpful in showing how to use it effectively. We want to remove barriers and make it easier for designers and developers to do great work. Like our design system itself, this guide is a living document — it will continue to evolve as we add new features and learn from our users.

## Voice and tone

- Friendly and conversational: Write as if explaining to a colleague
- Direct and action-oriented: Use "you" to address readers
Copy link
Member

@sh0ji sh0ji Nov 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I much prefer "we" in any writing where the reader is learning from an expert because it quietly invites the reader to be the expert, whereas "you" creates a line between author and reader: "I the expert am telling you the novice what's what." Or more simply, "we" is inclusive, "you" creates separation.

My general advice here is to prefer "we" whenever possible because there will be times when "you" is the better choice. For instance, it wouldn't make sense to say "use our best judgment" if we're encouraging the reader to use their judgment, so "use your best judgment" would be fine. But those instances are surprisingly rare—we can usually use "we" for most things without much effort.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For product copy/UX writing we :) generally use "we" as the voice of the company, and we use "you" for a more conversational tone with learners.

I can understand this sentiment of being inclusive for this context of documentation. One question: I remember seeing a reference to being explicit about "we" as Codecademy where applicable (can't seem to find it right now)... would we want to place that piece of information closer to this, since Gamut is public and referred to from some of our courses?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Our users are primarily (entirely?) other Skillsoft employees, which is one reason we might want this to be different from company style.

As an aside, this was a very specific style point that was used to great effect at Norton. When we switched to using "we" in our composition list in particular, we saw huge growth (it was accompanied by lots of other changes, but this one was notable to our editor). Instead of an expert telling you—the learner—how to write, we were writing together.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like we can take this in different directions —

  1. where we explicitly call out when to use "we" (maybe add this in as part of line 18)
  2. removing/rewriting line 19 to emphasize "we" more

I think it seems to lean more towards point 1, where we call out the usage of "we" (there is also a separate section in "Language and Grammar" that touches upon this.

Will note that we should discuss as a group

- Encouraging without overpromising: Be supportive but realistic
- Global audience awareness: Avoid idioms, slang, and culturally-specific references

## Inclusivity

- Use inclusive language that makes all contributors feel welcome
- Avoid jargon unless necessary — define terms when first introduced
- Write for accessibility — ensure screen readers can parse content
- Consider contributors of varying experience levels and roles (designers and developers)

## Transparency

- Clearly indicate component status:
- `current`: Stable, recommended for use
- `updating`: In progress, API may change
- `deprecated`: Do not use for new work
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small quibble: "deprecated" means still actively supported but an end is planned. I mention it because a lot of people think it means "no longer supported" in my experience.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Quick question, are these 4 component status labels considered "props"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sh0ji — is that to say I should update the definition to be more specific, like what you wrote? or something else?

@uxemilylee — semantics semantics lol
these status labels are part of an object that have key/value pairs, which can also be called "properties" (sometimes folks call the "key" a "property"... 🤷) which I guess can be shortened to "prop"
More often, when folks are talking about props, esp the Gamut team, we're referencing information that's being passed into a component. Which actually in this case, is being passed into a StatusTab component! 🤯
So to come full circle, yes, they're considered "props"

- `static`: Reference material, no active development
- Link to source code and design files (Figma, GitHub)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nitpick 😅: Could we switch the order to match:

Link to source code and design files (GitHub, Figma)

- Direct contributors to help channels (#gamut-team, Office Hours)

## Consistency

- Use the same terminology throughout documentation
- Match language between headings, body copy, and code examples
- Maintain consistent component naming across packages
- Follow established patterns from existing components
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
import { Meta } from '@storybook/blocks';

import { AboutHeader } from '~styleguide/blocks';

export const parameters = {
id: 'Language and Grammer',
title: 'Language and Grammer',
subtitle: 'Guidelines for language usage and grammar in documentation',
status: 'static',
};

<Meta title="Meta/Gamut Writing Guide/Language and Grammer" />

<AboutHeader {...parameters} />

## Voice

- Use active voice: "The component renders..." not "The component is rendered by..."
- Use second person ("you") when addressing the reader
- Use imperative mood for instructions: "Add the component" not "You should add the component"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lol thanks for using this phrase! "imperative mood"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was the robot, I actually had to google that


## Tense

- Use present tense for current functionality: "The Button accepts a variant prop"
- Use future tense sparingly, only for confirmed features
- Avoid past tense except in changelogs or historical context
Comment on lines +25 to +26
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't disagree, but why?

This is probably universal, but we should briefly explain why something is recommended.

Copy link
Contributor

@uxemilylee uxemilylee Nov 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe these references about plain language guidelines could help! The first one cites many references that support using the active voice and preference for present tense.
https://readabilityguidelines.co.uk/clear-language/plain-english/
https://digital.gov/guides/plain-language/writing

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated, lmk your thoughts!


## Pronouns

- Use "you" for the user
- Avoid "we" unless referring to the Codecademy team
- Avoid “I/my/me” entirely
- Avoid "your/my" in button labels: prefer "Go to dashboard" over "Go to your dashboard"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this getting into the component-specific writing guidelines? Or are there parts of Storybook where contributors are writing buttons?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very fair, I will remove


## Articles

- Use articles (a, an, the) for clarity

- "The Box component" (first mention) → "the component" (subsequent mentions)
- When plural, the component should stay singular and the “component” is the pluralized, e.g
- ✅ “These Box components are…”
- ❌ “These Boxes are…”
- Omit articles in lists when appropriate for brevity

## Prepositions
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we find a better title here?

Copy link
Contributor

@uxemilylee uxemilylee Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kind of related...

It looks like several of the bulleted items on the Language and grammar are about referring to components or other referents. Maybe some of these could be moved to the Referencing code section?

Examples of what could be moved:

  • "The Box component" (first mention) → "the component" (subsequent mentions)
  • When plural, the component should stay singular and the “component” is the pluralized, [...]
  • Use "in" for code locations: "in the componentName.mdx file"


- Platform-agnostic language: "select" or "choose" (not "tap" or "click")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think something like "Prefer words that aren't specific to input devices" might be more clear here. It wasn't until I got to "tap" that I understood what this meant.

Also strong quibble: "click" is device agnostic and often the best choice. Screen reader users can click, keyboard users can click, mouse users can click, and touch device users can click.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting! The majority of preexisting writing guidelines I've encountered have said to use "select" as the most device-agnostic and inclusive term (often noting "click" and "tap" as being device-specific).

Hmm... is touching the surface of a device a "click"? Or is the noted guidance an urban myth?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, this is an older thread: https://ux.stackexchange.com/questions/57666/documentation-do-we-click-push-press-or-select-a-button-on-a-touch-s
have things changed? I haven't heard someone clicking on a phone screen 🤔

- Avoid directional language: not "the form on the right" or "in the section below"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need non-directional copy to accompany these directional examples. Maybe something like, "the following/adjacent form" and "in the next section"?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I often use "the previous __" and "the following __."

- Use "in" for code locations: "in the `componentName.mdx` file"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we need guidance on this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's helpful to have since we can have multiple files (maybe in a folder) for a single component.
Take for instance a SB page, which has its written guidance in a .mdx file and code examples in its .stories.tsx file. And some even have examples.tsx files that abstract logic being used — knowing where specifically to direct a learner would be helpful imo.


## Abbreviations and Acronyms

- Spell out on first use: "Web Content Accessibility Guidelines (WCAG)"
- Use abbreviations for common terms: HTML, CSS, API, UI, UX
- Avoid uncommon abbreviations without definition
Comment on lines +54 to +55
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be more clear with something like, "common to the domain of web design and development." If I'm writing in other contexts, I would probably initialize API, UI, and UX, for instance.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Use abbreviations for common terms in the domain of web design and development:"
=> Makes sense to me!


## Capitalization

- Sentence case for all headings, buttons, and UI text
Copy link
Contributor

@uxemilylee uxemilylee Nov 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like we need to make all the headings in the writing guidelines section conform to sentence case...

Also a couple of copy editing items:
Language and Grammer => Language and grammar
Refencing Code => Referencing code

- PascalCase for component names: `MyComponent`, `ButtonGroup`
- camelCase for props and variables: `onClick`, `backgroundColor`
- Capitalize proper nouns: Codecademy, Storybook, Figma, GitHub
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Love the succinctness and clarity of the sections!

85 changes: 85 additions & 0 deletions packages/styleguide/src/lib/Meta/Style Guide/Linking.mdx
Original file line number Diff line number Diff line change
@@ -0,0 +1,85 @@
import { Meta } from '@storybook/blocks';

import { AboutHeader, Callout } from '~styleguide/blocks';

export const parameters = {
id: 'Linking',
title: 'Linking',
subtitle: 'Best practices for linking within documentation',
status: 'static',
};

<Meta title="Meta/Gamut Writing Guide/Linking" />

<AboutHeader {...parameters} />

Use links to help users navigate between related components and resources. This guide covers linking within Storybook, to external sites, and writing clear link text.

## Internal Links

Use the `LinkTo` component from ‘~styleguide/blocks' and set the id prop as the story’s id value.

```tsx
import { LinkTo } from '~styleguide/blocks';
<LinkTo id="Meta/Stories">Stories</LinkTo>
<LinkTo id="Atoms/Animations/About">Animation</LinkTo>
```

### Guidelines:

- Link text describes the destination, not the action: "See the [Stories page](#)" not "[See the Stories page](#)"
- Use descriptive link text that makes sense out of context: "[Stories page](#)" not "[Click here](#)"
- Link component names to their documentation
- Verify that the link works correctly

## External Links

### Markdown Links:

You can use Markdown for external links, the examples below will open in a new tab:

```markdown
[GitHub Repository](https://github.com/Codecademy/gamut)
[React Documentation](https://react.dev)
```

### Anchor Component:

If you need more control over the link, you can use the Anchor component,the example below will open in the current tab:

```tsx
<Anchor href="https://github.com/Codecademy/gamut">Gamut Repository</Anchor>
```

<Callout text='If you need external links to open in new tabs, use `target="_blank" rel="noreferrer"` together for security. However, avoid forcing this behavior unless necessary—users can choose to open links in new tabs themselves.' />

### URL Guidelines:

- Use full URLs for external resources
- Link to official documentation when referencing tools

## MDX file parameters

For a component's `.mdx` file, add the following to the `parameters` object. Use the `main` branch for the `githubLink`.

```tsx
source: {
repo: 'gamut',
githubLink: 'https://github.com/Codecademy/gamut/blob/main/packages/gamut/src/Button'
}
```

```tsx
design: {
type: 'figma',
url: 'https://www.figma.com/file/ReGfRNillGABAj5SlITalN/%F0%9F%93%90-Gamut?node-id=993-0'
}

```
Comment on lines +61 to +78
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was very confused about this section on first read because it's not about links. I realized part way through that it's about Storybook, not MDX or links.

I'm also not too sure if we want this in our writing docs. It's more of a Gamut Storybook convention, which would be better to capture in code. For instance, maybe we could just make it required in the typing?

interface GamutParameters extends Meta['parameters'] {
  source: GamutSourceCode;
  design: GamutDesignFile;
}


## Link Text Guidelines

- 2-3 words minimum for easy clicking
- Unique link text when multiple links on page
- Meaningful and descriptive: conveys destination
- Action-oriented when appropriate: "View the component"
Comment on lines +80 to +85
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why's this section separate from the first Guidelines section?

Loading
Loading