# Use Real Website Examples Inside Windsurf [Open the live Fudge conversation](https://design.withfudge.com/share/real-website-examples-inside-windsurf) Last updated: 2026-08-25 You can use real website examples inside Windsurf by converting each reference into a short, concrete design brief. Instead of asking Windsurf to imitate a page, tell it what to inspect, what your product needs to communicate, and which decisions must remain original. ## Choose references for a reason Start with two to four examples that help answer a specific design question. One reference may clarify developer positioning, another may show a compact integration workflow, and another may demonstrate how technical information is grouped. Avoid collecting examples simply because they look attractive. For each one, record: - The visitor, page purpose, and likely next action - The order of the major sections - The relationship between headline, supporting copy, and product preview - Font family, type scale, weight, and line spacing - Background, text, border, link, and action colors - Button, card, input, tab, and code-block styles - Spacing inside components and between sections - What appears to stack, scroll, collapse, or disappear on small screens - Any visible interaction that supports understanding or completion Fudge lets you search captured public references or saved references by description and observed design details. It can inspect captured page structure, typography, colors, spacing, component styling, images, motion, and interactions. If you use Fudge through its MCP server, Windsurf can work from those observations instead of relying on a screenshot or a vague style request. Compare the examples below as developer-oriented references. They are prompts for discussion, not templates to reproduce. ## Captured pages [![Notion Developer Platform](https://pin.fontofweb.com/9283?format=jpg)](https://design.withfudge.com/share/pin-9283) [Notion Developer Platform](https://design.withfudge.com/share/pin-9283) [![Claude Code](https://pin.fontofweb.com/1446?format=jpg)](https://design.withfudge.com/share/pin-1446) [Claude Code](https://design.withfudge.com/share/pin-1446) [![Exa MCP Server](https://pin.fontofweb.com/6429?format=jpg)](https://design.withfudge.com/share/pin-6429) [Exa MCP Server](https://design.withfudge.com/share/pin-6429) ## Give Windsurf a comparison brief A useful prompt distinguishes observations, requirements, and output. Use this structure: 1. **Goal:** state who the page serves, what problem it addresses, and the main action. 2. **Reference evidence:** describe visible hierarchy, typography, color roles, spacing, components, and responsive behavior. 3. **Keep original:** specify your wording, brand, product content, accessibility needs, and technical constraints. 4. **Build request:** ask for components, states, responsive rules, and an implementation order. For example: > Build an original landing page for a developer integration product. Study the references for clear technical hierarchy, focused actions, and compact product explanation. Do not copy their branding, wording, illustrations, distinctive shapes, or exact layouts. Create responsive navigation, a concise hero, an integration preview, three practical benefits, setup guidance, and a clear primary action. Keep keyboard navigation, readable contrast, mobile layout, and the existing application in mind. Explain the decisions before writing the components. This is more actionable than “make it feel like a polished developer site.” If the references conflict, ask Windsurf to choose based on your visitor's next step rather than visual novelty. ## Compare what changes the implementation Before coding, answer these questions in plain language: - Can a visitor identify the main action quickly? - Is the page spacious, compact, editorial, or documentation-led? - Does the typography create a technical, human, or product-focused tone? - Which colors establish hierarchy, and which are decorative? - Do buttons, cards, inputs, navigation, and code areas follow shared rules? - Does spacing create clear section boundaries? - What makes the product concrete: a preview, example, setup step, or technical detail? - What must happen on a narrow screen? “The main action uses the strongest contrast near the headline” is useful. “Make the CTA pop” is not. “The card grid becomes one column below the mobile breakpoint” is useful. “Make it responsive” is not. ## Review the result before shipping Ask Windsurf to state which observations it used and why. Then check the implementation against your product goal. Remove details that were copied too closely or added without a clear purpose. Confirm that the wording represents your product, the main action is easy to find, headings and controls remain readable, focus states are visible, and narrow screens do not simply squeeze the desktop layout. Review the visitor path before decorative polish. A clear headline, understandable setup action, and usable product preview matter more than an impressive effect. Ask for a short list of remaining risks and fix issues affecting understanding, access, or completion first. ## Use this in your AI agent > Use Fudge to inspect the supplied website references for my Windsurf project. Describe only observable hierarchy, typography, colors, spacing, components, responsive behavior, and interaction cues. Then create an original implementation brief tied to my product goal. Do not copy branding, wording, illustrations, or exact layouts. Return components, responsive rules, accessibility checks, and a prioritized build plan. > > [Use Fudge with your AI agent](/mcp) --- Use four labeled parts: project goal, reference observations, originality constraints, and build request. Start with the visitor, problem, and main action. For each reference, describe visible decisions such as section order, type contrast, action placement, color roles, spacing, and mobile behavior. Then state that your wording, brand, imagery, product details, accessibility rules, and responsive requirements must come from your project. Finish by asking Windsurf for components, states, responsive rules, accessibility checks, and an implementation order. Ask it to explain why each selected pattern supports the product goal. If references disagree, tell it to choose based on the visitor's next step rather than which screenshot appears more impressive. --- Review the result in five passes. First, follow the visitor path: can someone understand the page and find the next action without extra explanation? Second, compare it with your notes and remove details that imitate a reference too closely or do not serve your product. Third, check consistency. Headings, body text, buttons, cards, borders, and spacing should feel like one system. Fourth, test narrow screens and keyboard navigation for clipped headings, overflowing code, hidden actions, weak focus states, and difficult controls. Finally, check the message and implementation together. The wording should be yours, the page should show your product, and important technical details should be easy to scan. Ask Windsurf for remaining risks, then fix issues affecting understanding, access, or the main action before polishing decorative details. ## Related questions - [Website design feedback MCP for Claude Code](/share/website-design-feedback-mcp-for-claude-code) - [Use real website examples inside GitHub Copilot](/share/real-website-examples-inside-github-copilot) - [Use real website examples inside Gemini CLI](/share/real-website-examples-inside-gemini-cli) - [Use website design references inside Cline](/share/real-website-examples-inside-cline)