Claude AI Design: Blog-Redesign mit einem Satz Prompt
3 Designs, 1 Prompt – wie Tailwind-Constraints KI-Design konkret machen
Ich bin Entwickler, kein Designer. devmaker.net hatte einen soliden Stack – Wagtail, Tailwind CSS, DaisyUI – aber das Design war das, was dabei rauskommt wenn ein Backend-Entwickler DaisyUI-Defaults nimmt und hofft dass es gut genug aussieht. Es war funktional. Es war nicht schlecht. Aber es war auch nicht meins.
Die Frage war: Wie kommt man als Solo-Entwickler ohne Grafik-Background zu einem professionellen, charaktervollen Design – ohne Figma zu lernen, ohne einen Freelance-Designer zu bezahlen, ohne wochenlang rumzuprobieren?
Die Antwort war überraschend kurz.
Das Tool: claude.ai/design
claude.ai/design ist Anthropics Design-Tool, direkt in claude.ai integriert. Der entscheidende Unterschied zu anderen KI-Design-Tools: Es kann mit echten Projektdateien arbeiten. Statt einer Textbeschreibung gibst du deine bestehenden Templates, deine CSS-Konfiguration, dein Component-System mit. Das Tool versteht dann was du schon hast – und arbeitet damit statt dagegen.
Für mich bedeutete das: Tailwind-Config, DaisyUI-Setup und meine bestehenden Django/Wagtail-Templates hochladen. Die KI weiß danach welche Klassen verfügbar sind, welche Komponenten existieren, und in welchem Kontext das Design landen muss.
Der Prompt
Das war mein kompletter initialer Prompt:
verbessere diesen tech blog. er nutzt tailwind css mit daisyui
Ein Satz. Kein Moodboard. Keine Farbpalette. Kein Referenz-Screenshot. Dazu hab ich die Template-Files und das Design-System hochgeladen – die eigentliche Arbeit steckte in diesen Constraints, nicht im Prompt.
Die drei Rückfragen
Statt sofort loszulegen hat Claude Design nachgefragt. Drei gezielte Fragen:
- Hi-Fi oder Lo-Fi Design? → Hi-Fi
- Interaktiver Prototype? → Ja
- Theme-Präferenz? → (Auswahl aus Vorschlägen)
Das ist der Moment wo das Tool zeigt dass es professionell arbeitet: Es fragt was es braucht, statt Annahmen zu halluzinieren. Ein Lo-Fi-Wireframe und ein ausgearbeitetes Hi-Fi-Design sind komplett unterschiedliche Deliverables – die Frage macht Sinn.
Drei Designs, eine Entscheidung
Claude hat drei vollständig ausgearbeitete Hi-Fi-Konzepte präsentiert – alle auf Basis meiner bestehenden Tailwind-Komponenten und DaisyUI-Klassen:
- V1 · Terminal Editorial – Editorial-Layout mit CLI-Motiven, Code-Snippets als Hero-Element, Serif-Typografie für Deks. Dark, technisch, charaktervoll.
- V2 · Mission Control – Dashboard-Ästhetik, dichte Tabellen, Status-Pills, System-Sidebar. Mehr App als Blog.
- V3 · Magazine Stack – Indie-Zine-Style, große Serif-Display-Schrift, nummerierte Artikel, Drop Caps. Editorial, aber anders.
Kein Generic-Bootstrap-Output. Keine austauschbaren Layouts. Drei echte Design-Richtungen mit klarer Identität.
Warum Terminal Editorial?
Terminal Editorial hat gewonnen weil es am stärksten zu meinem Blog passt: Es fühlt sich an wie ein Tech-Blog von jemandem der tatsächlich im Terminal lebt. CLI-Prompts als Navigation, cat featured/ als Kicker, ./read --post als CTA-Button – das ist keine Dekoration, das ist Identität.
V2 (Mission Control) wäre interessant für ein Monitoring-Dashboard, aber zu APP-artig für einen Blog. V3 (Magazine Stack) war visuell stark, aber der Indie-Zine-Style passt nicht zum pragmatischen, direkten Ton von devmaker.net.
Von Design zu Code: Claude Code übernimmt
Hier wird der Workflow komplett: Das fertige Design aus claude.ai/design wurde direkt an Claude Code übergeben. Claude Code hat die bestehenden Wagtail-Templates angepasst, Tailwind-Klassen korrekt eingesetzt – keine neuen erfunden – und DaisyUI-Komponenten beibehalten.
Was mich überrascht hat: Die generierten Templates waren sauber. Kein Copy-Paste-CSS-Chaos, keine Inline-Styles, keine Klassen-Explosion. Zum Vergleich – so sah die ursprüngliche Homepage aus:
{# Vorher: Standard Swiper-Carousel + Grid #}
<section class="mb-12">
<div class="swiper w-full p-0 shadow-md hover:shadow-xl">
<div class="swiper-wrapper p-0 m-0">
{% for article in page.get_latest_3_articles %}
{% article_carousel_cards article %}
{% endfor %}
</div>
<div class="swiper-button-prev"></div>
<div class="swiper-button-next"></div>
</div>
</section>
<div class="grid grid-cols-1 md:grid-cols-2 xl:grid-cols-2 gap-8">
{% for article in page.get_latest_articles %}
{% article_cards article %}
{% endfor %}
</div>
Danach – das Terminal-Editorial-Hero mit CLI-Kicker und Code-Frame:
{# Nachher: Terminal Editorial Hero #}
<section class="hero-grid px-4 sm:px-6 lg:px-10 pt-10 sm:pt-14 pb-10">
<div class="hero-head min-w-0" data-cat="{{ hero.category.slug }}">
{# CLI-Kicker: cat featured/slug.md #}
<div class="kicker-prompt mb-4 flex items-center gap-2.5 flex-wrap">
<span>cat featured/</span>
<span class="text-base-content break-all">{{ hero.slug }}.md</span>
<span class="cursor"></span>
</div>
<h1 class="display-title text-[clamp(2.25rem,4vw,3.5rem)]">
<a href="{{ hero.get_absolute_url }}" class="hover:text-primary transition-colors">
{{ hero.title }}
</a>
</h1>
</div>
{# CTA im Terminal-Stil #}
<a href="{{ hero.get_absolute_url }}"
class="btn btn-primary rounded-md font-mono normal-case h-auto py-2.5">
./read --post {{ hero.slug }}
</a>
{# Code-Frame als Fallback wenn kein Hero-Bild #}
<figure class="code-frame">
<header class="code-frame__bar">
<span class="dot dot--r"></span>
<span class="dot dot--y"></span>
<span class="dot dot--g"></span>
<span class="path">~/{{ hero.slug }}/README.md</span>
</header>
<div class="code-frame__body">
<pre class="m-0"># {{ hero.title }}
{{ hero.dek|truncatewords:18 }}</pre>
</div>
</figure>
</section>
Lessons Learned
- Constraints sind der Schlüssel. Tailwind + DaisyUI als Input mitzugeben hat verhindert dass Claude ins Generische abdriftet. "Mach einen coolen Tech-Blog" ohne Kontext hätte wahrscheinlich ein austauschbares Bootstrap-Ergebnis gegeben. Die bestehenden Files waren der eigentliche Prompt.
- Rückfragen > Halluzinieren. Dass Claude Design nachgefragt hat statt einfach loszulegen hat die Qualität drastisch erhöht. Hi-Fi vs. Lo-Fi ist kein Detail – das ist der Unterschied zwischen einem Wireframe und einem fertigen Design.
- Drei Optionen ist die richtige Anzahl. Nicht zu viele um überwältigt zu werden, nicht zu wenige um eine echte Auswahl zu haben. Jede hatte eine klare Identität.
- Design → Code Handoff funktioniert. Der Übergang von claude.ai/design zu Claude Code war nahtlos. Keine manuellen Übersetzungsschritte, keine Interpretationsverluste.
- Die Qualität der generierten Templates hat mich überrascht. Sauberes HTML, korrekte Tailwind-Klassen, keine Anti-Patterns. Das war nicht "so lala genug um damit anzufangen" – das war direkt verwendbar.
Fazit
claude.ai/design ist kein Magic-Button der aus nichts ein gutes Design macht. Aber wenn du ein bestehendes Design-System mitbringst – Tailwind, DaisyUI, Material UI, whatever – wird es konkret. Der Workflow aus Design-Tool + Coding-Agent ist für Solo-Entwickler ohne Design-Background ein echter Game-Changer.
Das Ergebnis ist diese Seite hier. Und ich hätte das alleine in dieser Qualität nicht hinbekommen.