Context: I'm a web professional with 20+ years in front-end, back-end, SEO, branding, content strategy and design. I've been using Claude (Opus 4.6 specifically) to build a complete website rebuild — design system, component library, page prototypes — without Figma. This is what I've learned about making it work well.
You don't need one magic prompt. You need a system — a set of documents that accumulate decisions over time, which Claude reads at the start of every session. The prompt that kicks off the design system is important, but the documents that constrain it afterwards are what make it actually work.
This is your first conversation. You're establishing the design language. Here's a template — adapt it to your project:
I'm building a design system for [project name] — [one sentence about what the project is].
The audience is [describe]. The brand personality is [describe — e.g. clinical and authoritative but not cold, premium but accessible].
Brand colours: [list hex values]
Fonts I want to use: [list, or say "recommend something"]
Build me a design system foundation as a single HTML/CSS file that includes:
- CSS custom properties for all tokens (colours, typography, spacing, grid, borders, shadows)
- A type scale with display, heading, body, and mono styles
- Button components (primary gradient, secondary outline)
- Section label / eyebrow pattern
- A responsive grid (max-width, gutters)
- A sample hero section demonstrating the system
- A sample card grid demonstrating the system
Design constraints:
- Light mode default with dark mode support via data-theme attribute
- No all-caps headings
- [Any other rules — e.g. "no rounded corners over 12px", "always use 1px borders at 0.12 opacity"]
Build this as production-quality HTML/CSS. This is not a wireframe — it should look finished.
Why this works: You're giving Claude the domain (brand, audience), the deliverable (a working file with specific components), and constraints (the rules that define taste). Claude is very good at executing within constraints. It's bad at inventing taste from nothing.
Key principle: If you have design opinions, state them. "I want a 1px-gap grid pattern between cards" is better than "make the cards look nice." The more specific your constraints, the more distinctive the output.
After the first session, you'll have a working design system. Now you need three documents that you maintain alongside the code:
Every design decision goes here. Every bug fix that establishes a pattern goes here. This is the single source of truth.
## Typography
- Display: Outfit 700, gradient text on key words
- Body: DM Sans 300-500
- Mono/eyebrow: JetBrains Mono 400-500, 11px, letter-spacing 3px, uppercase
- No all-caps headings
## Grid
- Max width: 1200px
- Gutter: clamp(20px, 4vw, 60px)
## Components
- 1px-gap grid pattern for all multi-column components
- Border opacity: 0.12 default, 0.18 on hover
- Cards use var(--surface) white backgrounds, not var(--bg) grey
## Approved Decisions Log
| Decision | Date | Notes |
|----------|------|-------|
| Phosphor Icons (not Lucide) | 2 Mar 2026 | Regular weight default |
| Hero: 100vh, photo behind nav | 9 Mar 2026 | All photo hero pages |What's built, what's not, what's broken. Page status table, known gaps, data that's been confirmed vs pending.
What's next. Build order. Dependencies.
At the start of every new conversation, tell Claude to read all three files. This is the single most important thing. Without it, Claude starts fresh and drifts from your system within 2-3 iterations.
At the end of every work block, update all three files. If you don't, decisions evaporate between sessions.
Once the design system exists, each new page follows a pattern:
Read PROJECT-RULES.md, CURRENT-STATE.md, and ROADMAP.md first.
Then read [most recent completed page file] as a pattern reference,
and [shared CSS file] for the component library.
We're building [page name]. It's a [describe the page's role in the site hierarchy].
Build this as a [framework template file — e.g. .njk, .tsx, .astro]
with its own page-specific CSS file.
Start with a content outline for my review before building.
The "content outline first" rule is critical. Claude will build a full page if you let it, and you'll spend more time fixing wrong content than you saved. A 2-minute outline review prevents an hour of corrections.
Best for:
- Design system creation and iteration
- Page prototype builds (HTML/CSS)
- Content writing and copy
- Design decisions and architectural planning
- Reviewing screenshots and giving feedback
- Research (structured data rules, SEO patterns, etc.)
Why: The chat interface lets you upload screenshots, have a back-and-forth conversation, and iterate visually. Design work is fundamentally conversational.
Best for:
- CMS integration (Payload, Sanity, Strapi, etc.)
- Build tooling setup (Eleventy, Next.js, Astro config)
- Large file refactoring (renaming CSS classes across 20 files)
- Git operations
- Database schema work
- Deployment scripts
- Any task where you'd normally be in a terminal
Why: Claude Code is better at multi-file operations, running commands, and pure logic tasks. It's worse at design taste — it tends to make conservative, safe choices. Use Claude chat for the creative direction, Claude Code for the implementation plumbing.
This is how the two tools work together:
- Claude chat: Design the component, agree the HTML/CSS, iterate on screenshots
- Claude Code: Integrate it into the build system, wire up the templating, extract shared components
- Claude chat: Review the result, catch visual regressions, plan the next page
Lets Claude chat read and write files directly on your machine. Without this, you're copy-pasting code back and forth. With it, Claude writes directly to your project directory.
Setup: Install via Claude Desktop settings. Point it at your project directory.
Lets Claude interact with your browser — read computed CSS values, check what's actually rendering vs what should be rendering. Invaluable when a style isn't applying and you can't figure out why.
If you're working with a designer or need Figma as an artefact, this lets Claude read Figma files and generate code from them. I skipped Figma entirely because Claude outputs HTML/CSS directly, but if your team requires Figma deliverables, it's worth connecting.
If you're rebuilding an existing site, connecting GA4 lets Claude analyse your traffic patterns, identify high-value pages, and make data-informed decisions about migration priority.
Use Opus for design work. The quality difference between Opus and Sonnet for visual/aesthetic decisions is significant. Sonnet will follow your rules but makes conservative choices and introduces subtle inconsistencies. Opus maintains design coherence across long sessions.
Use Sonnet for mechanical tasks — bulk content migration, repetitive template generation, data formatting. It's faster and cheaper for work that doesn't require taste.
If you accidentally prompt with the wrong model and get poor results, don't iterate — switch models and start the task fresh. Trying to fix Sonnet's design output in the same conversation rarely works well.
Fix: State explicitly in your rules: "Do not add features or content that is not requested. Propose new content FIRST before adding." Claude is eager to help and will embellish if you don't constrain it.
Fix: The project rules file. Every decision documented. Every session starts by reading it. Also: extract shared components into a single CSS file early. If a component is used on 2+ pages, it goes in the shared file — not duplicated in page-specific CSS.
3. "The monolithic file problem" — Claude builds one giant HTML file instead of using your template system
Fix: State it as a hard rule: "Every new page must be built in the [framework] template system. Never as a standalone monolithic HTML file." We learned this the hard way.
Fix: Check the model before starting design work. If Sonnet has already made changes, it's often faster to revert and rebuild with Opus than to fix Sonnet's output.
Fix: The three-document system (PROJECT-RULES, CURRENT-STATE, ROADMAP). Update after every work block. Claude's project knowledge feature helps, but the markdown files are the real source of truth.
Claude doesn't replace design skill. If you don't know what good typography looks like, Claude won't save you — it'll give you something competent but generic. What Claude does is multiply your existing taste by removing the execution bottleneck. If you know what you want but building it would take days, Claude gets you there in hours.
The human's job is: brand direction, quality control, content accuracy, and saying "no, that's not right" when Claude drifts. Claude's job is: execution at speed, maintaining consistency across dozens of files, and remembering every rule you've agreed on (as long as you wrote it down).
The real unlock is not the first prompt. It's the accumulated context — months of documented decisions, patterns, and constraints that make each new page faster and more consistent than the last.