Building screens people actually want to use. AI can generate layouts fast — but good interfaces come from knowing what experience you're designing toward, not just what pixels look right.
Don't open with "make a nav bar with a logo on the left." Open with "this feels like a calm, professional tool — minimal color, generous whitespace." Layout follows feel. Specifying pixels first produces generic work.
Build a button. Get it right. Build a card. Get it right. Assemble them. Asking AI to "build the whole page" produces something that technically works but rarely fits your vision — too many decisions made at once to evaluate clearly.
After each generation, run three questions: Does it feel right? (visceral). Is it easy to use? (behavioral). Does it say something worth saying? (reflective). AI doesn't know what level matters most for your project — you do.
Immediate sensory response to color, type, spacing, motion.
"Does it feel right before they do anything?"The pleasure (or friction) of actually using it — clicks, flows, feedback.
"Can they figure it out without thinking?"What the interface says about them or the world after they've used it.
"What does this communicate about who made it?"Best for iterating on components with natural language feedback. Paste your current HTML, describe what's wrong, and get targeted fixes. Excellent at explaining why something looks off and what to change.
Primary — generate & debugGenerates React/Tailwind components from prompts with a live preview. Strong starting point for complex UI patterns — forms, data tables, dashboards. Export clean code and adapt it.
Rapid component generationFull-stack in-browser environment. Good when your UI needs backend logic (forms that submit, data that persists) and you want everything in one place. Generates and runs the project instantly.
Full-stack prototypesYour first debugging stop. Inspect any element, live-edit CSS, see what's actually rendering. Open with F12 or right-click → Inspect. Screenshot the Elements panel and paste it to Claude for targeted fixes.
Inspect & live-editBuild and test isolated components in a sandboxed environment without a local setup. Paste AI-generated HTML/CSS/JS here to verify it works before adding it to your project. Easy to share for feedback.
Isolated component testingDesign-side reference. Use it to establish visual intent — color palette, type scale, spacing — before generating code. Screenshots from Figma give AI a concrete visual target to hit, dramatically improving output quality.
Visual spec & referencePaste this at the top of your first AI message. It anchors every generation to your actual project.
Decide on three things: the dominant color palette (write the hex codes), the typeface family (serif / sans / mono), and the overall density (spacious / packed / in between). Write these into your DID before generating anything. AI will produce wildly inconsistent results across sessions if you don't anchor it.
Start small. Ask for a single card, button, or nav bar. Lead with the experience: "This should feel sturdy and deliberate — not playful. Users should feel confident they're clicking the right thing." Then give the specs: size, colors, behavior.
Paste your DID before the component request in every new sessionOpen the generated HTML directly in a browser. Ask the three questions: Does it feel right? Is it usable? What does it say? Take notes before you prompt again. Don't iterate until you know what specifically isn't working and why.
Take a screenshot of what you see. Paste it into Claude with a specific description: "The button text is too small and looks timid — I want it to feel more decisive. Increase font size to 16px and add 4px letter-spacing." One change per prompt. Don't ask for five things at once.
Before copying code into your project, ask: "Explain what this CSS rule does and why you used it." If you can't explain what's in your own project, you can't debug it when something breaks. AI will often use shorthand or newer properties that aren't universally supported.
Once individual components work, assemble them. Often things that look fine in isolation fight each other at full page scale — margins collapse, colors clash, hierarchy disappears. Send a screenshot of the full page and ask: "What's competing for attention that shouldn't be?"
Before you finish a session, ask Claude to add a CSS comment block at the top of your file documenting the color palette, type scale, and any design decisions. This becomes the next session's DID and ensures consistency even if you switch tools.
Ask: "Add a comment at the top of my CSS summarizing the design system we've built""Make it look like Apple.com" produces generic minimalism that has nothing to do with your project's actual intent. AI anchors to the reference image, not your design goals.
The first result will almost always work technically. It rarely captures the exact experience you want. Accepting it and moving on locks in a baseline that compounds — every subsequent component inherits its visual DNA.
AI will try to make all five changes at once. Some will land, some won't. You won't know which change fixed which problem, and you can't easily undo one without the others.
AI generates for whatever viewport is implied in the prompt. If you don't mention a screen size, you'll often get a desktop layout that breaks completely on mobile — and a lot of MicroArtistry projects run on tablets or embedded displays.
Each generation session produces its own class names and variable definitions. Paste four sessions' outputs into one file and you'll have four competing definitions of --primary-color, duplicate class names, and cascading conflicts no one can untangle.