Webdesign mit Figma: Schritt für Schritt vom Briefing bis zur Übergabe

Webdesign mit Figma heißt: Sie planen, gestalten, testen und übergeben jede Ansicht einer Website in einer gemeinsamen Datei, bevor jemand Produktionscode schreibt. In diesem Leitfaden zeige ich die Reihenfolge aus meinen eigenen Projekten: Briefing, Sitemap, Wireframe, Designsystem, responsive Layouts mit Auto Layout, Prototyp und Übergabe im Dev Mode.

Das ist keine Funktionsübersicht. Ich verwende die genauen Begriffe aus dem offiziellen Hilfecenter von Figma, konzentriere mich aber auf Entscheidungen. Was kommt zuerst, was können Sie weglassen, und was soll jeder Schritt liefern? So wissen Sie jederzeit, wo Ihr Projekt steht, egal ob Sie selbst gestalten oder mit einer Designerin arbeiten.

Wie funktioniert Webdesign mit Figma Schritt für Schritt?

Webdesign mit Figma folgt sieben Schritten: ein Briefing mit klaren Zielen, eine Sitemap mit Seiten und Vorlagen, ein graues Wireframe, ein Designsystem aus Variables und Components, responsive Ansichten mit Auto Layout, ein klickbarer Prototyp und die Übergabe im Dev Mode. Jeder Schritt liefert also die Grundlage für den nächsten.

Abkürzungen sind verlockend. Viele Teams gestalten zum Beispiel sofort eine farbige Startseite, und dann passt der echte Text nicht hinein. Deshalb erledige ich die ersten beiden Schritte außerhalb von Figma, in einem einfachen Dokument. Wenn ich die Arbeitsfläche öffne, weiß ich bereits, was ich zeichne.

Die folgenden Abschnitte gehen die Schritte der Reihe nach durch. Zu jedem Schritt erkläre ich, welche Funktion ich nutze, warum ich sie nutze und welches Ergebnis das Projekt weiterbringt. Am Ende finden Sie zudem den gesamten Ablauf in einer Tabelle.

Warum brauchen Sie ein Briefing, bevor Sie Figma öffnen?

Ein Briefing ist ein kurzes Dokument, das festhält, was das Design erreichen soll. Ohne Briefing wird jede Stunde in Figma zur Geschmacksdebatte. Denn für die Frage „Sieht das gut aus?" gibt es keinen Maßstab. Für die Frage „Erreichen mehr Besucher das Angebotsformular?" dagegen schon.

Mein Briefing enthält diese Punkte:

• Die Aufgabe der Website in einem Satz und die wichtigste Conversion (Angebot, Termin, Kauf, Anruf).
• Die Zielgruppe, ihre ersten drei Fragen und die Einwände, die sie bremsen.
• Vorhandene Markenelemente: Logo, Farben, Schriften und Fotoarchiv.
• Drei Websites, die dem Kunden gefallen, und drei, die ihm nicht gefallen, jeweils mit Begründung.
• Technische Grenzen: das CMS, die Sprachversionen und die Schnittstellen.

Nehmen Sie sich vor allem für die Zielgruppe Zeit. Die passenden Fragen finden Sie in meiner Anleitung zur Zielgruppenanalyse. Für die Conversion hilft Ihnen mein Beitrag, wie Sie Conversion Ziele festlegen. Zudem beginne ich kein Wireframe, bevor der Kunde das Briefing freigibt. Diese eine Regel spart erfahrungsgemäß mehr Korrekturschleifen als jedes Werkzeug.

Wie erstellen Sie eine Sitemap und ein Seiteninventar?

Eine Sitemap ist ein Baum, der alle Seiten und ihre Beziehungen zeigt. Für das Design hat sie allerdings eine besondere Aufgabe: Sie zeigt, wie viele Vorlagen Sie brauchen. Eine Firmenwebsite mit fünfzehn Seiten kommt meist mit vier oder fünf Vorlagen aus, etwa Startseite, Leistungsseite, Übersicht, Artikel und Kontakt.

Ich zeichne die Sitemap in FigJam oder auf einer eigenen Seite in der Figma Datei. Neben jede Box notiere ich dann den Suchbegriff und die wichtigste Handlung dieser Seite. Somit treffen sich Design und SEO von Anfang an am selben Tisch. Für die Verteilung der Suchbegriffe nutze ich Keyword Mapping.

Planen Sie einen großen Katalog oder viele Kategorien, zählt die Tiefe der Hierarchie noch mehr. Wenden Sie in diesem Fall die Regeln aus meinem Beitrag zur Kategoriestruktur für große Websites an, bevor Sie gestalten. Sonst zeichnen Sie Menüs und Filter später neu.

Außerdem halte ich schon hier die Sonderzustände jeder Vorlage fest. Ein leeres Suchergebnis, ein ausverkauftes Produkt und die Bestätigung nach dem Formularversand brauchen jeweils ein eigenes Design. Listen Sie diese früh auf, dann fragt in der Entwicklung niemand mehr, wie dieser Bildschirm aussehen soll. Kurz gesagt: Die Sitemap wirkt wie eine Vereinbarung über den Umfang.

Das Ergebnis dieses Schritts sind zwei Listen: Seiten und Vorlagen. Die Vorlagenliste bestimmt zudem die Arbeitsreihenfolge in Ihrer Datei.

Worauf sollten Sie sich beim Wireframe in Figma konzentrieren?

Ein Wireframe ist ein schlichtes Gerüst ohne Farbe und Dekoration. Es zeigt also die Reihenfolge und Priorität der Inhaltsblöcke. In dieser Phase spreche ich weder über Farben noch über Fotos oder Schriften. Stattdessen suche ich drei Antworten: Was sollen Besucher zuerst sehen, in welcher Reihenfolge überzeugen sie sich, und wo steht der wichtigste Button?

Graue Flächen, eine Schrift und einfache Frames reichen daher völlig aus. Verwenden Sie trotzdem Texte, die dem echten Inhalt nahekommen. Eine Leistungsseite mit Lorem ipsum läuft fast immer über, sobald der echte Text kommt. Deshalb bitte ich den Kunden um einen groben Textentwurf oder schreibe die Überschriften selbst.

Zunächst zeichne ich das Wireframe in mobiler Breite. Passt ein Block nicht auf einen schmalen Bildschirm, bringt er auch auf dem Desktop wenig. Diese Logik erkläre ich ausführlich in meinem Beitrag Was ist Mobile First Design.

Sie können auch drei oder vier Wireframes mit einfachen Verbindungen klickbar machen. So versteht der Kunde den Ablauf besser. Animationen füge ich hier allerdings nicht hinzu, denn das einzige Ziel ist die Bestätigung der Reihenfolge.

Diesen Schritt schließe ich mit einem kurzen Abstimmungstermin ab. Steht die Reihenfolge fest, geht es im visuellen Design nur noch um das Aussehen. Die Strukturdebatte kommt somit nicht zurück.

Wie sollten Sie eine Datei in Figma organisieren?

Die Dateistruktur entscheidet vor allem, wie schnell Sie im zweiten Projektmonat arbeiten. Die Empfehlungen von Figma zur Übergabe an Entwickler zielen in dieselbe Richtung: Seiten klar benennen, Ebenen sinnvoll benennen und zusammengehörige Ansichten in Sections gruppieren.

Meine Standardstruktur sieht so aus:

1. Cover: Projektname, Status und letzte Änderung.
2. Briefing und Sitemap: eine kurze Zusammenfassung der freigegebenen Entscheidungen.
3. Wireframes: mobile und Desktop Gerüste.
4. Designsystem: Farben, Typografie, Abstände und Components.
5. Ansichten: eine Section pro Vorlage, darin die Breakpoints.
6. Prototyp: verbundene Abläufe.
7. Archiv: verworfene Varianten.

Automatische Namen wie „Frame 427" lasse ich nie stehen. Eine Karte heißt bei mir zum Beispiel „card/service", ein Titel „hero/title". Entwickler sehen diese Namen im Dev Mode, denn dort arbeiten sie. Namen nahe an den späteren CSS Klassen beschleunigen daher die Abstimmung. Auch das Archiv zählt: Wer alte Versionen dorthin verschiebt statt sie zu löschen, rettet den Tag, wenn der Kunde „die erste Version zurück" möchte.

Wo beginnt ein Designsystem: Farbe, Schrift und Abstand?

Im Webdesign mit Figma sammelt ein Designsystem alle wiederkehrenden Entscheidungen einer Oberfläche an einem Ort. Ich baue es selbst für kleine Firmenwebsites auf, weil es sich schnell auszahlt. Ohne System bringt jede neue Seite einen neuen Grauton und einen neuen Abstandswert mit.

Zunächst definiere ich die Farbpalette. Die Markenfarben dienen als Primärfarben, danach erstelle ich hellere und dunklere Abstufungen. Anschließend vergebe ich Rollen: Text, Hintergrund, Rahmen sowie Statusfarben für Erfolg, Warnung und Fehler. Farbcodes vergleichen und Abstufungen testen können Sie mit meinem Tool für HTML Farbcodes.

Für die Typografie lege ich dann eine Skala fest: Fließtext, Kleintext und vier bis fünf Überschriftenebenen. Den Fließtext halte ich gut lesbar und den Zeilenabstand großzügig. Für Abstände wähle ich eine Reihe aus Vielfachen von 4 oder 8. Somit folgen Padding und Gap einem System statt zufälligen Zahlen.

Alle diese Entscheidungen stehen auf einer einzigen Seite namens „Designsystem". Neue Designer oder Entwickler sollten die Regeln des Projekts dort in zehn Minuten verstehen.

Variables oder Styles: Was nutzen Sie wann?

Figma bietet zwei Wege, Designentscheidungen zu speichern, und der eine ersetzt den anderen nicht. Laut der Figma Seite zum Unterschied zwischen Variables und Styles bündeln Styles mehrere Werte und wenden sie gemeinsam an. Variables speichern dagegen einzelne Werte, die sich je nach Kontext ändern können.

Es gibt vier Arten von Variables: Color, Number, String und Boolean. Sie ordnen sie in Collections, und jede Collection kann mehrere Modes enthalten, etwa hell und dunkel oder mobil und Desktop. Schalten Sie einen Frame in den dunklen Mode, zeigen alle verknüpften Ebenen ihren dunklen Wert.

Meine Faustregel lautet also: Rohwerte als Variables, Text und Effektkombinationen als Styles. Wie Figma auf derselben Seite schreibt, können Variables keine Farbverläufe speichern. Verläufe bleiben deshalb Styles.

Wie richten Sie Components und Variants ein?

Ein Component ist ein Baustein, den Sie einmal gestalten und überall als Instance wiederverwenden. Ändern Sie das Hauptcomponent, aktualisiert Figma alle Instances. Buttons, Formularfelder, Karten, Menü und Footer stehen bei mir immer ganz oben auf der Liste.

Eine Variant fasst verschiedene Zustände desselben Components in einem Component Set zusammen. Die Anleitung zu Variants von Figma erklärt das mit Eigenschaften und Werten. Ein Button hat zum Beispiel die Eigenschaften Size, State und Color, und State enthält Werte wie Default, Hover, Pressed und Disabled.

Darauf achte ich beim Aufbau:

• Standardnamen wie „Property 2" lasse ich nie stehen, stattdessen nutze ich klare Namen wie „Größe" oder „Zustand".
• Verschiedene Icons gruppiere ich nicht als Variants, denn Figma empfiehlt Variants nur für Größen desselben Icons.
• Ich ordne Variants in Zeilen und Spalten an, damit fehlende Kombinationen sofort auffallen.
• Jedes Component bekommt eine kurze Beschreibung: wann es passt und ein Hinweis zur Barrierefreiheit.

Buttons verdienen besondere Sorgfalt, weil sie den Verkauf erledigen. Für Text, Farbe und Platzierung hilft Ihnen mein Beitrag mit CTA Button Beispielen.

Wie bauen Sie responsive Layouts mit Auto Layout?

Auto Layout ist die Funktion, die Objekte in einem Frame nach Regeln anordnet und den Frame bei geänderten Inhalten automatisch anpasst. Sie funktioniert also ähnlich wie Flexbox in CSS. Die Anleitung zu Auto Layout nennt vier Flows: Vertical, Horizontal, Wrap und Grid.

Drei Größeneinstellungen steuern das responsive Verhalten. Hug contents hält einen Frame so klein wie möglich um seine Inhalte. Fill container dehnt ein Objekt über den gesamten freien Platz im übergeordneten Frame. Fixed hält die Größe dagegen konstant. Zusätzlich können Sie Mindest und Höchstwerte für Breite und Höhe festlegen.

Konkret baue ich es so auf. Der Seitenframe hat eine feste Breite. Der Inhaltscontainer nutzt Fill container mit einer maximalen Breite. Karten liegen in einem horizontalen Flow mit aktiviertem Wrap. Ziehe ich den Frame schmaler, rutschen die Karten von selbst in die nächste Zeile. Deshalb muss ich denselben Baustein nicht doppelt für Desktop und Mobil zeichnen.

Padding und Gap verknüpfe ich zudem mit Number Variables. Außerdem gibt es die Option „Ignore auto layout", früher Absolute Position. Ich nutze sie nur für Badges oder Eckmarken außerhalb des Flows. Setzen Sie sie zu oft ein, zerstören Sie das responsive Verhalten selbst.

Wie wählen Sie Breakpoints im Webdesign mit Figma?

Ein Breakpoint ist eine Bildschirmbreite, an der sich das Layout ändert. In Figma lege ich für jeden Breakpoint einen eigenen Frame an, die Components bleiben aber gleich. Nur die Layoutregeln ändern sich, also bleibt das System stabil. Meist reichen drei Frames: Mobil, Tablet und Desktop.

Wählen Sie die Breiten nach dem Inhalt statt nach einer Geräteliste. Die Breite, ab der ein dreispaltiges Kartenraster eng wirkt, ist zum Beispiel ein natürlicher Breakpoint. Danach gleiche ich die Werte mit dem CSS Framework der Entwickler ab.

Hier helfen die Modes der Variables sehr. Legen Sie für Abstände und Schriftgrößen die Modes „mobil" und „Desktop" an, dann ändert ein Wechsel des Modes alle Werte auf einmal. Statt Überschriften auf jedem Bildschirm von Hand zu korrigieren, steuern Sie sie somit über das System.

An jedem Breakpoint prüfe ich dieselben Punkte. Was passiert mit dem Menü? Läuft die Tabelle über? Nehmen Formularfelder die volle Breite ein? Sind die Buttons groß genug für den Daumen? Die mobile Seite behandle ich ausführlicher in meinem Beitrag zu Mobile First Design.

Wie gehen Sie von der Startseite zu den Unterseiten über?

Steht das System, beginne ich mit dem visuellen Design. Die Reihenfolge ist immer gleich: zuerst die Vorlage mit dem meisten Traffic und den meisten Components, danach der Rest. In den meisten Projekten ist das die Startseite oder die wichtigste Leistungsseite.

Entsteht beim ersten Template ein neuer Baustein, verschiebe ich ihn sofort auf die Seite mit dem Designsystem. Einzelstücke sammle ich nicht in den Ansichten. Sonst kopiere ich beim zweiten Template denselben Baustein aus einer Ansicht, und die Inkonsistenz beginnt.

In dieser Phase achte ich außerdem auf die Fotos. Echte Aufnahmen vom Team, vom Produkt oder vom Betrieb schaffen mehr Vertrauen als Stockbilder. Daher lege ich Platzierung und Seitenverhältnisse in Figma fest und plane danach die Fotoliste.

Formulare brauchen allerdings eigene Aufmerksamkeit. Die Zahl der Felder, der Ort der Fehlermeldungen und der Text der Bestätigung beeinflussen direkt, wie viele Anfragen die Website bringt. Hier folge ich den Regeln aus meinem Beitrag, wie Sie ein Formular optimieren. Nach jeder Vorlage stelle ich das Ergebnis dem Kunden in einem kurzen Video vor. Das schriftliche Feedback kommt dann deutlich klarer zurück.

Welche Prüfungen zur Barrierefreiheit gehören in die Datei?

Barrierefreiheit beim Aufbau der Components zu prüfen, kostet weit weniger als eine Korrektur nach dem Launch. Für das Web gilt vor allem der Standard WCAG. Das Kontrastkriterium der WCAG 2.2 verlangt mindestens 4.5:1 für normalen Text und 3:1 für großen Text.

Zudem führte WCAG 2.2 ein Kriterium zur Zielgröße ein (2.5.8). Es verlangt Klickflächen von mindestens 24 mal 24 CSS Pixeln oder genügend Abstand drumherum. Buttons und Iconlinks gestalte ich großzügiger, vor allem im mobilen Menü.

Meine Prüfungen in Figma:

• Beim Festlegen der Farbrollen messe ich den Kontrast jedes Paars aus Text und Hintergrund.
• Zustände wie Hover, Focus und Disabled zeichne ich als Variants; vor allem der Tastaturfokus muss sichtbar bleiben.
• Fehlermeldungen zeige ich mit Text und Icon, nicht nur mit roter Farbe.
• Die Überschriftenebene schreibe ich in den Ebenennamen, damit die Entwickler das richtige Tag wählen.

Diese Prüfungen stützen auch die SEO. Gut lesbarer Text und eine klare Überschriftenstruktur helfen Menschen und Suchmaschinen gleichermaßen. Wie Sie beides ausbalancieren, beschreibe ich im Beitrag UX und SEO in Einklang bringen.

Wie verbinden Sie einen Prototyp, und was soll er zeigen?

Ein Prototyp macht also aus statischen Ansichten einen klickbaren Ablauf. In Figma fügen Sie einem Objekt über den Tab Prototype eine Interaktion hinzu. Jede Interaktion besteht dann aus einem Trigger und einer Action.

Laut der Figma Seite zu Prototyp Triggern sind On click (mobil On tap), While hovering, Mouse enter, Mouse leave und After delay die gängigsten. Bei After delay geben Sie die Dauer in Millisekunden an. Wichtig ist eine Grenze: On click und While hovering funktionieren nicht gemeinsam am selben Objekt. Stattdessen nutzen Sie Mouse enter und Mouse leave.

Bei den Actions verwende ich meist Navigate to für den Wechsel zwischen Frames. Zudem nutze ich Overlays für Popups und Links zu externen Adressen. Smart animate erkennt Ebenen mit gleichem Namen in verschiedenen Frames und glättet den Übergang. Auch deshalb lohnen sich einheitliche Ebenennamen.

Trotzdem verbinde ich nicht alles. Ein Prototyp sollte nur die kritischen Abläufe zeigen: von der Startseite zur Leistung, von der Leistung zum Formular und vom Formular zur Dankeseite. Diese drei oder vier Abläufe reichen für Tests völlig aus.

Mit wem und wie testen Sie den Prototyp?

Ein Test zeigt zunächst, wie das Design bei echten Nutzern funktioniert. Die Nielsen Norman Group vertritt seit Langem die Position, dass kleine, wiederholte Tests mit wenigen Personen mehr Probleme finden als ein großer Einzeltest. Daher arbeite ich pro Runde mit einer Handvoll Personen und wiederhole die Runden nach Bedarf.

Zunächst wähle ich Teilnehmende nahe an der Zielgruppe. Das eigene Team des Kunden oder befreundete Designer eignen sich schlecht, denn sie kennen die Ansichten bereits. Jede Person bekommt eine Aufgabe, etwa „Fordern Sie ein Angebot bei dieser Firma an". Danach beobachte ich, ohne einzugreifen.

Ich notiere drei Dinge:

1. Wo zögerte die Person oder ging zurück?
2. Welchen Text übersprang sie, und welchen las sie zweimal?
3. Hat sie die Aufgabe gelöst, und mit wie vielen Klicks?

Für Tests aus der Ferne reicht der Link zum Prototyp. Die Person öffnet ihn im Browser, während ich per Bildschirmfreigabe zusehe. Anschließend ordne ich die Erkenntnisse nach Priorität und übertrage sie ins Designsystem oder in die betroffene Vorlage. Meine häufigste Änderung nach einem Test? Einfachere Buttontexte und weniger Formularfelder.

Was bietet der Dev Mode bei der Übergabe an Entwickler?

Der Dev Mode ist die Oberfläche von Figma, mit der Entwickler Designs untersuchen. Laut der Anleitung zum Dev Mode steht er in allen kostenpflichtigen Tarifen zur Verfügung und erfordert einen Full Seat oder einen Dev Seat. Entwickler sehen dort Maße, Farben, Namen der Variables und automatisch erzeugten Code.

Diese Funktionen helfen bei der Übergabe am meisten:

• Status Ready for dev: Sie markieren einen Frame, ein Component, eine Instance oder eine Section als fertig, also muss niemand raten.
• Annotations: Sie ergänzen Maße, Verhalten und besondere Hinweise direkt am Design.
• Codeansicht: automatisch erzeugter Code für CSS, iOS und Android, mit wählbarer Sprache und Einheit.
• Compare changes: zeigt die Unterschiede zu einer früheren Version.
• Figma for VS Code: Entwickler prüfen die Datei, ohne den Editor zu verlassen.

Mit Code Connect zeigt ein Team zudem echten Komponentencode im Dev Mode. Laut Figma steht das in den Tarifen Organization und Enterprise bereit. In kleinen Projekten brauche ich es selten. Kopieren Sie außerdem das erzeugte CSS nicht unverändert. Dieser Code ist ein Ausgangspunkt, kein Produktionscode.

In welchen Formaten exportieren Sie Bilder und Icons?

Figma exportiert konkret PNG, JPG, SVG und PDF. Der Dev Mode erkennt zudem Icons und listet sie als herunterladbare Assets. Trotzdem entscheide ich als Designer, welches Asset in welchem Format die Datei verlässt.

Meine Grundregel: Icons und Logos als SVG, Fotos als JPG oder als hochwertige Quelle, die der Entwickler in WebP umwandelt, und Bilder mit Transparenz als PNG. Jedes Asset bekommt in der Datei seine Exporteinstellung. Dann muss der Entwickler nicht einzeln nachfragen.

Das Bildgewicht wirkt sich zudem direkt auf die Ladezeit aus. Ein Heldenbild, das Sie in 2x aus Figma exportieren, wiegt schnell mehrere Megabyte. Vor dem Launch können Sie Bilder mit meinem Tool zum Bild verkleinern komprimieren. Wie die Ladezeit Rankings und Umsatz beeinflusst, erkläre ich im Beitrag Wie beeinflusst die Ladezeit SEO.

Schließlich setze ich Favicon und Vorschaubild für Social Media auf die Exportliste. In den meisten Projekten warten diese kleinen Assets bis zum letzten Tag und entstehen dann in Eile. Wer sie zusammen mit dem Designsystem vorbereitet, hält die Marke konsistent.

Welche Prozessfehler bremsen Webdesign mit Figma?

Dieser Abschnitt behandelt keine Usability Fehler der Oberfläche selbst. Diese beschreibe ich in einem eigenen Beitrag über UX Fehler, die Umsatz kosten. Hier geht es um Prozessfehler, denn sie ziehen ein Projekt oft um Wochen in die Länge.

• Ohne Briefing mit dem visuellen Design beginnen und die Struktur anhand bunter Ansichten diskutieren.
• Ansichten ohne Components zeichnen; zehn Seiten später existiert derselbe Button in sieben Versionen.
• Auto Layout auslassen; jede Textänderung heißt dann Handarbeit an allen Ansichten.
• Nur den Desktop gestalten und das mobile Layout den Entwicklern überlassen.
• Ebenen nicht benennen; wer im Dev Mode „Group 12" sieht, muss raten.
• Zustände wie Hover, Focus, Fehler und leere Ansicht vergessen.
• Den Prototyp ohne Test zur Freigabe schicken.

Jeder Punkt dieser Liste entsteht, weil ein Schritt aus den vorherigen Abschnitten fehlt. Die Lösung ist daher kein neues Werkzeug, sondern die Treue zur Reihenfolge. In meinen Projekten gehe ich diese Liste am Ende jeder Phase durch. Fehlt etwas, gehe ich nicht weiter.

Prozess im Überblick: Welche Phase liefert welches Ergebnis?

Die folgende Tabelle fasst die Schritte mit ihren Ergebnissen und Freigaben zusammen. Nutzen Sie sie also als Checkliste für Ihr eigenes Projekt.

Die Dauer hängt vom Umfang ab. Als Startwert aus meiner Praxiserfahrung, ohne Garantie: Bei einer Firmenwebsite mit fünf Vorlagen brauchen Briefing und Sitemap einige Tage, Designsystem und Ansichten einige Wochen. Tests und Übergabe planen Sie dann zusätzlich ein.

Wann lohnt sich professionelle Hilfe beim Webdesign mit Figma?

Figma selbst ist nicht schwer zu lernen, und die Grundlagen im Webdesign mit Figma sitzen schnell. Sie starten im kostenlosen Tarif und verstehen die Grundlagen in wenigen Tagen. Schwierig ist allerdings nicht das Werkzeug, sondern die Entscheidung: Welcher Block kommt zuerst, was steht auf welchem Button, welcher Baustein gehört ins System? Dafür braucht es Erfahrung.

Selbst umsetzen können Sie einen One Pager, eine kleine Anpassung an einer bestehenden Vorlage oder einen schnellen internen Prototyp. Professionelle Hilfe empfehle ich dagegen für eine Firmenwebsite, die Umsatz bringen soll, für mehrsprachige Auftritte, für E-Commerce Abläufe und für Projekte mit mehreren Entwicklern.

In meinem Angebot für Webdesign folge ich genau der Reihenfolge aus diesem Beitrag und übergebe Ihnen am Ende die Datei. Wenn Sie die Conversion Seite des Designs vertiefen möchten, ist mein Beitrag zu conversionorientiertem Webdesign ein guter nächster Schritt. Für Ihr Projekt erreichen Sie mich über die Kontaktseite.