Minimal modernes UI

Minimal modern UI: minimalistische Seiten, die sich fertig anfühlen

Für persönliche Seiten, Portfolios, Landing Pages und Blogs: kleine, inhaltsorientierte Websites, bei denen Zurückhaltung und Detailarbeit den Ton angeben. Nicht für Web-Apps, Produktoberflächen, Dashboards oder Tools; deren Probleme (App-Status, Datendichte, komplexe Formulare) erfordern andere Anleitungen.

Alles hier ist reines HTML, CSS und ein bisschen Vanilla-JS, passt also in jedes Setup oder gar keines. Wo das Projekt bereits ein Build- oder Templating-Setup hat, verwende es; die Prinzipien ändern sich nicht.

Es ist ein Kompass, keine Vorlage: Jede Regel erklärt das Warum und einen Ausgangspunkt, der an das Thema und den Geschmack des Nutzers angepasst werden kann. Mit Firm gekennzeichnete Punkte sind die wenigen, die nicht übersprungen werden sollten.

Unterstützende Dateien (bei Bedarf lesen):

• references/snippets.md: Bausteine zum Kopieren und Einfügen (Token, Basis, Prosa, Beitragsliste, Formulare, Animationen).
• references/interface-checklist.md: Detaillierte Interaktions-, Formular-, Inhalts- und Leistungsprüfungen, angepasst an Vercels Web Interface Guidelines.
• references/ship-checklist.md: SEO, Social Preview, RSS, Analysen, Hosting.
• references/lessons.md: Fallstricke und Tipps zur Browser-Überprüfung aus echten Projekten.
• references/templates.md: Maße aus 10 Carrd-Landingpage-Vorlagen (zitiert nach Carrds Vorlagennummer, z. B. #304). Referenzdaten zur Kalibrierung des Auges, keine Regeln.

1. Arbeitsablauf

1. Verstehe die Aufgabe. Wessen Seite, für wen, die eine Sache, die ein Besucher tun oder lernen soll, die benötigten Seiten und was „fertig" bedeutet. Frage, wenn die Antwort den Build verändert: die endgültige Domain, ob Besucher getrackt werden, wer den Text besitzt und ob es vorhandene Inhalte (Beiträge, Projekte) gibt, die eingebunden werden müssen.
2. Lege die Richtung fest (§2) und schreibe sie auf: Farb-Token, eine Schriftkombination, eine Skala für Abstände und Radien sowie eine Bewegungspersönlichkeit, in den Projektnotizen (CLAUDE.md, AGENTS.md oder README), damit spätere Sitzungen konsistent bleiben.
3. Richte die gemeinsamen Teile ein (§3) vor der ersten Seite: Token, Basisstile, Layout-Primitive, Komponenten und eine Quelle für Header, Footer und <head>. Jede Seite, auch die erste, wird daraus gebaut.
4. Zuerst echten Text. Platzhaltertexte verbergen Layout-Probleme. Befolge das Seitenrezept (§4).
5. Baue statisch, responsive und barrierefrei, füge dann Bewegung hinzu, dann poliere.
6. Veröffentliche (§11), überprüfe im Browser (§12), führe dann den Zurückhaltungs-Pass (§13) durch.
7. Iteriere in kleinen, sichtbaren Schritten. Eine Änderung nach der anderen, betrachte sie, bitte um Geschmacksentscheidungen anstatt zu raten, sage klar, was überprüft wurde und was nicht, und committe oder veröffentliche nur, wenn darum gebeten wird.

2. Wähle eine Richtung

Minimal ist der Standard: Inhalt zuerst, eine Akzentfarbe, großzügige Abstände, feine Linien anstelle von Kästen, dezente Bewegung. Jedes Element sollte Bedeutung tragen; Dekoration, die das nicht tut, wird entfernt.

Familie	Aussehen	Passt tendenziell zu
Ruhig hell	Fast weiß, neutrale Sans, hauchdünne Trennlinien, ein klarer Akzent	Persönliche Seiten, Blogs, Texte
Ruhig dunkel	Fast schwarz, große leichte Schrift, ein Akzent, eine Monospace für Metadaten	Engineering- und persönliche Seiten, Launches
Redaktionell	Serifen für Anzeige oder Fließtext, großzügiges Maß, umrandete Buttons	Lange Texte, Bücher, Kultur; kann bei Tech-Zielgruppen veraltet wirken, also zuerst live zeigen
Sanftes Leuchten	Ruhige Basis plus ein subtiler Verlauf oder radiales Leuchten, optional matte Oberfläche	Landing Pages, die etwas Wärme brauchen
Ein kräftiger Block	Ruhige Basis plus ein randloser Farbblock oder gerahmtes Foto	Portfolios, Events, persönliche Marken

• Ton schlägt Neuheit. Ein ernstes Thema verlangt Ruhe und Glaubwürdigkeit; verspielte Schriftarten und laute Effekte werden dort meist abgelehnt.
• Passe dich den Konventionen des Publikums an. Tech-Zielgruppen erwarten tendenziell eine neutrale Sans auf fast weißem oder fast schwarzem Hintergrund mit einem klaren Akzent; andere Zielgruppen haben ihre eigenen. Wenn du mehrere Richtungen vorschlägst, lass sie sich im Layout und in den Oberflächen unterscheiden (Listenseite, geteiltes sticky Layout, Kartenraster, ein Farbblock), nicht nur in Schrift und Papierfarbe, damit der Nutzer zwischen echten Alternativen wählen kann.
• Wenn der Geschmack unbekannt ist, probiere es live aus. Tausche die Schrift, den Akzent oder die Abstände auf der echten Seite aus und lass den Nutzer reagieren. Erwarte ein paar Runden.
• Der Geschmack des Nutzers hat Vorrang vor diesem Leitfaden. Sobald er eine Richtung annimmt oder ablehnt, schreibe sie in die Projektnotizen und folge ihr gegenüber jeder hier genannten Vorgabe.

3. Gemeinsame Stile und Komponenten

Eine zweite Seite sollte wie die erste aussehen, weil sie aus denselben Teilen gebaut ist, nicht weil Stile kopiert wurden.

• Eine Quelle für Token. Farben, Schriftgrößenskala, Abstände, Radien, Schatten und Bewegungszeiten sind benutzerdefinierte Eigenschaften in einer Datei. Seiten und Komponenten verwenden Token, niemals Rohwerte: ein Hex-Code oder eine einmalige Pixelgröße in den Stilen einer Seite ist ein zu behebender Fehler.
• Gestalte Komponenten, nicht Seiten. .btn, .card, .field, .prose, .post-list, .site-header, nicht .about .blue-box. Varianten sind Modifikatoren (.btn--outline), niemals bearbeitete Kopien. Seitenstile ordnen nur Komponenten an und bleiben kurz.
• Schichte das CSS: Token → Basis → Layout-Primitive → Komponenten → Seitenanordnung, deklariert mit @layer, damit eine Seitenregel nicht stillschweigend eine Komponente überstimmen kann (siehe Snippets).
• Schreibe gemeinsame Chrome einmal. Header, Nav, Footer, <head> und das Site-Skript stammen aus einer Quelle: den Includes, Partials oder Templates des Projekts oder einem kleinen Build-Skript. Handkopierte Header driften auseinander; wenn Kopieren auf einer Zwei-Seiten-Seite unvermeidbar ist, sage dies und überprüfe jede Kopie nach jeder Änderung erneut. Markiere die aktuelle Seite in der Navigation mit aria-current="page".
• Verhalten durch Markup. Ein Site-Skript behandelt Einblendungen und Aufklapp-Elemente über Datenattribute und Klassen, sodass eine neue Seite diese ohne seitenbezogenes JS erhält.
• Führe ein Inventar. Liste die Komponenten in den Projektnotizen auf (Name, Zweck, Varianten). Bei einer neuen Seite zuerst wiederverwenden; alles Neue kommt in die gemeinsamen Dateien und die Liste, nicht in die Seite. Eine styleguide.html, die jede Komponente in jedem Zustand und Thema zeigt, ist eine schnelle Überprüfung nach Änderungen.
• Nur eine Seite heute? Trenne Token und Komponenten trotzdem von den Seitenstilen; die nächste Seite wird dann zur Zusammenstellung.

4. Seitenrezepte

Landing Page

• Hero: eine Überschrift, ein Einleitungssatz, die primäre Aktion (oder das Anmeldeformular selbst) im ersten Viewport.
• Dann Abschnitte, die die Fragen des Besuchers in der Reihenfolge beantworten: Was es ist, wie es funktioniert (nummerierte Schritte plus ein kleines Bild), Beweise (kurze Zitate, Logos, Zahlen, die real sind), FAQ, Footer.
• Wiederhole den Pitch nicht: Wenn der Hero das Formular enthält, fügt ein abschließender Block, der es wiederholt, nichts hinzu.

Persönliche Seite / Portfolio

• Name und eine Zeile darüber, was die Person tut, dann kurze Abschnitte: Arbeit oder Projekte, Schreiben, Über mich, Kontakt.
• Listen mit feinen Linien sind besser als Kartenraster für Projekte und Beiträge; ein gerahmtes Foto reicht als Bildmaterial.
• Kontakt ist ein einfacher Link (E-Mail, Profile), kein Formular, es sei denn, der Nutzer wünscht eines.

Blog-Index

• Eine Liste, keine Karten: Titel, Datum (<time datetime>), optional eine einzeilige Zusammenfassung. Gruppiere nach Jahr, sobald es viele Beiträge gibt. Die gesamte Zeile ist der Link, ohne tote Zonen.
• Keine Standard-Thumbnails. Paginierung oder eine einzige lange Seite funktionieren beide; sage in den Notizen, welche gewählt wurde.

Blogbeitrag

• Eine Lesespalte von etwa 60–72 Zeichen, Text 17–19px mit Zeilenabstand 1.6–1.75 (§5).
• Titel, Datum und optionale Lesezeit oben; Überschriften mit Ankern und scroll-margin-top; ein Inhaltsverzeichnis nur für lange Beiträge.
• Abbildungen mit Bildunterschriften dürfen breiter als der Text sein; Codeblöcke scrollen in sich selbst, niemals die Seite.
• Ende mit einem nächsten Schritt: vorherige/nächste Beiträge oder eine kurze Liste mit weiteren, plus den RSS-Link.

Gemeinsamkeiten aller Typen

• Header: eine Navigation oder nichts. Ein einzelner einsamer Button gegenüber der Marke wirkt unfertig.
• Footer am unteren Rand, auch auf kurzen Seiten (volle Höhe, Flex-Spalte), ohne stray margin darunter.
• Gestalte jeden Zustand: leer (noch keine Beiträge), sehr lange Titel, fehlende Bilder, eine 404-Seite im Look der Seite.

5. Typografie

• Eine oder zwei Schriftfamilien: ein neutraler Fließtext (ein System-Stack ist in Ordnung) plus höchstens eine Auszeichnungsschrift. Eine Monospace für Daten, Code und Metadaten ist eine dritte Schrift nur, wenn sie es verdient.
• Überschriften wirken modern groß, leicht und eng gesperrt: etwa 40–72px für den Hero, Stärke 300–500, Buchstabenabstand −0,02 bis −0,05em für Neo-Grotesk, Zeilenabstand 1.1–1,25, skaliert mit clamp().
• Abschnittsüberschriften auf einer kurzen Seite (persönliche Seite, Blog-Index): etwa 1,25× Fließtext (≈20px), halbfett, in der Textfarbe. Blasse Großbuchstaben-Beschriftungen sind zu schwach; Auszeichnungsgrößen konkurrieren mit dem Hero.
• Lesetext. 17–19px, Zeilenabstand 1.6–1.75, 60–72ch Maß, Absätze mit etwa 1em Abstand. Sekundärtext verwendet eine gedämpfte Farbe, keine kleinere Größe.
• Ordentliche Zeilen: text-wrap: balance auf Überschriften, text-wrap: pretty auf Absätzen, um einzelne Wörter zu vermeiden.
• Typografische Details: geschweifte Anführungszeichen („"), das Auslassungszeichen (…), ein geschütztes Leerzeichen zwischen Zahl und Einheit (10 MB), tabular-nums für Daten und Zahlen in Listen. Markiere Marken- und Produktnamen mit translate="no", damit die Browser-Übersetzung sie in Ruhe lässt.
• Wortmarke: groß genug, um sich neben Abschnittsüberschriften zu behaupten (oft 1,2–1,6×); ein Gewichtskontrast innerhalb eines Wortes (leicht + extrafett) verleiht günstig Charakter.
• Blocksatz nur mit gesetztem lang und hyphens: auto, und niemals in schmalen Spalten.

6. Farbe und Oberflächen

• Token auf :root: Hintergrund, Oberfläche, Text, gedämpft, eine Haarlinienfarbe, ein Akzent (optional zweiter Verlaufsstopp) und eine auf-Akzent-Farbe.
• Kontrast (Firm). Fließtext mindestens 4.5:1 (WCAG 2) auf der tatsächlichen Oberfläche, überprüft an der hellsten Stelle von transluzenten oder verlaufenden Oberflächen. Leichte Auszeichnungsschrift benötigt mehr. APCA ist eine nützliche Zweitmeinung für dünne Schriften, kein Ersatz. Setze immer Linkfarben; das standardmäßige Blau des Browsers sieht auf fast jedem Design falsch aus.
• Akzent für ein paar kleine Markierungen: ein Wort in einer Überschrift, Links, Hover und Fokus, das aktuelle Navigationselement. Kein großer Farbblock und keine Nummerierung von Listen.
• Oberflächen: Standardmäßig flach mit feinen Linien. Schatten, wenn verwendet, haben zwei Ebenen (weich, ambient plus einen engeren, direkten); Ränder können halbtransparent sein, sodass Kanten auf jedem Hintergrund scharf bleiben. Innere Radien sind niemals größer als die ihres Containers. Auf einem farbigen Hintergrund töne Ränder und Schatten in Richtung seines Farbtons.
• Hover und Fokus erhöhen den Kontrast gegenüber dem Ruhezustand.
• Hell, dunkel oder beides. Entscheide früh. Ein festes Schema ist in Ordnung: setze color-scheme und theme-color entsprechend. Für beide, definiere dieselben Token unter prefers-color-scheme: dark neu (plus einen [data-theme]-Override, wenn es einen Umschalter gibt) und überprüfe Kontrast, Schatten, Bilder und Codeblöcke in jedem.
• Hintergründe: einfarbig oder ein sanfter Verlauf oder Leuchten; ein Muster nur bei ≤10% Kontrast. Niemals zwei laute Dinge.

7. Bewegung

Bewegung sollte jemandem helfen zu sehen, was sich geändert hat oder wohin er schauen soll. Auf diesen Seiten ist weniger meist besser.

• Standard: ein kurzes Einblenden des Hauptinhalts beim Laden (ein paar Pixel Aufwärtsbewegung) und Hover/Fokus-Feedback. Eine Seite mit nur diesem Effekt ist ein vollständiges, ruhiges Ergebnis.
• Scroll-Enthüllungen sind optional und bleiben subtil: Deckkraft plus 6–20px Bewegung, ease, 0.3–1s, einmal abspielen, wenn etwa 25% sichtbar. Kaskadiere nach Distanz (Überschrift bewegt sich am wenigsten, Buttons am meisten); Staffelung 100–150ms, maximal 6–8 Elemente. Niemals bei langen Lesetexten.
• CSS zuerst, dann die Web Animations API, dann eine JS-Bibliothek nur, wenn wirklich nötig.
• Animiere nur opacity und transform, liste übergehende Eigenschaften explizit auf (niemals transition: all), und setze transform-origin dort, wo die Bewegung physisch beginnt. Für SVG animiere ein <g> mit transform-box: fill-box.
• Unterbrechbar: Übergänge, keine festen Zeitachsen, sodass ein Hover-Out oder ein zweiter Klick reibungslos umkehrt.
• Hover/Fokus: Buttons skalieren etwa 1.02–1.06 oder heben sich an; Nav- und Textlinks erhalten eine 2px Unterstreichung, die von links hereingleitet, auch bei :focus-visible.
• Hintergrundbewegung: höchstens eine langsame Schleife oder keine. Schleifende Medien sind ein stummgeschaltetes <video>, kein GIF, und Bewegung länger als 5 Sekunden benötigt eine Pause-Steuerung.
• Glas-Flackern (Chrome): blende keine Kinder eines backdrop-filter-Elements aus und animiere seine Unschärfe nicht (siehe Lektionen).

8. Interaktionsmuster

• Links sind Links. Navigation verwendet <a>, damit neuer Tab, Link kopieren und Mittelklick funktionieren. Keine toten Zonen: Wenn eine Zeile anklickbar aussieht, ist sie es ganz.
• Formulare (Anmeldung, Kontakt): jedes Feld beschriftet; korrekte type, name, autocomplete und inputmode; Rechtschreibprüfung aus für E-Mails; native Validierung zuerst. Blockiere kein Einfügen oder Tastendrücke, und deaktiviere das Absenden nicht, bevor der Nutzer es versucht. Fehler erscheinen neben dem Feld, sagen, wie das Problem zu beheben ist, und der Fokus bewegt sich beim Absenden zum ersten Fehler. Mehr in der Interface-Checkliste.
• Absenden: der Button behält seine Beschriftung und erhält einen Spinner, der erst nach ~200ms und dann für mindestens ~400ms angezeigt wird, damit schnelle Antworten nicht flackern (siehe Snippets). Erfolg ersetzt das Formular durch einen klaren nächsten Schritt.
• Aufklapp-Elemente (FAQ, „mehr anzeigen"): ein <button aria-expanded aria-controls>, animiert mit dem Grid-Zeilen-Trick, geschlossener Zustand nur, wenn JS läuft.
• Hilfe im Text vor Tooltips. Erkläre zuerst im Text. Wenn ein Tooltip nötig ist, verlasse dich niemals auf title; verwende einen benutzerdefinierten bei Hover und Fokus, mit einer kurzen Verzögerung vor dem ersten und keiner beim Wechsel zwischen benachbarten Elementen.
• Text: sage, was die Seite bietet, in den Worten des Besuchers; Buttons sagen genau, was sie tun („Newsletter abonnieren", nicht „Absenden"); Fehlermeldungen sagen, wie man sich erholen kann.

9. Qualitätsbasis (Firm)

• Reduzierte Bewegung: mit prefers-reduced-motion: reduce erscheinen Enthüllungen sofort und Schleifen und Smooth Scrolling sind aus.
• Ohne JS sicher: versteckt-bis-enthüllte Zustände leben hinter einer .js-Klasse, sodass nichts unsichtbar bleibt, wenn JS fehlschlägt.
• Tastatur und Fokus: ein „Zum Inhalt springen"-Link, logische Überschriftsebenen,

…

[gekürzt zur Übersetzung]