Motion-Slop: Warum jede KI-Landingpage dasselbe Fade-in-up animiert

Darüber liegt ein zweites Verräterisches: der Stagger, der keiner ist. Wenn die KI doch mal Abwechslung versucht, staggert sie ein Grid mit transition={{ delay: index * 0.1 }}. Jetzt kaskadieren sechs Feature-Cards der Reihe nach herein. Sieht edler aus. Ist schlechter. 100ms Verzögerung pro Element bei sechs Elementen heißt, der Nutzer wartet 600ms auf die letzte Card, und die Kaskade hat keine Bedeutung: Card 6 ist nicht wichtiger als Card 1, warum kommt sie dann später an? Mechanischer Stagger ist Bewegung, die Choreografie cosplayt. Du erkennst es quer durch den Raum, weil der Rhythmus perfekt linear ist: 0, 100, 200, 300. Nichts in gutem Design läuft auf einem perfekt linearen Verzögerungsplan.

Und das Easing. ease-out auf allem. ease-out heißt schneller Start, langsames Ende, richtig für etwas, das *ankommt* und sich setzt. Aber die KI nutzt es auch für Exits, für Hovers, für alles, weil es der sichere Default ist. Echte Bewegung mischt: ease-out für Eingänge, ease-in für Ausgänge, ein eigenes cubic-bezier(0.34, 1.56, 0.64, 1) mit Overshoot für etwas Verspieltes, linear nur für Endlosschleifen. Eine Seite, auf der alles dieselbe Easing-Kurve teilt, hat den Tonumfang einer einzigen Klaviertaste.

So erkennst du es in 30 Sekunden

Öffne die DevTools, geh ins Animations-Panel (Chrome: More Tools → Animations) und scroll. Wenn jede aufgezeichnete Animation dieselbe Dauer, dasselbe Easing und dieselbe Transform-Distanz teilt, schaust du auf eine generierte Seite. Oder lies den Quelltext: durchsuch das Bundle nach whileInView, data-aos oder einer .reveal-Klasse mit translateY. Dann prüf: Ist es mit Absicht auf *ein* Element angewendet, oder per .map() über das ganze Dokument gestreut?

Die schnellere Heuristik, ganz ohne Tools: Scroll in normalem Lesetempo und frag dich, ob die Bewegung dir irgendetwas gesagt hat. Hat etwas deinen Blick auf das Wesentliche gelenkt? Oder ist die ganze Seite beim Scrollen der Reihe nach nach oben gezuckt? Wenn Letzteres, ist die Bewegung Dekoration, von einem Generator angeklatscht, ein weiterer Posten in der 30-Sekunden-Checkliste zur KI-Erkennung, gleich neben dem Blau-Lila-Gradient und der Geist-Schrift.

Noch ein Verräter: der Lade-Flash. Viele KI-Scroll-Reveal-Setups setzen opacity: 0 im CSS, triggern das Reveal aber in JS. Bei langsamer Verbindung oder mit deaktiviertem JS ist der Inhalt above the fold unsichtbar, eine leere Seite, bis der Observer feuert. Es ruiniert auch die gemessene Performance: Jedes Element, das nach dem First Paint hereinpoppt, zählt auf den Cumulative Layout Shift, und eine Seite, die ihren Hero hinter einem Observer versteckt, kann einen CLS jenseits von 0,25 hinlegen (Googles "schlecht"-Schwelle liegt bei 0,1) und ihren Largest-Contentful-Paint-Kandidaten komplett verlieren, weil das LCP-Element noch nicht gemalt war, als der Browser hinschaute. Eine echte Implementierung versteckt nie Inhalt hinter einem Script. Die generierte liefert fröhlich eine Seite aus, die für den First Paint eines Screenreaders und einen Lighthouse-Crawl leer ist, also genau die Art von Sache, die Googles Helpful-Content-Maschinerie zu bestrafen lernt.

Bewegung mit Absicht

Hier der Perspektivwechsel. Bevor du auch nur eine einzige Transition hinzufügst, beantworte pro animiertem Element eine Frage: Was ist die Aufgabe dieser Bewegung? Wenn du die Aufgabe nicht benennen kannst, lösch die Animation. "Sieht nett aus" ist keine Aufgabe.

Wenn Bewegung eine Aufgabe hat, hört der Code von ganz allein auf, uniform zu sein, weil verschiedene Aufgaben verschiedene Bewegung brauchen:

// Aufgabe: Den Blick auf die zentrale Aussage lenken, dann die
// stuetzende Zeile als nachgeordnet folgen lassen. Ein Stagger, gewollt.
<motion.h1
  initial={{ opacity: 0, y: 12 }}
  animate={{ opacity: 1, y: 0 }}
  transition={{ duration: 0.4, ease: [0.22, 1, 0.36, 1] }}
>
  Halbiere deine AWS-Rechnung.
</motion.h1>
<motion.p
  initial={{ opacity: 0 }}
  animate={{ opacity: 1 }}
  transition={{ duration: 0.4, delay: 0.12 }}  // folgt der Headline
>
  Wir auditieren ungenutzte Instanzen, die du laengst vergessen hast.
</motion.p>

// Aufgabe: keine. Der CTA ist der Punkt. Er ist ab Frame eins da.
<a href="/start" className="btn-primary">Audit starten</a>

Achte auf den Unterschied. Die Headline nutzt eine echte Easing-Kurve, [0.22, 1, 0.36, 1], ein schnelles Abbremsen, nicht das faule easeOut. Die Subheadline blendet nur ein, ohne y, weil sie keinen Auftritt hat, sie holt auf. Der CTA animiert gar nicht. Drei Elemente, drei Entscheidungen. Das ist das Gegenteil eines .map().

Für Scroll lautet die Regel: Enthülle etwas, das der Nutzer ohnehin nicht sehen konnte, und enthülle es, weil es jetzt wichtig ist, es zu sehen. Ein Chart, der seine Balken zeichnet, während er ins Viewport kommt, hier *ist* die Bewegung das Enthüllen der Daten, verdient. Eine Preistabelle, die beim Scrollen nichts tut, weil sie eine Tabelle ist und du sie lesen willst, nicht angucken, auch korrekt. Der generierte Instinkt ist "alles enthüllt sich". Der gestaltete Instinkt ist "fast nichts enthüllt sich, und das eine, das es tut, hat einen Grund".

Und mach die barrierefreie Variante ordentlich, in CSS, damit Inhalt nie hinter JS gesperrt ist und Reduced-Motion-Nutzer den Inhalt ohne Sprung bekommen:

.reveal { opacity: 0; transform: translateY(20px); transition: opacity .5s, transform .5s; }
.reveal.in { opacity: 1; transform: none; }

@media (prefers-reduced-motion: reduce) {
  .reveal { opacity: 1; transform: none; transition: none; }
}

Dieser letzte Block ist die Zeile, die der Generator fast nie schreibt. Grob jeder dritte macOS- und iOS-Nutzer hat "Bewegung reduzieren" zeitweise aktiviert; ohne diese Media Query auszuliefern heißt, dass dein "hochwertiges" Reveal für sie nichts weiter ist als ein Layout, das ruckelt.

Ein paar praktische Anti-Slop-Moves:

• Variier nach Rolle, nicht nach Index. Kein delay: i * 0.1. Stagger nur, wenn die Elemente eine echte Abfolge bilden, einen nummerierten Prozess, eine Timeline. Für ein Grid gleichgewichtiger Cards blende die ganze Gruppe gemeinsam ein, oder blende sie gar nicht ein.
• Misch deine Easings. Eingänge bremsen ab. Ausgänge beschleunigen. Reservier Overshoot (cubic-bezier(0.34, 1.56, 0.64, 1)) für ein, zwei verspielte Momente, damit es etwas Besonderes bleibt. Eine Seite mit drei eigenständigen Kurven wirkt komponiert; eine mit einer einzigen wirkt gedruckt.
• Animier eine unerwartete Eigenschaft. Alle machen Opacity und Translate. Ein clip-path-Wipe, ein filter: blur(8px), der sich scharfstellt, ein einzelner Akzent, der von #64748b zu #0ea5e9 wandert, das liest sich gerade deshalb als bewusst, weil der Generator nie danach greift.
• Kill das Below-the-fold-Reveal bei Langform-Content. Ein Artikel oder eine Docs-Seite braucht nicht, dass ihre Absätze beim Scrollen hochsteigen. Das ist Bewegung um der Bewegung willen, und es bremst das Lesen aktiv aus.
• Versteck nie Inhalt hinter JS. Bewegung ist eine Verbesserungsschicht, kein Tor. Sichtbar beim First Paint, immer.

Der tiefere Punkt zieht sich durch diesen ganzen Blog. Der KI-Default ist nicht schlecht, weil er hässlich ist, Fade-in-up ist für eine halbe Sekunde völlig angenehm. Er ist schlecht, weil er *undifferenziert* ist, und undifferenziert ist der eigentliche Fingerabdruck maschineller Ausgabe. Der Gradient, die Schrift, die rounded-2xl-Card, der text-gray-600-Fließtext und das 16px-Scroll-Reveal sind dasselbe Versagen: Ein Generator pickt die globale-Minimum-Sicherheitsentscheidung und wendet sie überall an, weil er keinen Geschmack zu riskieren und keine Absicht auszudrücken hat.

Du brichst es jedes Mal auf dieselbe Weise auf. Hör auf, das Tool entscheiden zu lassen. Nimm jedes Element in die Hand und frag, wofür es da ist. Die Bewegung, die diese Frage überlebt, ist die Bewegung, die es wert ist, ausgeliefert zu werden, und sie wird nie, niemals aussehen wie ein .map() von whileInView die Seite hinunter.