Designing with LADLE.

LADLE's design mode is not a Figma replacement. It's not a whole-website builder. It's the specific tool for producing one gorgeous HTML file — a landing page, a poster, an email, a hero, a component — that renders live, iterates in place, and drops onto your machine as a real .html file when you're done. Used well, it replaces the "draft me a mockup" step for a lot of small design work. Used badly, it produces bootstrap-grade output that isn't worth shipping.

The difference is almost entirely in the prompt.

The one-sentence brief

Design mode's dedicated system prompt tells the model: emit ONE complete HTML document per reply, use one Google Fonts family, mobile-responsive, tasteful defaults, no external dependencies. All of that is baked in. Your job is the brief.

The best briefs are one specific sentence. Not "landing page for a coffee shop" — the model will produce something perfectly generic. Instead:

> "Landing page for Ember & Oak, a specialty coffee shop in Portland. Warm cream palette with a burnt amber accent. Serif display face, humanist sans body. Hero, three features, testimonial, opening hours + address. Understated, editorial, no drop shadows."

Every constraint in that brief is doing work. "Ember & Oak" gives the model a name to build the design around; "Portland" invents plausible ancillary content (the address, the hours); "warm cream palette with a burnt amber accent" collapses the color-decision space; "serif display / humanist sans" collapses type; the section list ("hero, three features, ...") gives the layout scaffolding; "no drop shadows" narrows the visual voice.

Design mode is not a mind reader. Every specification you write is a specification the model doesn't have to guess.

The two-message iteration loop

First message: the brief. You'll get a design.

Second message: three specific changes.

Not "make it better" — that's the folklore trap. Say what to change and why.

> "Two changes: (1) the hero copy is too corporate — soften to 'Coffee made with the patience of people who taste it'; (2) the testimonial section reads bolted-on — cut it, replace with a 'coming soon: December beans' teaser card with a mailing-list signup input."

The model will preserve the parts you didn't ask to change (the design system prompt instructs it to). Repeat with two-to-four changes at a time. Design mode is genuinely good at incremental refinement — better, in many cases, than starting over.

The seven mistakes

**One.** Vague brief. "Nice landing page for my product." You'll get a nice generic landing page for a generic product. Give it a name, a palette, a voice, a section list.

**Two.** Asking for a whole site. Design mode ships one HTML file. If you ask for "the whole marketing site," you'll get a single very long page. Break the work into per-page design chats.

**Three.** Requiring specific external dependencies. Design mode won't include Tailwind, React, D3, or your favorite CSS framework. It ships plain HTML + inline CSS + one Google Font. If you need framework code, use a normal code chat instead.

**Four.** Trying to redesign after you've extensively hand-edited. Once you've made 20 hand-edits, the model no longer has your changes in context (the response was truncated in transit); asking it to "add a testimonial" will lose your edits. Fork instead — start a new chat, paste your current version as the brief.

**Five.** Ignoring the iteration budget. Design turns are the most expensive kind of chat you can send — the model produces 3,000-10,000 output tokens per reply. Twenty design iterations on a single artifact is $2-3 of API cost. That's fine if the design is worth it; be aware.

**Six.** Not naming the voice. "Playful and fun" produces very different output from "considered and quiet" produces very different output from "aggressive and technical." Voice is the axis you have most control over via language, and most people underuse it.

**Seven.** Not naming the target device. "For desktop" and "for mobile" produce different-shaped compositions. If you don't specify, you'll get responsive-mobile-first output that reads fine on both but is optimized for neither.

The device toggle

Every design artifact has a Desktop / Tablet / Phone toggle at the top of the preview panel. Use it. A design that looks great at desktop and awful at 390px is not a shipped design. If the mobile view breaks, tell the model:

> "Mobile view: the hero image overlaps the copy at 390px; increase padding-top on the copy container by 40px and cap the image at 60% viewport height."

Specific fix, specific side, specific number. The model will fix it in one pass.

When it's the right tool

Best cases: landing pages, one-screen posters, transactional email templates, isolated design system components (a hero, a pricing tier, a card), share cards / social image mockups, one-off internal pages.

Not appropriate: multi-page apps (build these normally); designs requiring specific brand libraries; anything you plan to hand to an engineer as a spec (design mode outputs implementation, not spec).

The download-and-edit path

Every design artifact has a Download button in the panel header. It saves the raw .html to your machine. From there you can:

- Open it in a browser to inspect / share via file - Import it into a design tool (Figma has an HTML import; most support raw HTML paste) - Edit it in a text editor and re-paste as a new brief when you want the model to riff on your edits

The download is the escape hatch. Design mode is a fast first pass; your text editor is the second.

The one thing to remember

Design mode is not producing art. It's producing a very good starting point that gets to a shipped design faster than starting from scratch. Treat it that way — brief specifically, iterate incrementally, download when it's close enough — and it earns its cost per reply. Treat it as an "AI designer" and you'll be disappointed by output that is objectively pretty good but not tuned to what you actually needed.

The tuning is on you.