Sale is final once you download — so every volume has a real extract here, and Vol. 00 is free in full. Use this page to judge tone, structure, and whether the work matches what you need for layouts, UI, decks, and handoff.
You receive print-ready PDFs and offline HTML you can keep. That is why we do not refund after delivery — and why this page exists. Skim one extract or read them all; open Vol. 00 free. If the writing feels careful and specific, you will recognise the same standard in the rest of the course.
The first question is the one nobody asks: what can Claude actually design? The honest answer is narrower than the hype suggests and broader than the scepticism allows. Claude is not a replacement for a designer. It is a collaborator that can render — in HTML, SVG, and well-structured layout — anything you can describe with precision.
The failure mode is vagueness. "Make a nice landing page" produces what any junior with a Bootstrap template would produce. The success mode is editorial instruction: a grid, a type stack, a colour system, a voice. This volume is a primer on how to think about that hand-off.
Across the thirteen volumes you'll see the same pattern repeated: specificity compounds. Every additional constraint you can articulate shifts the output from generic to intentional. The work is in learning what to constrain.
A prompt is a brief. The sooner you accept that, the faster your output improves. Designers spend years learning to write briefs — for agencies, for clients, for their own files — and the skill transfers directly. A prompt has six components, and when one is missing, the model guesses. Its guesses are statistically average. Your job is to remove guesswork.
1. Role. Who is making this? A junior on a first draft produces different work from a senior on a rebrand. Name the maker.
2. Artefact. Not "a website." A marketing site hero section, 1440×900, scroll-to-anchor. Name the thing.
3. Constraints. Grid, type stack, palette, voice. Constraints are generative, not restrictive — they produce the specificity that makes the output feel authored.
4. References. "In the spirit of" a known brand, publication, or era. Don't copy — triangulate.
5. Success criteria. What does "done" look like? If you can't describe it, you won't recognise it when it arrives.
6. Failure modes. The tropes to avoid. Naming them halves the chance they appear.
The second prompt turns the model from a guesser into an executor. The output is not better because the model is better; it is better because the brief is better.
If you fix one thing in your prompts, fix typography. It is the single lever with the highest output-quality return per character of instruction. Models know typefaces. They know weights, widths, tracking, optical sizes. They rarely use that knowledge unless you ask.
The default — the one you must fight — is Inter at 16px with default line-height on a 1200px container. This is not a design. It is the absence of one. Every decision you add replaces an average with an intention.
Name two typefaces, three sizes, and a measure. Every time. "GT Sectra at 48/60/72, measure 66ch." That one line eliminates 80% of the visual anaemia you'd otherwise get. It is absurdly cheap. Do it.
Two faces. Three sizes. One measure. Whenever you find yourself writing "make it look nice," stop, and write those four numbers instead.
Hex codes are a compression artefact from the 1990s. They work, but they hide the thing you actually care about: perceptual brightness. Two hexes with nearly identical numeric values can look wildly different to the eye, and two that look related on screen often collapse into mud when printed.
OKLCH — Lightness, Chroma, Hue — fixes this. You pick a lightness value and the colour looks that bright, across every hue. You hold L constant and rotate H, and you get a palette that feels coherent because it is coherent.
Think of L as "how loud." C as "how saturated." H as "which direction." Claude understands this directly. Ask for oklch(62% 0.14 35) and you'll get the same visual weight as oklch(62% 0.14 240) — just rotated round the wheel.
Grids are misunderstood. Beginners avoid them, thinking they constrain creativity. Veterans over-use them, thinking discipline equals design. Neither is right. A grid is a tuning device — it gives you a repeatable interval so you can decide, deliberately, when to break it.
For Claude, the grid is also the shortest path to coherence. Tell the model "12 columns, 80px gutters, 8px baseline," and every subsequent layout decision it makes will harmonise. Omit that line and every spacing choice becomes a random sample.
The editorial grid. 12 columns, generous gutters, a prominent baseline. For anything that reads like a page.
The product grid. 8px / 4px rhythm, looser columns, often 6 or 8. For apps and dashboards.
The poster grid. 3×3 or 4×4 max, enormous gutters. For moments you want to feel composed rather than efficient.
A slide deck is a short book with a forced pace. That framing — book, not slideshow — changes every decision. Books have covers, chapters, rhythm, and a voice; your deck should too. PowerPoint templates fight you on all four. Claude, given the right brief, gives them back.
The biggest mistake in AI-generated decks is treating every slide the same. A twenty-slide deck needs movements: a cold open, a statement of intent, a middle of evidence, a turn, a close. If every slide has a title-at-top and three-bullets-below, you've made a spreadsheet of text.
The distance between a Figma artboard and something you can click is the distance between a sketch and a film. One implies the other; only the second can be tested. Claude closes that distance dramatically, and the designers who realise it sooner will ship better work sooner.
The mental move is this: stop designing screens, start designing states. A single "onboarding screen" is actually five to twelve states — empty, loading, filled, error, success, conflict. A prototype that covers all of them tells you whether your flow actually holds up. A static screen tells you only whether it looks nice when nothing is happening.
Three screens, four states each, one happy path, one error path. React in a single HTML file. No build step. Claude writes it in one prompt, you tweak three things, you send the URL. Twenty minutes, end to end.
Motion is the most over-used and under-considered layer of interface design. Transitions are sprinkled on at the end, each a quarter-second, each the default ease. The cumulative effect is soup: a soft blur of movement that teaches the eye nothing.
Better: think of motion as punctuation. A fast snap is a full stop. A long ease is a semicolon. A spring is an em-dash. You are telling the user where a sentence ends and another begins. Used that way, motion becomes legible, not decorative.
80ms — state changes inside a single element. Too fast to notice; exactly what you want.
240ms — transitions between related screens or components. The workhorse.
600ms — deliberate, attention-getting transitions. Use rarely, and only with a reason.
Hero moments. Once per page, maybe. An eye-catching entrance for the single most important element. Everywhere else, invisible is the goal — motion you notice is motion that's failing.
A design system is often presented as a library of components. That framing is wrong, and it's why so many systems rot. A design system is a contract — between designers, between designers and engineers, and between today's decisions and tomorrow's. Components are just the surface; the contract is the value.
Claude is unusually good at enforcing contracts. Give it a tokens file and a component spec, and it will keep within them religiously — more religiously than most human teams. The implication is practical: if you're starting a system, start with the contract, not the components. The components write themselves.
Tokens — colour, type, spacing. Pure values. No opinions about where they're used.
Primitives — button, field, card, table. Opinionated but not contextual.
Patterns — onboarding flow, checkout, empty state. Opinionated and contextual.
Every colour, every spacing, every size referenced in a component must resolve to a token. No magic numbers. Claude will follow this to the letter if you tell it to.
Designers often treat export as administrative — the bit after the design work, the bit for someone else. That is a mistake. The format a design lives in shapes what the design can do. A PDF is a manuscript; a PPTX is a teleprompter; an HTML file is an instrument. Knowing which one you're making changes what you make.
PDF — when the content will outlive the conversation. Print, archive, sign-off artefacts, board packs.
PPTX — when someone else needs to edit it without asking you. Sales decks, client-editable briefs.
HTML — when the content is doing something. Prototypes, live dashboards, anything the viewer interacts with.
Canva — when a non-designer will continue the work after you.
There is a difference between revising a design and iterating on one. Revision takes the last output and nudges it. Iteration takes the last output, diagnoses what's wrong, and changes the brief. Most teams plateau because they revise when they should iterate.
With Claude the temptation to revise is enormous — it's so fast to say "make the headline bigger" and see the headline get bigger. But that is dragging the output around by its corners. It does not move the design forward. What moves the design forward is returning to the brief and asking: what's actually wrong here?
This volume names seven iteration patterns — the Diagnosis Loop, the Reference Loop, the Constraint Loop, the Variance Loop, the Subtraction Loop, the Freeze Loop, and the Kill-Your-Darlings Loop. Each has a prompt shape. Each has a failure mode.
You're forcing the model to externalise the critique it would apply anyway, then operating on the critique rather than the design. Two rounds of this usually gets you further than ten rounds of "make it better."
Lucia is a twelve-table trattoria off Brick Lane. The owner, Rossana, wanted a menu that "didn't look like every other restaurant menu." That sentence, without interrogation, is useless. Two hours of conversation converted it into a real brief: mid-century Milanese, single column, serif-only, no photography, prices in small caps at the far right, printed A4 on uncoated stock, reprinted weekly.
The prompts we wrote with Claude took about ninety minutes. The printed version was in Rossana's hand the next afternoon. The case-study chapter walks through all seven prompts, the three dead ends, and the one moment where I ignored Claude's suggestion and was wrong to.
Claude suggested breaking the single-column rule for the wine list — splitting reds and whites into parallel columns. I overruled it, in the name of "consistency." The first night of service, two waiters complained. I rebuilt it Claude's way. Rossana has not changed it since.
Vol. 12 is the working reference. Eighty-six defined terms, a prompt template library, a troubleshooting index, and a twelve-page printable appendix. It is the book you open during the work, not before it. This extract shows five entries from the glossary so you can see the hand.
Baseline grid. The invisible horizontal ruling that all type in a document aligns to. Usually 4px or 8px. When Claude ignores it, your layout feels drifty without your being able to say why.
Contrast ratio. The measurable relationship between two colours. WCAG AA requires 4.5:1 for body text; 3:1 for large text. Violating this is not a stylistic choice; it is inaccessibility.
Leading. The distance between baselines of consecutive lines. For body text, 1.5× the type size is a safe default. Tighter for display; looser for small captions.
Measure. The length of a line of text. Ideal measure: 45-75 characters, inclusive of spaces. Longer and the eye gets lost returning; shorter and it feels like verse.
Optical size. The variant of a typeface designed for a specific use — "Display" for large sizes, "Text" for body. A good face has both. Use the right one.
This is the volume readers report they return to most often. Keep it open next to the work. It's not a book you finish — it's a book you live with.
If these extracts match the standard you want for your own work, continue to pricing or checkout. Checkout confirms you have read the previews and accept non-refundable digital delivery — the same terms we explain up front.
Berta.one is a trading name of Rondanini Publishing Ltd (No. 16548159), UK.