Ab WordPress 7.0 lassen sich eigene Blöcke vollständig in PHP entwickeln. Bisher war dafür zwingend JavaScript notwendig. Mit der neuen Option autoRegister entfällt das. WordPress übernimmt die Editor-Integration automatisch.

Was ist »autoRegister«?

autoRegister ist eine neue Option im supports-Array, die mit WordPress 7.0 eingeführt wurde. Das supports-Array ist Bestandteil von register_block_type() und legt fest, welche Editor-Funktionen ein Block unterstützt, wie z.B. Farb- oder Abstandsoptionen. Ist autoRegister aktiv, registriert WordPress den Block selbstständig im Editor.

Block erstellen: Schritt für Schritt

Ein PHP-only Block kann folgendermaßen aufgebaut werden:

1. Block-CSS mit wp_register_style() registrieren
2. Block via register_block_type() registrieren und Titel, Beschreibung, Kategorie, Attribute und Supports direkt als PHP-Array übergeben
3. Im supports-Array autoRegister auf true setzen
4. Einen render_callback schreiben (eine PHP-Funktion, die das HTML des Blocks für das Frontend erzeugt)
5. get_block_wrapper_attributes() verwenden (eine WordPress-Funktion, die alle notwendigen HTML-Attribute wie Klassen und Inline-Styles aus den Block Supports automatisch generiert)

In folgendem Beispiel erzeugen wir einen einfachen PHP-Block als Plugin. Der Block heißt »Info-Block« und gibt einen kurzen Text im Frontend aus. Über die Sidebar des Block-Editors lässt sich der Text bearbeiten sowie Schrift- und Hintergrundfarbe anpassen – alles ohne eine einzige Zeile JavaScript.

<?php
/*
Plugin Name: Info-Block (PHP-Only Block)
Description: Integration des PHP-Only Info-Blocks ab WordPress 7.0
*/

function kb_info_block_register_block() {

    // Schritt 1: CSS registrieren
    wp_register_style(
        'kb-info-block-style',
        plugin_dir_url( __FILE__ ) . 'style.css'
    );

    // Schritte 2 & 3: Block registrieren und autoRegister aktivieren
    register_block_type( 'pluginname/info-block', [
        'title'    => 'Info-Block',
        'category' => 'text',
        'style'    => 'kb-info-block-style',
        'attributes' => [
            'text' => [
                'type'    => 'string',
                'label'   => 'Text',
                'default' => '',
            ],
        ],
        'supports' => [
            'autoRegister' => true,
            'color' => [
                'text'       => true,
                'background' => true,
            ],
        ],
        'render_callback' => 'kb_info_block_render_block',
    ] );
}
add_action( 'init', 'kb_info_block_register_block' );

// Schritte 4 & 5: render_callback mit get_block_wrapper_attributes()
function kb_info_block_render_block( $attributes ) {
    $wrapper = get_block_wrapper_attributes();
    $text    = esc_html( $attributes['text'] ?? '' );

    return "<div {$wrapper}>{$text}</div>";
}

Das Plugin besteht aus zwei Dateien: der PHP-Hauptdatei (z. B. info-block.php) mit der Block-Registrierung und einer style.css im selben Ordner für das Styling. Der Plugin-Ordner wird wie üblich unter wp-content/plugins/ abgelegt.

Einstellungen (Block Controls) für PHP-Blöcke festlegen

WordPress generiert automatisch die passenden Eingabefelder und Styling-Optionen in der rechten Seitenleiste, sobald bestimmte Attribute korrekt definiert sind. Eigene, JavaScript-basierte, Eingabefelder (Inspector Controls) lassen sich mit PHP-only Blöcken nicht umsetzen. Für viele Anwendungsfälle wird das auch nicht benötigt.

Input-Typen über Attribute steuern

Erhält ein Attribut einen label-Key, erzeugt WordPress daraus selbstständig ein passendes Eingabefeld in der Sidebar. Der Typ des Attributs bestimmt dabei, welches Control erscheint:

• string → Texteingabe (TextControl)
• integer oder number → Zahleneingabe (NumberControl)
• boolean → Umschalter (ToggleControl)
• string kombiniert mit enum → Auswahlmenü (SelectControl)

Styling-Optionen mittels Block Supports steuern

Block Supports sind vordefinierte WordPress-Funktionen wie Farb-, Abstands- oder Typografie-Optionen. Sie lassen sich direkt im supports-Array aktivieren, wodurch WordPress die entsprechenden Sidebar-Panels automatisch rendert.

Wann sind PHP-only Blöcke sinnvoll?

PHP-only Blöcke eignen sich besonders für einfache Ausgabe-Blöcke ohne komplexe Interaktion im WordPress-Editor. Sobald ein Block aufwändige Editor-Interaktion benötigt, z.B. verschachtelte Blöcke Media-Uploads oder eine eigene Live-Vorschau, kommt man um JavaScript nicht herum. Für alle anderen Fälle ist der PHP-Block oft die schlankere und wartungsärmere Lösung.

PHP-Blöcke mit Claude Code entwickeln

Claude Code lässt sich durch Skills erweitern. Der folgende Skill php-block (nicht offiziell von WordPress) versorgt Claude mit den Konventionen des Projekts, sodass generierter Code den Standards entspricht. Eine Einführung in das Thema bietet dieses Video-Tutorial.

Der Beitrag WordPress: PHP-only Blöcke mit autoRegister erschien zuerst auf Agentur kulturbanause.

Video

Vom Wasserfall zum iterativen Prozess

Jahrelang war der typische Weg zwischen Design und Code eine Einbahnstraße: Im Design-Tool entstand ein Entwurf, Entwicklerinnen und Entwickler übertrugen ihn in Code. MCP-Integrationen haben diesen Transfer zuletzt automatisiert – aber die Richtung blieb meist dieselbe – wenn es auch bereits seit Jahren Gegentrends gab. Mit »Code to Canvas« dreht Figma diesen Prozess nun konsequent um. Eine fertig umgesetzte Benutzeroberfläche im Browser, bestehend aus HTML, CSS und JavaScript, wird dabei automatisch auf die Figma-Arbeitsoberfläche übertragen.

Ein Figma-Plugin für Claude Code

Im Zuge einer Kooperation zwischen Figma und Anthropic, dem Hersteller von Claude, ist ein offizielles Plugin entstanden, das die Integration deutlich vereinfacht. Statt den Figma-MCP-Server manuell einzurichten und Skills separat herunterzuladen, liefert das Plugin beides als Bundle. Die Installation erfolgt über das Terminal im jeweiligen Projektordner mit einem einzigen Befehl.

Nach der Installation und einem Neustart von Claude Code erscheint das Figma-Plugin als »Built-in MCP«. Wer bereits die klassischen Figma-MCP-Integration eingerichtet hat, kann diese weiternutzen.

Vom Browser in die Figma-Datei

Der Transfer vom Browser in den Code läuft über einen Prompt in Claude Code. Dieser enthält zwei Informationen: die localhost-URL der laufenden Web-App und den Link zur Zieldatei in Figma. Ein einfacher Satz wie »Implementiere dieses Design (localhost-URL) in diese Figma-Datei (Figma-URL)« genügt.

Claude Code greift automatisch auf den passenden Figma-Skill zurück und analysiert die Figma-Datei und die HTML-Quelle. Für den Prozess wird ein kleines JavaScript-Snippet temporär in die HTML-Datei eingefügt. Dieses Script ermöglicht Figma, einen visuellen Snapshot der Seite zu erstellen, und aktiviert zusätzlich eine interaktive Toolbar im Browser, mit der ihr auch einzelne Elemente zur selektiven Übertragung auswählen könnt.

Das Ergebnis in Figma ist überzeugend: Die Elemente erscheinen mit korrekten Abmessungen und Auto-Layout-Interpretation so, wie sie im Code definiert wurden.

Bidirektional: Änderungen aus Figma zurück in den Code

Der wirklich interessante Teil des Features liegt im bidirektionalen Workflow. Figma verfolgt das Ziel, die strikte Trennlinie zwischen Design und Entwicklung aufzuweichen. Änderungen sollen nicht nur von Design zu Code fließen, sondern auch in die umgekehrte Richtung.

In der Praxis funktioniert das so: Ein Element in Figma wird bearbeitet, anschließend genügt ein kurzer Prompt wie »Ziehe die Designänderungen im Code nach«, damit der Agent die Figma-Datei ausliest, die Änderung identifiziert und den Code aktualisiert. Das Resultat ist unmittelbar im Browser sichtbar.

Der Grundstein ist gelegt

Code to Canvas ist ein wichtiger und überzeugender erster Schritt. Was in vielen Fällen Drittanbieter-Plugins wie HTML to Design ermöglichten, ist jetzt zumindest in Anfängen nativ in Figma verfügbar und tief mit KI-gestützten Coding-Tools wie Claude Code verzahnt.

Der bidirektionale Ansatz beschreibt allerdings letztlich einen Workflow, den Designer mit Coding-Kenntnissen schon immer intuitiv genutzt haben. Das dauerhafte Wechseln zwischen Design-Tool und Code-Editor um Änderungen in beide Richtungen zu übertragen. Neu ist, dass diese Übergänge jetzt durch KI und MCP-Integrationen automatisiert werden und somit auch für Teams ohne tiefes Coding-Wissen zugänglich werden.

Der Beitrag Figma »Code to Canvas« und bidirektionale Workflows mit Claude erschien zuerst auf Agentur kulturbanause.

Video

Video anschauen

Was der Dev Mode an Layout-Informationen ausgibt

Wer im Dev Mode ein Element anklickt, das sauber mit Auto Layout aufgebaut wurde, erhält auf einen Blick alle relevanten CSS-Eigenschaften: Padding-Werte, Gap zwischen den Kind-Elementen sowie das grundlegende Layout-Verhalten – also ob es sich um eine Flexbox oder ein Grid handelt.

Ein Beispiel: Ein Header-Element mit Logo links und Button rechts zeigt im Dev Mode justify-content: space-between und align-items: center – genau das, was der Abstand »Auto« im Design-Mode bedeutet. Padding-Werte erscheinen farblich hervorgehoben (blau für Padding, rot schraffiert für Gap), was die Übersicht weiter erleichtert.

Diese Ausgabe funktioniert aber nur, wenn das Element im Design-Mode tatsächlich mit Auto Layout gebaut wurde. Ohne diese Vorbereitung liefert Dev Mode keine Layout-Eigenschaften – nur feste Breiten- und Höhenangaben.

Auto Layout: Die Abstraktion von Flexbox und Grid

Auto Layout ist Figmas abstrahierte Umsetzung von CSS-Layoutmechanismen wie Flexbox und Grid. Es erlaubt Designerinnen und Designern, Elemente so zu strukturieren, dass sie ähnlich wie im Browser reagieren – responsiv, abstandsbasiert, hierarchisch verschachtelt.

Der Unterschied zu einem klassischen Design-Tool wie Illustrator: Dort werden Elemente einfach positioniert – ein Rechteck hier, ein Text daneben. In Figma mit Auto Layout dagegen definiert man Innenabstände (Padding) und Abstände zwischen Elementen (Gap) explizit, und die Breite eines Elements ergibt sich automatisch aus Inhalt plus Padding. Das entspricht dem intrinsischen Verhalten im Web.

Sobald mehrere Elemente gemeinsam reagieren sollen – etwa zwei Buttons nebeneinander – werden sie in ein Eltern-Element verpackt, das ebenfalls Auto Layout erhält. So entsteht eine verschachtelte Hierarchie, die der DOM-Struktur im Browser sehr ähnelt.

Ohne Auto Layout fehlt etwas

Wird ein Element ohne Auto Layout gebaut – also nur als gezeichnetes Rechteck mit Text darüber –, sieht man im Dev Mode kein Padding, keinen Gap, keine Flexbox-Eigenschaften. Entwicklerinnen und Entwickler müssen sich die Abstände dann manuell ablesen oder schätzen.

Das ist nicht nur ineffizient, es führt auch zu Fehlern und Missverständnissen im Handoff. Eine Datei, die so aufgebaut ist, hat klaren Nachbesserungsbedarf. Die Mindestanforderung sollte sein: einheitliche Abstände, eine Spacing-Hierarchie, und konsequente Nutzung von Auto Layout für alle strukturierten Elemente.

Layout-Variablen für konsistente Abstands-Tokens

Noch aussagekräftiger wird der Dev Mode, wenn Layout-Informationen nicht als fester Wert, sondern als Variablen vergeben werden. Dazu legt man in Figma eine eigene Variable-Collection für Layout an – etwa mit Zahlenwerten wie »size-1 = 8px« und »size-2 = 12px«.

Diese Variablen werden dann bei Padding- und Gap-Werten der Elemente eingesetzt. Im Dev Mode erscheinen anschließend nicht mehr nur Pixelwerte, sondern die zugehörigen Token-Namen – also zum Beispiel »space-4« statt »24px«. Das ermöglicht es, Design-Tokens direkt im Code mit Komponentenwerten zu verknüpfen, was den Handoff erheblich beschleunigt.

In gut organisierten Design-Systemen gibt es dafür eine eigene Spacing- oder Responsive-Collection, in der alle Abstandswerte zentral definiert und von dort aus im gesamten Design referenziert werden.

Flexbox mit Wrap und Grid in Figma

Auto Layout unterstützt nicht nur einfache horizontale oder vertikale Flexbox-Layouts. Wird die Option »Wrap« aktiviert, erhält das Layout sowohl einen horizontalen als auch einen vertikalen Gap – und der Dev Mode gibt entsprechend flex-wrap: wrap aus.

Für Grid-Layouts gibt es in Figma (aktuell noch in der Beta) eine eigene Grid-Option in Auto Layout. Dort lässt sich die Spalten- und Zeilenstruktur definieren, Elemente können frei im Raster positioniert werden, und einzelne Spalten können feste oder dynamische Breiten erhalten – etwa »1fr« oder »200px«.

Im Dev Mode erscheint dann kein Flexbox-Code, sondern ein CSS Grid mit grid-template-columns und den entsprechenden Zeilendefinitionen.

Min- und Max-Breiten für responsives Verhalten

Responsives Design bedeutet mehr als nur flexible Breiten. Oft benötigt man Mindest- und Höchstbreiten, damit ein Element nicht zu klein oder zu groß wird. In Figma lassen sich bei der Breitendefinition eines Elements zusätzlich min-width und max-width festlegen – zum Beispiel »minimal 320px« (Smartphone-Breite) und »maximal 500px«.

Wurden diese Werte im Design-Mode hinterlegt, erscheinen sie auch im Dev Mode – umgerechnet in rem-Werte (sofern so konfiguriert) und direkt als min-width und max-width ausgewiesen. Das macht die Umsetzung im CSS deutlich eindeutiger und reduziert Rückfragen zwischen Design und Entwicklung.

Der Beitrag Figma Dev Mode: Layout Informationen auslesen – von Auto Layout zu Flexbox und Grid erschien zuerst auf Agentur kulturbanause.

Video

Video anschauen

Das Problem: Interpretation statt Production Code

Wenn Entwickler im Figma Dev Mode eine Komponente inspizieren, zeigt Figma eine Code-Interpretation an – einen automatisch generierten Vorschlag, wie die Komponente umgesetzt werden könnte. Dasselbe passiert beim agentischen Coden: Die KI erfindet den Code jedes Mal neu, basierend auf der visuellen Darstellung.

In vielen Organisationen existiert jedoch bereits eine getestete, produktionsreife Code-Bibliothek mit fertigen Komponenten. Der automatisch generierte Code von Figma ist in solchen Fällen bestenfalls ein Näherungswert – im schlimmsten Fall führt er zu Inkonsistenzen und Mehraufwand.

Code Connect: Die Brücke zwischen Design und Code

Figma bietet mit »Code Connect« ein Feature, das genau dieses Problem löst. Es stellt eine direkte Verbindung zwischen UI-Komponenten in der Figma-Library und den dazugehörigen Code-Dateien in einem Repository her. Sobald diese Verbindung besteht, sehen Entwickler im Dev Mode nicht mehr Figmas Interpretation, sondern den tatsächlichen Code ihrer Organisation.

Voraussetzung ist eine Organisation- oder Enterprise-Lizenz von Figma. Das Feature ist in den unteren Lizenzmodellen nicht verfügbar.

Einrichtung über die Benutzeroberfläche

Die Verknüpfung erfolgt im Dev Mode über den Menüpunkt »Library → Connect Components to Code«. Figma zeigt eine Liste aller Komponenten der aktuellen Bibliothek an. Für jede Komponente kann eine URL zur entsprechenden Code-Datei in einem Repository hinterlegt werden.

Besonders komfortabel wird es mit einer GitHub-Verbindung: Figma erkennt dann die Repository-Struktur und ermöglicht eine direktere Auswahl der passenden Dateien. Grundsätzlich funktioniert das Feature aber auch mit beliebigen URLs, die nicht auf GitHub liegen.

Sobald die Verbindung hergestellt ist, wird die Komponente in der Übersicht als „connected“ markiert und im Dev Mode erscheint der Verweis auf die verknüpfte Code-Datei.

KI-Instruktionen für gezielte Steuerung

Ein besonders nützliches Feature ist die Möglichkeit, pro Verbindung zusätzliche Anweisungen für KI-Tools zu hinterlegen. Diese »Instructions« werden gelesen, wenn eine KI die Komponente umsetzen soll. So lässt sich sicherstellen, dass KI-gestützte Workflows nicht blind arbeiten, sondern kontextbewusst agieren.

Integration mit KI-Coding-Tools

Über das Model Context Protocol (MCP) können KI-Tools wie Claude Code auf den Figma-Kontext zugreifen. In der Praxis bedeutet das: Man kopiert den Link zu einer Figma-Komponente, gibt Claude Code & Co. den Auftrag, diese Komponente zu bauen, und das Tool liest automatisch den hinterlegten Code sowie die Instructions aus.

Die KI greift dann nicht auf eine neue Interpretation zurück, sondern nutzt den tatsächlichen Production-Ready-Code als Basis – ergänzt um die spezifischen Anweisungen, die für diese Komponente hinterlegt wurden.

Der Beitrag Figma Code Connect UI: Komponenten mit »Production Ready« Code verknüpfen erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Was ist das Original?

Im klassischen Workflow zwischen Design und Entwicklung steht das Design am Anfang. UX/UI-Teams gestalten Oberflächen und Komponenten in Tools wie Figma, und anschließend wird das Ergebnis in Code übertragen – ob manuell durch Entwickler oder automatisiert durch KI. Änderungen werden zuerst im Design umgesetzt und danach im Code nachgezogen.

Dieses Vorgehen hat einen grundlegenden Nachteil: Was in Figma als einzelne Komponente existiert – etwa ein Button – wird in der Praxis in verschiedenen Umgebungen gerendert. Unterschiedliche Browser, verschiedene Zieltechnologien wie HTML und React, und diverse Rendering-Engines führen dazu, dass aus einem einzigen Design-Original eine multidimensionale Code-Darstellung entsteht. Die Single Source of Truth im Design wird durch die Vielfalt der Implementierungen aufgeweicht.

Code als Single Source of Truth

Die Alternative besteht darin, den Workflow umzudrehen. Statt im Design zu starten und den Code abzuleiten, wird der Code selbst zum Original. Änderungen finden direkt in der Code-Basis statt, und das Design-Tool – in diesem Fall Figma – dient als Darstellungsoberfläche, um mit den UI-Komponenten im Kontext von Prototypen und Iterationen arbeiten zu können.

Dieser Ansatz ist besonders dann sinnvoll, wenn bereits ein ausgereiftes Design-System als Code-Bibliothek vorliegt, beispielsweise in einem Storybook oder einer browserbasierten Komponentendokumentation. Statt die Bibliothek in Figma von Grund auf aufzubauen und anschließend an den Code zu übertragen, kommt man von der Code-Seite und importiert die Komponenten zurück in die visuelle Umgebung.

HTML to Design: Das Figma-Plugin für den Import

Das Figma-Plugin HTML to Design ermöglicht genau diesen Weg. Es ist im Design-Modus verfügbar (nicht im Dev Mode) und bietet in der kostenlosen Version etwa 10 Importe pro Monat. Es gibt zwei Hauptwege für den Import: Die direkte Eingabe einer URL, um eine komplette Seite zu importieren, oder die Nutzung einer Chrome-Extension, mit der gezielt einzelne Bereiche einer Live-Website ausgewählt und an Figma gesendet werden können.

Die Chrome-Extension funktioniert ähnlich wie die Browser-DevTools: Man wählt auf der gewünschten Website den gewünschten Bereich aus – etwa eine Navigationsleiste – und sendet ihn direkt an das Plugin in Figma. Dort stehen verschiedene Import-Optionen zur Verfügung, etwa ob Auto Layout verwendet werden soll oder wie mit Schriften umgegangen wird.

Was das Plugin erkennt und umsetzt

Beim Import interpretiert das Plugin die Code-Struktur intelligent. Flexbox-Layouts werden automatisch als Auto Layouts erkannt, Container-Strukturen und Verschachtelungen werden beibehalten. Das Ergebnis ist ein Figma-Frame, der die tatsächliche Code-Architektur widerspiegelt – mit korrekten Hierarchien, Abständen und Layout-Eigenschaften.

Falls verwendete Schriftarten lokal nicht verfügbar sind, bietet das Plugin einen automatischen Ersatz an, etwa durch Helvetica. So entsteht ein arbeitsfähiges Figma-Element, das als Ausgangspunkt für weitere Design-Arbeit, Prototypen oder Iterationen dienen kann.

Der Beitrag Figma HTML to Design: Wenn der Code zur Single Source of Truth wird erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Pixelgrafiken (PNG, JPG) aus Figma exportieren

Beim Umsetzen von Designs müssen regelmäßig Grafiken exportiert werden – von Hintergrundbildern über Logos bis hin zu Icons. Figma bietet dafür im Dev Mode mehrere Wege an, die je nach Anwendungsfall unterschiedlich effizient sind.

Für den Export als Pixelgrafik (PNG, JPG) muss das zu exportierende Element in einem Frame liegen. Frames sind in der Ebenenpalette am Rauten-Symbol erkennbar. Nach Auswahl des Frames erscheint rechts unten die Export-Funktion mit Einstellungen für Format, Auflösung (1x, 2x, 3x) und Farbprofil (sRGB, Display P3). Eine Vorschau zeigt das Ergebnis vor dem Download. Moderne Bildformate wie WebP oder AVIF werden aktuell noch nicht nativ unterstützt, können aber über Plugins ergänzt werden.

SVG exportieren

In der Praxis dominiert der SVG-Export, insbesondere für Icons, Logos und grafische Formen. Figma erkennt innerhalb einer Auswahl automatisch enthaltene Assets – ein Icon innerhalb eines Buttons wird als eigenständiges Element identifiziert und kann separat heruntergeladen werden. Bei Vektorformen zeigt die rechte Seitenleiste einen SVG-Abschnitt mit dem vollständigen Quellcode.

Der effizienteste Workflow für SVGs die im Code eingefügt werden sollen: Per Rechtsklick auf das Element und »Copy as SVG« den Code direkt in die Zwischenablage kopieren. Anschließend lässt sich der Code in einem Optimierungstool wie SVG Viewer einfügen, dort auf Korrektheit prüfen und in der Dateigröße reduzieren. Das optimierte SVG wird dann direkt in die Codebasis übernommen – ohne den Umweg über eine gespeicherte Datei. Alternativ steht der SVG-Code auch in der rechten Seitenleiste zum Kopieren bereit. Verschachtelte Komponenten – etwa ein Button, der ein Icon als eigene Instanz enthält – lassen sich durch Klicken auf die tiefere Ebene einzeln inspizieren. So kann das Icon isoliert exportiert werden.

Der Beitrag Figma Dev Mode: Grafiken und SVGs exportieren erschien zuerst auf Agentur kulturbanause.

Video

Link zum Video

Eine Datei oder mehrere?

Solange ein Projekt überschaubar ist und alle Designs in einer einzigen Datei leben, müssen Komponenten und Styles nicht zwingend als Bibliothek veröffentlicht werden. Erst wenn mehrere Projektdateien auf dieselben globalen Assets zugreifen sollen, lohnt sich der Schritt zur geteilten Bibliothek. In der Praxis ist das allerdings üblich.

Das Veröffentlichen erfolgt über den Bereich Assets → Bibliotheken. Bei größeren Designsystemen mit über 1000 Komponenten kann dieser Vorgang durchaus mehrere Minuten dauern.

Verknüpfte Bibliotheken im Dev Mode

Sobald eine Bibliothek veröffentlicht und in einer Projektdatei verknüpft ist, können Komponenten aus der Bibliothek ganz normal eingesetzt werden. Im Dev Mode fällt dann jedoch ein kleiner, aber wichtiger Unterschied auf:

• Befindet sich die Hauptkomponente in derselben Datei, zeigt Figma in der Seitenleiste schlicht »Component instance« an.
• Stammt die Komponente aus einer externen Bibliothek, erscheint ein abweichendes Icon und ein Hinweis, dass das Original in einer anderen Datei liegt. Zusätzlich wird der Name der Quelldatei in Klammern angezeigt, zum Beispiel: »Component instance (Simple Design System)«.

Mit einem Klick auf dieses Icon springt man direkt in die Originaldatei und genau an die Stelle, wo die Komponente erstellt wurde. Voraussetzung ist natürlich, dass man Zugriff auf diese Datei hat. Fehlt der Zugriff, erscheint eine entsprechende Meldung.

Bibliotheks-Updates und Änderungen

Hat jemand eine Instanz lokal angepasst – etwa den Text geändert –, zeigt der Dev Mode das transparent an: Es wird darauf hingewiesen, dass Text oder Layout vom Original abweichen. Über eine Vergleichsansicht lässt sich genau nachvollziehen, was geändert wurde.

Wenn in der Hauptbibliothek Änderungen vorgenommen werden, können diese als Update in den Projektdateien eingespielt werden. Dabei sollte man im Hinterkopf behalten, dass eine scheinbar kleine Änderung weitreichende Folgen haben kann: Da Komponenten im Atomic Design oft ineinander verschachtelt sind, kann eine einzelne Anpassung Dutzende abhängige Komponenten betreffen.

Das Update selbst kann global oder selektiv für einzelne Instanzen eingespielt werden. Hier liegt jedoch eine wichtige Einschränkung des beschriebenen Workflows: Wurde ein Update nur für einzelne Instanzen eingespielt, ist der veraltete Stand anderer Instanzen im Dev Mode nicht leicht erkennbar.

Der Beitrag Figma-Bibliotheken: Struktur, Updates und Dev-Mode-Besonderheiten erschien zuerst auf Agentur kulturbanause.

Captchas gehören zu den Themen, bei denen Barrierefreiheit, Datenschutz und Nutzererlebnis regelmäßig in Konflikt geraten. Wir möchten einordnen, wie wir das Thema bei kulturbanause angehen und welche Anbieter wir uns angeschaut haben. Grundsätzlich versuchen wir in Projekten ganz ohne Captcha auszukommen. Wenn ein Captcha unvermeidbar ist, setzen wir auf eine datenschutzkonforme, barrierefreie und möglichst selbst gehostete Lösung. Allerdings sind wir mit keiner uns bekannten Lösung vollständig zufrieden, da sie alle – je nach Projektanforderungen – Nachteile haben.

Was sind Captchas?

Captcha steht für »Completely Automated Public Turing test to tell Computers and Humans Apart«. Es handelt sich um einen automatisierten Test, der erkennen soll, ob eine Eingabe von einem Menschen oder von einem Bot stammt. Captchas kommen typischerweise in Formularen, bei Login-Vorgängen oder bei Registrierungen zum Einsatz.

Arten von Captchas

Es gibt verschiedene Ansätze, die sich in der Art der Nutzerinteraktion und im Grad der Sichtbarkeit unterscheiden. Die relevantesten sind:

• Bildbasierte Captchas stellen visuelle Aufgaben, etwa das Auswählen bestimmter Motive wie Ampeln, Zebrastreifen oder Fahrzeuge. Sie sind weit verbreitet, aber problematisch in Bezug auf Barrierefreiheit. Zudem finden viele Menschen diese Art der Abfrage sehr nervig.
  
• Textbasierte Captchas zeigen verzerrte Buchstaben- oder Zahlenfolgen, die abgetippt werden müssen. Auch diese Variante ist für Menschen mit Sehbeeinträchtigungen oder kognitiven Einschränkungen schwer nutzbar.
  
• Rechenaufgaben fordern die Lösung einfacher mathematischer Aufgaben wie »Was ergibt 3 + 7?«. Sie sind leichter zugänglich als Bilder, aber ebenfalls nicht barrierefrei im engeren Sinne, da kognitive Tests problematisch sind.
  
• Checkbox-Captchas wie das bekannte »Ich bin kein Roboter« analysieren im Hintergrund das Nutzerverhalten und zeigen nur bei Verdacht eine zusätzliche Aufgabe. Die Checkbox selbst ist dabei nicht die eigentliche Prüfung – die Analyse findet vorher statt.
  
• Unsichtbare Captchas sind technisch den Checkbox-Captchas sehr ähnlich, arbeiten jedoch vollständig im Hintergrund. Sie analysieren das Verhalten oder den Kontext einer Anfrage, um einen Risk-Score zu berechnen. Die Verifizierung erfolgt automatisch, ohne dass Nutzerinnen und Nutzer aktiv etwas tun müssen.
  
• Proof-of-Work-Captchas verfolgen einen anderen Ansatz: Das Endgerät löst eine kryptografische Rechenaufgabe, die für einen einzelnen Aufruf trivial ist, bei massenhaften Bot-Anfragen aber schnell aufwändig wird. Da keine Nutzerdaten erhoben werden müssen, ist dieses Verfahren besonders datenschutzfreundlich. Allerdings hat dieser Ansatz auch Nachteile, denn die Berechnung erfolgt auf dem Endgerät der Nutzerinnen und Nutzer und benötigt Rechenleistung sowie Energie.

Anforderungen, Vorteile und Nachteile von Captchas

Bots verursachen Spam, erzeugen gefälschte Konten, überlasten Server und manipulieren Formulare. Captchas lösen in diesem Zusammenhang ein reales und häufig auftretendes Problem. Ein wirksamer Schutz für Formulare ist daher in vielen Projekten notwendig. Gleichzeitig bringen Captchas eine Reihe von Problemen mit sich, die in der Theorie häufig unterschätzt werden.

Barrierefreiheit

Seit dem Inkrafttreten des EAA und den Vorgaben der BITV 2.0 müssen öffentliche und zunehmend auch privatwirtschaftliche Webangebote barrierefrei sein. Die WCAG sind dabei der technische Maßstab. Bildbasierte und textbasierte Captchas stehen häufig im Konflikt mit diesen Anforderungen – insbesondere dann, wenn keine gleichwertige barrierefreie Alternative angeboten wird. Sie sind für blinde und sehbehinderte Menschen nicht bedienbar, für Menschen mit kognitiven Einschränkungen schwer verständlich und für Menschen mit motorischen Einschränkungen oft nicht zuverlässig zu lösen. Auch Audio-Alternativen sind in der Praxis häufig unzureichend – sie setzen gutes Hörvermögen voraus und sind in vielen Sprachen nicht verfügbar. Wer ein Captcha einsetzt, muss sicherstellen, dass es WCAG-konform ist oder eine gleichwertige Alternative bereitstellt. Andernfalls wird der Sicherheitsmechanismus zur Barriere.

Datenschutz

Viele Captcha-Lösungen erheben Daten, die weit über das hinausgehen, was für die Unterscheidung zwischen Mensch und Bot erforderlich ist. IP-Adressen, Browser-Fingerprints, Mausbewegungen, Cookies usw. Insbesondere bei den Angeboten großer US-Konzerne fließen diese Daten i.d.R. auf Server außerhalb der EU. Eine DSGVO-konforme Nutzung von US-basierten Diensten ist grundsätzlich möglich, der rechtliche und organisatorische Aufwand dafür ist allerdings erheblich, und ein Restrisiko bleibt. Wer diesen Aufwand vermeiden möchte, setzt auf Anbieter, bei denen die Daten die EU gar nicht erst verlassen. Das ist unser bevorzugter Ansatz.

Usability und UX

Alle visuellen Captchas werden gemeinhin als störend und nervig wahrgenommen. Zudem ist die Wirksamkeit klassischer Captchas auch nicht mehr das, was sie einmal war. Moderne Bots und KI-Modelle lösen bild- und textbasierte Captchas recht zuverlässig und schneller als viele Menschen. Neuere Captcha-Verfahren sind weniger anfällig – aber auch sie bieten keinen vollständigen Schutz.

Am liebsten gar kein Captcha

Bevor wir über einzelne Anbieter sprechen, wollen wir unsere grundsätzliche Haltung deutlich machen: Wir streben zunächst an, ganz ohne Captcha auskommen. In vielen Fällen ist das möglich, wenn man bereit ist, auf bestimmte Features zu verzichten oder alternative Schutzmaßnahmen zu kombinieren.

Wir setzen in den meisten Fällen auf eine Kombination aus mehreren Standard-Maßnahmen:

• Honeypot-Felder sind versteckte Formularfelder, die für Menschen unsichtbar sind, von Bots aber automatisch ausgefüllt werden. Wird ein solches Feld ausgefüllt, kann die Anfrage verworfen werden. Die meisten Formular-Plugin für WordPress bieten Honeypots an.
• Zeitprüfungen und serverseitige Validierungen helfen ebenfalls: Wenn ein Formular innerhalb von Millisekunden nach dem Seitenaufruf abgesendet wird, stammt die Eingabe mit hoher Wahrscheinlichkeit nicht von einem Menschen.
• Web Application Firewalls (WAF) können auf Infrastrukturebene das Angriffsvolumen zusätzlich reduzieren – das ersetzt kein Captcha, verringert aber den Druck, eines einsetzen zu müssen.

Und man kann sich auch grundsätzlich fragen, ob ein Formular wirklich notwendig ist. Nicht jede Kontaktmöglichkeit braucht ein Formular, zumal viele Menschen auch lieber eine E-Mail schicken. Erst wenn die o.g. Maßnahmen nicht ausreichen – z.B. bei Registrierungsformularen, Kommentarfunktionen oder häufig besuchten Kontaktseiten – denken wir über ein Captcha nach.

Captcha-Anbieter im Vergleich

Viele Captcha-Dienste bieten eine kostenlose Basisstufe an, die für kleine Websites mit geringem Traffic ausreicht. Für den professionellen Einsatz mit höherem Aufkommen oder erweiterten Funktionen fallen jedoch Kosten an – und das ist auch in Ordnung. Sicherheit und Datenschutz haben einen Wert, und ein zuverlässiger Schutzmechanismus darf etwas kosten.

Neben den reinen Kosten gibt es weitere Überlegungen, die in die Entscheidung einfließen sollten. Möchte man einen globalen Tech-Konzern unterstützen, der möglicherweise Nutzerdaten für eigene Zwecke verwendet? Wo werden die Daten verarbeitet – in der EU oder auf Servern in den USA? Ist die Lösung Open Source und damit transparent und überprüfbar? Kann man das System selbst hosten und behält so die volle Kontrolle? Diese Fragen sind für uns bei kulturbanause entscheidend, und wir geben uns große Mühe Projektpartnern unsere Sichtweise nachvollziehbar zu vermitteln.

Google reCAPTCHA

Google reCAPTCHA ist der am weitesten verbreitete Captcha-Dienst. Die aktuelle Version (v3) arbeitet unsichtbar im Hintergrund und liefert einen sogenannten Risk-Score, auf dessen Basis ihr selbst entscheidet, wie ihr mit einer Anfrage umgeht. Technisch funktioniert das ziemlich gut. Trotzdem setzen wir reCAPTCHA nur im Notfall ein.

Datenschutz problematisch

reCAPTCHA überträgt umfangreiche Daten an Google-Server. Google hat angekündigt, ab April 2026 die Rolle vom »Data Controller« zum »Data Processor« zu wechseln. Das klingt zunächst nach einer Verbesserung: Google verarbeitet die Daten dann formal nur noch nach Weisung der Website-Betreiber. In der Praxis bedeutet das allerdings, dass die rechtliche Verantwortung auf die Betreiber übergeht, während die Vertragsbedingungen weiterhin von Google festgelegt werden. Eine wirkliche Kontrolle hat man somit nicht.

Nicht Open Source

reCAPTCHA ist proprietär. Wie genau die Risikobewertung funktioniert, welche Daten erhoben und wie sie verarbeitet werden, ist nicht überprüfbar.

Überschaubare Kosten

reCAPTCHA Essentials bietet bis zu 10.000 Bewertungen pro Monat kostenlos an. Darüber hinaus fallen bei reCAPTCHA Premium 8 USD pro 1.000 Bewertungen an (bei über 10.000) bzw. 1 USD pro 1.000 Bewertungen ab 100.000. Die Enterprise-Stufe erfordert ein 12-Monats-Abo. Die aktuellen Preise findet ihr auf der reCAPTCHA-Preisseite.

Cloudflare Turnstile

Cloudflare Turnstile wird häufig als unkomplizierte Alternative zu reCAPTCHA genannt. Die Integration ist recht einfach, es gibt keine visuellen Rätsel, und es kostet in der Basisversion nichts. Enterprise-Funktionen gibt es allerdings nur gegen individuelle Preise.

US-Unternehmen mit globaler Datenverarbeitung

Cloudflare ist ein amerikanisches Unternehmen. Die Datenverarbeitung erfolgt über die globale Cloudflare-Infrastruktur, und eine exklusive Verarbeitungsoption innerhalb der EU ist uns nicht bekannt. Wie bei allen US-Anbietern ist eine DSGVO-konforme Nutzung zwar grundsätzlich möglich, aber mit erhöhtem rechtlichen Aufwand und Restrisiko verbunden. Selbst wenn Cloudflare angibt, keine Daten für Werbe-Retargeting zu nutzen, bleiben die Daten auf Servern eines US-Konzerns, der dem US-amerikanischen Recht unterliegt.

Nicht Open Source

Turnstile ist ein proprietärer Dienst. Der Code, der auf den Endgeräten eurer Nutzerinnen und Nutzer ausgeführt wird, ist nicht einsehbar. Was genau erfasst und übertragen wird, lässt sich von außen nicht vollständig nachvollziehen.

Barrierefreiheit unklar

Cloudflare dokumentiert nach unserem Kenntnisstand keine vollständige WCAG-Konformität für Turnstile. Zum Zeitpunkt unserer Recherche konnten wir keine offizielle Erklärung dazu finden. Bei Wettbewerbern(!) wird zudem auf Einschränkungen bei der Nutzung mit Screenreadern und assistiven Technologien hingewiesen. Wir haben das nicht selbst getestet, halten den Punkt aber für relevant genug, um ihn zu erwähnen.

hCaptcha

hCaptcha ist nach reCAPTCHA einer der bekanntesten Captcha-Dienste und positioniert sich ausdrücklich als datenschutzfreundliche und barrierefreie Alternative. Bei genauerem Hinsehen halten diese Versprechen einer kritischen Prüfung allerdings nur bedingt stand.

Kerngeschäft basiert auf KI-Training

hCaptcha setzt bevorzugt auf bildbasierte Rätsel, bei denen Nutzerinnen und Nutzer Objekte in Fotos identifizieren müssen. Im Hintergrund werden damit KI-Modelle trainiert. Ob das mit einer datenschutzfreundlichen Positionierung vereinbar ist, muss jeder für sich selbst entscheiden. In Enterprise-Lizenzen gibt es auch ein unsichtbares Verfahren.

DSGVO-Konformität mit Einschränkungen

hCaptcha bewirbt sich als DSGVO-konform und bietet ein Data Processing Agreement an. Formal ist eine datenschutzkonforme Nutzung damit grundsätzlich möglich. Allerdings bleibt, dass die Datenverarbeitung auf US-Servern erfolgt. Auch das beworbene »First-Party-Hosting«, bei dem Anfragen über eine Subdomain der eigenen Website laufen, ändert daran nichts, zumal dieses Feature nur im Enterprise-Tarif verfügbar ist. Wer »DSGVO-konform« als »Daten verlassen die EU nicht« versteht, wird hier nicht fündig.

Barrierefreiheit in Stufen

hCaptcha bietet zwei Alternativen zum Bild-Captcha: ein textbasiertes Rätsel und ein Third-Party-Cookie, für das sich Betroffene per E-Mail registrieren müssen. In der Enterprise-Variante gibt es darüber hinaus den bereits erwähnten unsichtbaren Modus. Die Verantwortung für eine barrierefreie Implementierung lagert hCaptcha dabei bewusst auf die Website-Betreiber aus. Für uns klingt das eher nach einem Workaround, aber nicht nach einer standardmäßig barrierefreien Lösung.

Nicht Open Source

Der Dienst ist proprietär, nicht selbst hostbar und verarbeitet Daten über externe Server.

Friendly Captcha

Friendly Captcha ist ein deutscher Anbieter, der einen deutlich datenschutzfreundlicheren Ansatz verfolgt als die US-basierten Alternativen. Die Lösung arbeitet unsichtbar im Hintergrund auf Basis von Proof-of-Work und erfordert keine Nutzerinteraktion.

Etwas Open Source, kein Self-Hosting

Das Widget-SDK ist öffentlich einsehbar. Der Verifizierungsdienst selbst ist allerdings proprietär und läuft über die Server von Friendly Captcha. Ohne Enterprise-Plan ist man dauerhaft auf die Infrastruktur des Anbieters angewiesen.

Barrierefreiheit stark

Friendly Captcha arbeitet standardmäßig unsichtbar. Damit bietet es eine sehr gute Ausgangslage für barrierefreien Einsatz. Friendly Captcha bewirbt auf der Accessibility-Seite u.a. WCAG 2.2 AA-Konformität. Eine unabhängige Zertifizierungsstelle wird nicht genannt. Für uns wiegt schwerer, dass wir aus eigener Projekterfahrung bestätigen können, dass Friendly Captcha eine BITV-Prüfung durch deutsche Behörden bestanden hat.

Datenschutz hat seinen Preis

Friendly Captcha erhebt laut eigener Datenschutzerklärung Verbindungs-, Umgebungs- und Interaktionsdaten deutlich sparsamer als die US-Anbieter. Dedizierte EU-Datenendpunkte gibt es erst ab dem Advanced-Plan für 200 Euro pro Monat. Die günstigeren Tarife nutzen globale Endpunkte, bei denen eine ausschließliche Verarbeitung in der EU nicht garantiert ist.

ALTCHA

ALTCHA ist die Lösung, die wir aktuell am häufigsten in Kundenprojekten einsetzen. Der Ansatz überzeugt uns in den Bereichen, die uns am wichtigsten sind: Datenschutz, Selbst-Hosting und Barrierefreiheit. Dass die Kernlösung Open Source ist, reduziert die Abhängigkeit von diesem einzelnen Anbieter.

Open Source und selbst gehostet

Das Widget und die Integrations-Bibliotheken sind unter MIT-Lizenz vollständig quelloffen. Die Basisversion mit Proof-of-Work-Verifizierung funktioniert ohne externe Abhängigkeiten und kann komplett auf der eigenen Infrastruktur betrieben werden. Das ist ein Vorteil, bedeutet aber auch, dass man Wartung, Updates und Sicherheit selbst verantworten muss. Für erweiterte Funktionen gibt es ALTCHA Sentinel, ein kostenpflichtiges und ebenfalls selbst gehostetes Produkt.

Datenschutzkonform und barrierefrei

Im Standardmodus erhebt ALTCHA keine Cookies, kein Tracking, kein Fingerprinting und überträgt keine Daten an Dritte. Auch bei der Barrierefreiheit überzeugt der Ansatz: Proof-of-Work arbeitet unsichtbar im Hintergrund und bietet wie bei Friendly Captcha somit eine sehr gute Ausgangssituation. ALTCHA bewirbt WCAG 2.2 AA-Konformität, eine unabhängige Zertifizierung wird ebenfalls nicht genannt. Für Risikofälle bietet Sentinel einen Code-Challenge-Modus mit Audio-Option. Dieses Feature ist somit allerdings kostenpflichtig.

Kostenlos bis kostenintensiv

Das Open-Source-Widget ist kostenlos. Das nicht über den offiziellen Plugin-Store erhältliche WordPress-Plugin (v2) beinhaltet allerdings auch Premium-Tarife ab 99 Euro pro Jahr für eine Website, Agenturen zahlen 999 Euro pro Jahr für bis zu 50 Sites. ALTCHA Sentinel startet bei 99 Euro pro Monat und skaliert auf bis zu 799 Euro pro Monat in der Enterprise-Version. Die Grenze zwischen »kostenlos« und »kostenpflichtig« ist damit weniger klar, als es auf den ersten Blick wirkt.

Probleme in der Praxis

Die Anbieter, die Barrierefreiheit, Datenschutz und Transparenz am besten lösen, können aufgrund des unsichtbaren Prüf-Verfahrens für Probleme bei der Implementierung sorgen. Zwar gibt es für alle Anbieter WordPress-Plugins oder Erweiterungen für Formulare wie Gravity Forms, im Einzelfall stolpert man jedoch immer wieder über Details.

Ein bekanntes Problem betrifft mehrstufige Formulare: Die kryptografische Challenge wird beim Laden des Formulars einmalig erzeugt und hat eine begrenzte Gültigkeitsdauer. Wenn Personen für das Ausfüllen zu lange brauchen oder die Seite zwischendurch vollständig oder teilweise neu geladen wird, kann die Challenge ablaufen oder ungültig werden. Das Formular lässt sich dann nicht absenden, obwohl die Person kein Bot ist.

Im Zusammenhang mit einstufigen Formularen ist uns das Problem nicht untergekommen.

Das Thema ist in Bewegung

Anbieter ändern ihre Preisstrukturen, Datenschutzbedingungen werden angepasst, neue Lösungen kommen auf den Markt.

Wir behalten das Thema im Blick und passen unsere Einschätzung an, wenn sich die Ausgangslage ändert. ALTCHA ist zum jetzigen Zeitpunkt die Lösung, die unsere Anforderungen am ehesten erfüllt – auch wenn wir im Projektalltag mitunter auf Einschränkungen stoßen. Am besten ist daher immer noch: kein Captcha.

Der Beitrag Captchas vs. Datenschutz, Barrierefreiheit & UX: Wie wir damit umgehen erschien zuerst auf Agentur kulturbanause.

Claude Code ist stark in der Codegenerierung, aber ohne Zugriff auf einen echten Browser fehlt der Blick auf das Laufzeitverhalten. Der Chrome DevTools MCP Server schließt diese Lücke: Er verbindet Claude Code mit den Chrome DevTools und ermöglicht so automatisierte Performance-Analysen, das Aufspüren von Konsolenfehlern oder die Überprüfung von Netzwerk-Requests.

Was bringt die Integration?

Claude Code kann mit der MCP-Integration selbstständig eine Chrome-Instanz starten, zu URLs navigieren, diese testen (z. B. mit Lighthouse) und detaillierte Berichte liefern. Praktisch bedeutet das: Ihr fragt Claude nach der Performance einer Website und bekommt Sekunden später eine Auswertung mit Metriken wie First Contentful Paint (FCP) oder Largest Contentful Paint (LCP) – inklusive konkreter Optimierungsvorschläge. Da Claude Code im Idealfall so konfiguriert ist, dass der KI-Agent die Code-Basis eures Projekts kennt (z.B. das Repository inkl. Versionierung), können Fehler automatisiert im Browser analysiert und anschließend selbstständig im Code geändert werden. Der »Plan-Mode« von Claude ist hier sehr zu empfehlen.

Installation

Die Einrichtung erfolgt über die CLI von Claude Code. Öffnet ein Terminal in eurem Projektordner und startet Claude Code:

claude

Anschließend installiert ihr den MCP Server. Der folgende Befehl lädt die aktuelle Version und registriert den Server in der Claude-Konfiguration.

claude mcp add chrome-devtools npx chrome-devtools-mcp@latest

Verbindung überprüfen

Nach einem Neustart von Claude Code könnt ihr mit /mcp prüfen, ob der Server verbunden ist.

/mcp

In der Liste sollte chrome-devtools mit dem Status »Verbunden« erscheinen. Falls nicht, wählt ihr bei der MCP-Eingabeaufforderung »Neu verbinden« – Claude übernimmt den Rest.

Beispiel-Prompt: Performance-Analyse

Wenn der Chrome MCP läuft, gebt in Claude Code einen Prompt wie diesen ein:

Überprüfe die Performance von https://kulturbanause.de mit dem Chrome DevTools MCP Server.

Claude startet daraufhin eine Chrome-Instanz im Remote-Debugging-Modus, navigiert zur URL und führt eine Performance-Messung durch. Das Ergebnis ist ein Bericht mit Ladezeiten, Ressourcen-Wasserfällen und konkreten Hinweisen – etwa »Nicht-kritisches JavaScript verzögert laden, um LCP zu verbessern.«

Zusammenfassung

Die Kombination aus Claude Code und Chrome DevTools MCP Server macht Browser-Debugging deutlich effizienter. Statt manuell zwischen Terminal und DevTools zu wechseln, Lighthouse-Test manuell anzustoßen und auf die Ergebnisse zu warten, liefert euch die KI automatisierte Analysen mit nachvollziehbaren Empfehlungen und behebt diese auf Wunsch automatisch in der verbundenen Code-Basis.

Der Beitrag Chrome DevTools MCP Server mit Claude Code verbinden erschien zuerst auf Agentur kulturbanause.

Das sog. »Mission Statement« auf einer Website beschreibt in knapper, prägnanter Form den grundlegenden Auftrag einer Organisation oder eines Unternehmens. Es beantwortet die Frage, warum es eine Organisation gibt und welchen konkreten Nutzen sie für Menschen, Kunden oder die Gesellschaft stiftet.

Auf der Startseite dient es häufig als inhaltlicher Anker: Besucherinnen und Besucher sollen innerhalb weniger Sekunden verstehen, wofür die Organisation steht und was sie im Kern tut.

Strategisch erfüllt das Mission Statement mehrere Funktionen. Es schafft Orientierung nach außen, stärkt Vertrauen und hilft bei der klaren Positionierung im Wettbewerb. Gleichzeitig wirkt es nach innen: Mitarbeitende, Ehrenamtliche oder Partner können sich an der formulierten Mission ausrichten und Entscheidungen daran messen. Ein gutes Mission Statement ist damit kein reiner Image-Text, sondern ein strategisches Kommunikationsinstrument, das Haltung, Zweck und Handlungsrahmen sichtbar macht.

Auf einzelnen Unterseiten gibt es mitunter etwas ähnliches in Form eines sog. tl;dr.

Wie sollte ein Mission Statement formuliert sein?

Ein wirkungsvolles Mission Statement ist klar, verständlich und aktiv formuliert.

Es verzichtet auf Fachjargon und Marketingfloskeln und spricht stattdessen eine eindeutige Sprache. Im Mittelpunkt stehen nicht die Organisation selbst oder abstrakte Eigenschaften, sondern das konkrete Wirken und der Nutzen für andere.

Inhaltlich sollte ein Mission Statement idealerweise drei Fragen beantworten:

• Was tun wir?
• Für wen tun wir es?
• Und warum ist das wichtig?

Je nach Kontext kann auch der Wertebezug eine Rolle spielen, etwa bei gemeinnützigen Organisationen oder Marken mit gesellschaftlichem Anspruch. Wichtig ist dabei, dass der Text realistisch bleibt und zum tatsächlichen Handeln passt.

Beispiele für gute Mission Statements

Gute Mission Statements sind oft überraschend schlicht. Sie machen keine Versprechen, die erklärt werden müssen, sondern formulieren einen klaren Kern. Ein Beispiel aus dem gemeinnützigen Bereich wäre:

»Wir unterstützen Menschen in schwierigen Lebenslagen und helfen dort, wo Hilfe gebraucht wird.«

Im unternehmerischen Kontext könnte ein Mission Statement lauten:

»Wir entwickeln digitale Lösungen, die Arbeit einfacher und effizienter machen.«

Auch emotionalere Varianten können funktionieren, sofern sie konkret bleiben:

»Wir glauben daran, dass jeder Mensch Zugang zu guter Bildung haben sollte – und arbeiten jeden Tag daran, das möglich zu machen.«

Die Beispiele ähneln sich insofern, als dass sie ohne Zusatzwissen verständlich sind und sofort ein Bild davon vermitteln, wofür die Organisation existiert.

Was sollte vermieden werden?

Häufig scheitern Mission Statements daran, dass sie zu vage, austauschbar oder selbstbezogen formuliert sind. Aussagen wie »Wir sind ein innovatives Unternehmen mit höchsten Qualitätsansprüchen« sagen wenig über den tatsächlichen Zweck der Organisation aus und könnten auf nahezu jede Website passen. Auch reine Imagebeschreibungen wie »traditionsreich und modern zugleich« sind für sich genommen kein Mission Statement, da sie weder Handeln noch Nutzen klar benennen.

Ebenso problematisch sind überladene Sätze, die mehrere Absätze benötigen, um erklärt zu werden, oder Mission Statements, die interne Ziele/Strukturen, Marktführerschaft oder Wachstumsambitionen in den Vordergrund stellen, statt den Mehrwert für andere. Ein Mission Statement ist keine Vision, kein Leitbild und keine Marketingkampagne – sondern eine präzise Antwort auf die Frage nach dem Sinn und Auftrag der Organisation.

Auf der Startseite eine Website kann es wesentlich dazu beitragen, dass die Absprungrate sinkt und Menschen sich mit dem Angebot beschäftigen.

Der Beitrag Was ist das Mission Statement auf einer Website – und welchen strategischen Nutzen hat es? erschien zuerst auf Agentur kulturbanause.