English Vocabulary for Storybook Developers

Storybook has become the industry standard for developing and documenting UI components in isolation. If you work with Storybook and collaborate with designers, product managers, or engineers in English, you need vocabulary to describe stories, document components effectively, and participate in design system discussions.

Key Vocabulary

Story A story in Storybook is a single, named example of a component in a specific state. Each story renders the component with a particular set of props and represents one use case or variation. Example: “I’ve written three stories for the Button component: primary, secondary, and disabled states.”

Controls Controls are the interactive panel in the Storybook interface that allow users to dynamically change a component’s props without editing code. They make it easy to explore a component’s behaviour and edge cases. Example: “You can use the controls panel to toggle between light and dark mode and see how the component responds.”

Decorator A decorator in Storybook is a wrapper component that adds context or styling to a story. Common decorators provide theme providers, router context, or layout wrappers. Example: “We added a ThemeProvider decorator to all our stories so they always render with the correct design tokens.”

Args Args (short for arguments) are the props passed to a component in a story. In the Component Story Format (CSF), args are defined at the story level and can be overridden by controls. Example: “The default args for this story set the label to ‘Submit’ and the variant to ‘primary’.”

Design system A design system is a collection of reusable UI components, design tokens, guidelines, and documentation that teams use to build consistent user interfaces. Storybook is commonly used as the living documentation for a design system. Example: “Our Storybook instance serves as the single source of truth for our design system — every component is documented there with usage guidelines and examples.”

Common Scenarios Where This Language Is Used

In a design review meeting: Storybook is often used as a shared reference during design reviews. “Can you pull up the Storybook for the Card component? I want to check whether we have a story for the loading state — the design calls for a skeleton placeholder.”

When writing component documentation: Good component documentation in Storybook includes a description of the component’s purpose, guidance on when to use it, and a breakdown of its props. “The Tooltip component should be used for short explanatory text that supplements a UI element. Avoid using it for critical information that users must see.”

In a pull request review: “I can see you’ve added a new story for the error state — nice. Could you also add a story for the case where the error message is very long? I want to make sure the layout handles text overflow gracefully.”

When onboarding designers: “Our Storybook is available at design.example.com. You can browse all our components, see their different states, and use the controls panel to experiment with different prop values. If a component is missing a state you need, raise it with the frontend team.”

Useful Phrases for Storybook Discussions

• “Let me check the Storybook to see what variants we already have for this component.”
• “I’ve written stories for the happy path, the error state, and the empty state.”
• “The controls panel lets you change the label and colour without touching the code.”
• “We use Chromatic to catch visual regressions — it compares stories against a baseline on every pull request.”
• “The component is documented in Storybook with usage guidelines and a prop table.”
• “We use decorators to provide the theme context that all our components expect.”
• “This story is marked as deprecated because we are replacing this component in the next design system release.”
• “The args for this story can be used as starting defaults for the controls.”
• “Our Storybook is the source of truth for the design system — always check there before building a new component.”
• “Can you add a story that demonstrates how this component looks in a right-to-left layout?”

Writing Component Documentation in Storybook

The docs page in Storybook auto-generates documentation from JSDoc comments and prop types. Writing good documentation comments is an English writing skill as much as a technical one.

A good component description answers: what is this component for, when should you use it, and are there cases where you should not use it? “The Alert component displays a prominent message to the user. Use it for important status information, warnings, or errors. Do not use it for general page content or decorative purposes.”

For prop descriptions, be precise about the type and the effect: “Sets the visual style of the alert. Use success for positive outcomes, warning for caution, and error for failures.”

Practice Suggestion

Open the Storybook for any open-source design system — Material UI, Chakra UI, or the UK Government Design System all have public Storybooks. Pick one component and read its documentation carefully. Then write a 150-word description of the component in your own English words, covering its purpose, when to use it, and what its most important props do. Compare your description with the original to see what you missed or could express more clearly.