Documentation for a new Card component
complete component docs, not just an API table.
usage guidance and do/don't, variants, accessibility, code examples, composition.
shipping only a props table with no when-to-use, accessibility, or examples.
What's really being asked
This evaluates whether you understand that documentation drives correct adoption, and that a props table alone leaves developers guessing.
The full answer
Start with an overview: what the Card is for, when to use it, and when to reach for something else, so consumers do not misuse it. Add usage guidance with concrete do and don't examples, showing good and bad patterns visually. Document variants and states such as elevated, outlined, interactive, loading, and disabled, each with a live example. Include an accessibility section covering semantics, focus behavior when the Card is interactive, and labeling expectations. Provide copy-pasteable code examples for common cases, ideally interactive. Cover composition: which subcomponents or slots exist, like header, media, body, and actions, and how to combine them. Document the design specs, the spacing, radius, and color tokens it uses, so design and code stay aligned. Finally, link related components and note responsive behavior. The props table is necessary but is only one section.
The mistakes people make
Providing only a props table. No when-to-use or do-and-don't guidance. Skipping accessibility. No live examples. Ignoring composition and tokens.
What usually comes next
How do you keep docs from drifting from code? What belongs in do versus don't? How do you document interactive versus static Cards differently?
A concrete example
The Card page opens with purpose and when-to-use, shows a do-and-don't pair, lists elevated, outlined, and interactive variants with live demos, includes an accessibility note that interactive Cards need a focusable control and label, offers code snippets, and documents the header, media, body, and actions slots plus the spacing and radius tokens used.
Interview question
Beyond the props table, which documentation section most directly prevents a Card component from being misused?
- a.A list of the contributors who built it
- b.When-to-use guidance with do and don't examplesCorrect
- c.The component's bundle size in kilobytes
- d.The internal git commit history
Why? this is the answer
When-to-use guidance with do and don't examples steers consumers toward correct usage and away from misuse. Contributor lists, commit history, and bundle size, while sometimes useful, do not tell a developer how or when to use the component.
Just read this? Test yourself on what you have been reading.
Read the original → magicpatterns.com
- #documentation
- #components
- #usage-guidance
- #accessibility
- #examples
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on documentation — each one lists the topics its interview covers.
See open roles