Structuring docs for multiple audiences

WHAT THIS TESTS: This evaluates whether you understand that a design system serves multiple roles and that documentation must address each without fragmenting into disconnected silos.

A GOOD ANSWER COVERS: Structure the documentation around shared foundations and per-component pages, then layer content by audience within them. Foundations cover design tokens, color, typography, spacing, iconography, and accessibility principles that everyone references. Each component page then serves several audiences: developers need the API and props, installation and import instructions, live code examples, and integration notes; designers need usage guidelines, when to use which variant, do and do not examples, content and layout guidance, and links to the design library; product managers and stakeholders need higher-level material like design principles, the component inventory and coverage, accessibility commitments, and roadmap or status. Keep getting-started and contribution guides for onboarding. Use interactive examples pulled from Storybook so documentation stays in sync with the real components. The goal is one coherent site where each audience can quickly find the depth they need without wading through irrelevant detail.

COMMON WRONG ANSWERS: Producing a single developer-focused API reference and assuming designers and PMs will manage. Splitting into entirely separate, disconnected sites that drift apart. Omitting foundations and accessibility. Static screenshots that fall out of date instead of live examples. No getting-started or contribution path.

LIKELY FOLLOW-UPS: How do you keep docs in sync with code automatically. What belongs in usage guidelines versus API docs. How do you measure whether documentation is actually helping adoption.

ONE CONCRETE EXAMPLE: A Button page leads with a live interactive demo, then tabs or sections for usage guidelines and do and do not for designers, a props table and code snippets for developers, and a short rationale and status note for PMs, all built on shared token and accessibility foundations.