# Documentation Website Design References for Claude Code [Open the live Fudge conversation](https://design.withfudge.com/share/documentation-website-design-references-for-claude-code) Last updated: 2026-08-25 For a Claude Code documentation site, choose references by matching the reader's jobs: find the right page, understand the instructions, copy a working example, and know what to do next. The captured examples below give you three useful comparison points. Study them for decisions you can explain, not for a page to reproduce. ## Start with the reader's route Before choosing a navigation style, define the shortest path from arrival to a successful first result. A documentation site should make it easy to answer four questions: 1. Where should I begin? 2. What do I need before I start? 3. What should I copy or change? 4. What page should I open next? Every reference should be reviewed against those questions. Do not assume that a dense navigation tree is helpful simply because it contains many links. Do not assume that a branded landing page is useful simply because it looks distinctive. Keep a pattern only when it helps a reader find, understand, or apply an instruction. ## Captured pages [![Theming](https://pin.fontofweb.com/5948?format=jpg)](https://design.withfudge.com/share/pin-5948) [Theming](https://design.withfudge.com/share/pin-5948) [![Apple Developer](https://pin.fontofweb.com/1796?format=jpg)](https://design.withfudge.com/share/pin-1796) [Apple Developer](https://design.withfudge.com/share/pin-1796) [![Stripe Dot Dev](https://pin.fontofweb.com/6881?format=jpg)](https://design.withfudge.com/share/pin-6881) [Stripe Dot Dev](https://design.withfudge.com/share/pin-6881) ## Compare the three references **Theming on shadcn/ui** is a useful page to inspect for a focused technical topic. Record how the page introduces its subject, groups related ideas, presents code or configuration, and points the reader toward the next relevant task. **Apple Developer** is useful for studying a broad developer destination. Review how its visible categories, product areas, and supporting resources help a visitor decide where to go. The important question is not whether Claude Code should reproduce its structure, but which wayfinding problems the structure solves. **Stripe Dot Dev** gives you a more focused developer-brand comparison. Study how the page balances recognition with access to technical material. Identify which visual choices support orientation and which would become distractions in a documentation task. For every reference, keep notes in three columns: **observed detail**, **reader problem it may solve**, and **Claude Code decision**. If you cannot state the reader problem, leave the pattern out of the brief. Also mark anything that requires further verification instead of presenting an assumption as a fact. ## Use a practical documentation structure A Claude Code documentation site can begin with a stable shell: a compact header, a section navigation area, a readable content column, and an optional page outline for long documents. On smaller screens, collapse the navigation without losing the reader's current location. Keep the reading width comfortable and give code blocks enough room to remain legible. Organize the main navigation around tasks rather than internal names alone. A useful draft is: - Start here - Install and sign in - Learn the basic workflow - Use commands and tools - Configure projects - Work with teams and permissions - Troubleshoot common problems - Reference Each page should answer one clear question. Put prerequisites near the beginning, show the shortest useful example early, and finish with the next likely task. Keep warnings beside the step they affect. Use page titles and headings that match the words a reader would use when searching for help. For code examples, provide a short explanation before the block, a clear language or command label, and a copy action when appropriate. Explain inputs, expected output, and any step that is easy to skip. A copied command is not enough if the reader cannot tell where it belongs or how to check that it worked. ## Turn references into an implementation brief Write each design decision in observable terms. For example: "The section navigation stays visible on wide screens, collapses on small screens, and preserves the current location when the reader changes pages." Another useful decision is: "Each example explains its purpose before the code and identifies the expected result afterward." Separate borrowed patterns from original decisions. You may borrow a navigation model or code-block treatment while choosing your own type scale, colors, illustrations, and terminology. Include responsive behavior, keyboard access, deep links, search, code copying, and error states in the acceptance checklist. Those are practical parts of a documentation experience, not decoration. Before coding, test the brief with a small task. Ask someone unfamiliar with the proposed structure to find installation, complete one first workflow, and locate the reference page for a specific command. Any hesitation should become a navigation or page-content revision. ## Use this in your AI agent > Compare the captured documentation references for Claude Code, especially Theming on shadcn/ui, Apple Developer, and Stripe Dot Dev. Separate observed details from recommendations. Prioritize navigation, page hierarchy, code examples, search and wayfinding, readable density, responsive behavior, and developer-focused branding. Explain which pattern serves which reader job, then produce an implementation checklist and a task-first navigation draft. Do not invent facts that are not visible in the captured references. [Use Fudge with your AI agent](/mcp) to inspect saved website references and turn verified observations into a focused build brief. --- Use a task-first structure rather than mirroring internal product ownership. Put the shortest route to a successful first result at the top, then separate everyday workflows from detailed reference material. A practical order is: 1. **Start here:** what the guide covers, who it is for, and the first successful workflow. 2. **Install and sign in:** requirements, setup, authentication, and a quick verification step. 3. **Core workflow:** opening a project, describing work, reviewing changes, and continuing a session. 4. **Commands and tools:** grouped by the job a reader wants to complete, with short examples. 5. **Project configuration:** settings, files, permissions, and team conventions. 6. **Troubleshooting:** common problems organized by symptom and observable remedy. 7. **Reference:** complete command, option, and configuration details. Keep the current section visible on desktop and make the mobile menu preserve the reader's place. Add a page outline only when a page is long enough to need it. Each page should show prerequisites, the main action, a working example, and the next recommended page. This gives beginners a clear route while letting experienced users jump directly to commands or reference details. Validate the structure by asking a new reader to find installation and complete one small task without coaching. --- Give Claude Code a brief about decisions, constraints, and checks instead of asking it to imitate a reference. Include the patterns worth studying and the parts that must remain original. Use this starter prompt: > Build a documentation website for Claude Code using a task-first information structure. Include Start here, Install and sign in, Core workflow, Commands and tools, Project configuration, Troubleshooting, and Reference. Use persistent section navigation on wide screens, a compact mobile menu, a readable main content column, page outlines for long documents, and code blocks with clear labels and copy actions. Study the captured Theming on shadcn/ui, Apple Developer, and Stripe Dot Dev references for navigation, hierarchy, code presentation, and developer branding, but do not copy their text, visual identity, or page-specific assets. Make the first successful workflow easy to complete, keep prerequisites near the relevant step, and provide related next actions. Test desktop and mobile navigation, deep links, code copying, keyboard focus, and the route from installation to the first working example. Before accepting the result, compare each choice with the brief's reader jobs. Ask for a revision when a visual detail does not improve finding, reading, or applying the documentation. Also verify every product-specific instruction against current source material before publishing it. ## Related questions - [Documentation Website Examples with Fonts, Colors, and Spacing](/share/documentation-website-examples-with-fonts-colors-and-spacing) - [Developer Tool Homepage Examples: Fonts, Colors, and Spacing](/share/developer-tool-homepage-examples-with-fonts-colors-and-spacing) - [Ecommerce Product Page Design References for Claude Code](/share/ecommerce-product-page-design-references-for-claude-code) - [Developer Tool Homepage Design References for Claude Code](/share/developer-tool-homepage-design-references-for-claude-code)