Structuring Storybook stories for visual states

WHAT THIS TESTS This checks whether you treat stories as living documentation rather than a sandbox. The interviewer wants each visual state to be independently discoverable, reproducible, and testable without manual fiddling.

A GOOD ANSWER COVERS Use Component Story Format with a default export defining the component and meta, then one named export per state: Default, Disabled, Loading, Error, Empty. Each story sets explicit args so it renders deterministically the moment it loads. Define argTypes so reviewers can tweak props live through controls. For interactive states like focus, hover, or open, add a play function that drives the component via testing-library interactions so the state is captured and asserted. A matrix or grid story rendering all variants side by side helps designers scan combinations quickly. Group related stories with sort metadata and add MDX docs pages to explain intent.

COMMON WRONG ANSWERS Putting every state into a single story controlled by knobs or a local toggle, which hides states from the sidebar and breaks visual regression snapshots. Hardcoding state inside the component instead of driving it through args. Forgetting accessibility states or error boundaries entirely.

LIKELY FOLLOW-UPS How do these stories feed visual regression tools like Chromatic. How do you document async loading without flaky snapshots. How do you avoid story duplication across similar components using shared args or story composition.

ONE CONCRETE EXAMPLE For a Button, export Default, Disabled with args disabled true, and Loading with args loading true. The Loading story mocks the spinner deterministically. A Playground story exposes all argTypes for manual exploration, while a States grid renders all variants in one frame for Chromatic to snapshot in a single diff.