"Kannst du mir zeigen, wie die Website aussieht?" – "Hier ist ein Mockup." – "Ah, sieht gut aus. Wann ist es fertig?"
Problem: Das Mockup ist nicht die Website. Es ist ein statisches Bild. Kein Klick funktioniert. Kein Text ist echt. Keine Funktion ist eingebaut.
Ein Mockup zeigt, wie etwas aussehen könnte – nicht wie es funktioniert.
Ein Mockup ist eine visuelle Darstellung eines Designs. Meist als statisches Bild.
Mockups zeigen:
• Layout und Struktur
• Farben und Schriften
• Bilder und Icons
• Proportionen und Abstände
Mockups zeigen nicht:
• Funktionen (nichts ist klickbar)
• Animationen
• Echte Inhalte (meist Platzhaltertexte)
"Kann ich das Mockup testen?" – Nein. Ein Mockup ist ein Bild.
Was du brauchst, ist ein Prototyp: Ein klickbares Modell, das Funktionen simuliert.
Mockup: Statisches Bild, zeigt Aussehen
Prototyp: Klickbar, zeigt Funktionen
"Warum steht da ‘Lorem Ipsum’?" – Weil es um das Design geht, nicht um den Text.
Aber: Wenn der echte Text viel länger ist als der Platzhalter, funktioniert das Design nicht mehr. Deshalb: Mockups mit realistischen Textmengen testen.
Ein Mockup mit 3 Zeilen Platzhaltertext ist nutzlos, wenn der echte Text 10 Zeilen hat.
50 verschiedene Versionen. Für jede Unterseite ein Mockup. Für jede Variante ein neues Bild.
Das überfordert. Besser: 3–5 Hauptseiten als Mockup. Der Rest wird im Design-System definiert.
Bevor Code geschrieben wird: Sieht das so aus, wie wir wollen? Passen Farben, Schriften, Layout?
Ein Mockup ist schnell geändert. Code nicht.
"So wird die Website aussehen." Das ist greifbarer als ein Wireframe (Skizze) und schneller als ein Prototyp.
Der Designer zeigt: So soll es aussehen.
Der Entwickler sieht: Abstände, Schriftgrössen, Farben.
Ohne Mockup: Jeder interpretiert anders.
Eine Skizze. Schwarz-weiss, ohne Details. Zeigt Struktur und Layout.
Zweck: Funktionen und Inhalte planen, bevor Design entsteht.
Ein statisches Bild. Mit Farben, Schriften, Bildern. Zeigt, wie es aussieht.
Zweck: Visuelles Design präsentieren und abstimmen.
Ein klickbares Modell. Simuliert Funktionen und Abläufe.
Zweck: Funktionen testen, bevor entwickelt wird.
Reihenfolge: Wireframe → Mockup → Prototyp → Entwicklung
Ein Wireframe plant. Ein Mockup zeigt. Ein Prototyp funktioniert.
Desktop: 1440px Breite
Tablet: 768px Breite
Mobile: 375px Breite
Mockups in echten Grössen zeigen, ob das Design funktioniert.
Nicht "Lorem Ipsum". Sondern: Echte Texte. Echte Bilder. Echte Titel.
Wenn der echte Content nicht passt → Design anpassen.
Nicht alle 50 Unterseiten. Sondern:
• Startseite
• Eine Contentseite
• Kontaktseite
• Mobile-Version
Der Rest folgt dem Design-System.
Standard für UI-Design. Kollaborativ, browserbasiert, kostenlos für kleine Teams.
Ähnlich wie Figma, aber von Adobe. Gut, wenn du schon Photoshop/Illustrator nutzt.
Mac-only. Lange Zeit der Standard, heute weniger verbreitet als Figma.
Einfach, aber limitiert. Gut für schnelle Mockups, nicht für komplexe Projekte.
Empfehlung: Figma. Kostenlos, kollaborativ, professionell.
Mockups sind sinnvoll, wenn:
• Du das Design vor der Entwicklung abstimmen willst
• Du Kunden zeigen willst, wie es aussieht
• Du Designer und Entwickler synchronisieren willst
Mockups sind überflüssig, wenn:
• Das Design schon klar ist
• Du direkt im Code designst (bei kleinen Projekten okay)
• Du nur Struktur planst (dann reicht ein Wireframe)
Ein Mockup ist kein Selbstzweck. Es ist ein Werkzeug, um Entscheidungen zu treffen.
Wir erstellen Mockups, um sicherzustellen, dass das Design funktioniert, bevor wir entwickeln. Das heisst: Mit echten Proportionen, echten Inhalten, für die wichtigsten Seiten. Kein Selbstzweck, sondern ein Werkzeug.
Falls du unsicher bist, ob du Mockups brauchst oder wie sie aussehen sollten, beraten wir dich gerne unverbindlich.

Lösungen suchen, offene Fragen klären oder direkt loslegen. Wir sind dabei und freuen uns, dich kennenzulernen.
Beim Absenden ist ein Fehler aufgetreten.
Bitte versuche es erneut oder schreib uns direkt an hello@namo.swiss.