Insights // imping.digital
Website-Mockups aus dem Live-Browser: warum Screenshots nicht reichen
Website-Mockups zeigen echte Seiten auf Geräten. Screenshot-Templates scheitern an Login, Responsive und Updates – Live-Browser lösen das.
Wer Website-Mockups braucht, kennt den Umweg: Screenshot machen, zuschneiden, in ein Geräte-Template schieben, Perspektive nachziehen. Bei jedem Text-Update von vorn. Und sobald die Seite hinter Login liegt oder nur auf Staging existiert, wird der Workflow unbrauchbar.
Website-Mockups aus dem Live-Browser lösen genau dieses Problem: Die echte Seite läuft im Browser auf dem Gerät – nicht als eingefrorener Schnappschuss.
Was sind Website-Mockups?
Ein Website-Mockup zeigt eine Website so, wie sie auf einem konkreten Gerät wirkt: MacBook, iPhone, iPad. Typische Zwecke:
- Portfolio und Case Studies
- Kunden-Pitches und Freigaben
- Social Media und Ads
- Interne Doku von Produktständen
Der Wert steckt nicht im Rahmen, sondern in der Glaubwürdigkeit des Inhalts: Wenn die Seite auf dem iPhone anders umbricht als auf dem Desktop, muss das Mockup das zeigen – nicht nur dasselbe Crop in ein anderes Gehäuse legen.
Warum Screenshot-Templates an Grenzen stoßen
Klassische Mockup-Kits (PSD, Figma, Online-Generatoren) erwarten ein fertiges Bild. Das erzeugt drei typische Lücken:
- Login und Staging: Dashboards, Kundenbereiche und interne Tools lassen sich nicht öffentlich screenshotten. Genau dort entstehen aber oft die entscheidenden Produktmomente.
- Responsive Wahrheit: Ein zugeschnittener Desktop-Screenshot im iPhone-Rahmen ist kein Mobile-Layout. Responsive Mockups brauchen die echte Viewport-Ansicht.
- Aktualität: Jede Copy-Änderung, jeder Feature-Stand bedeutet neuen Screenshot, neues Zuschneiden, neues Einsetzen.
Für einmalige Marketing-Seiten kann das reichen. Im Projektalltag und in der Produktarbeit kostet es unnötig Zeit.
Live-Browser statt Screenshot-Upload
Der alternative Ansatz: Die Website wird in einem echten Browser geladen und auf 3D-Gerätemodelle gelegt. Sie navigieren zum gewünschten Zustand – auch angemeldet – und exportieren die Szene.
Das ändert die Reihenfolge:
| Schritt | Screenshot-Workflow | Live-Browser |
|---|---|---|
| Inhalt | Bild vorbereiten | URL öffnen, navigieren |
| Geräte | Template befüllen | Responsive Ansicht pro Gerät |
| Login | Oft unmöglich | Session im lokalen Browser |
| Update | Neu fotografieren | Seite neu laden |
Kurz: Browser statt Screenshots. Die Kategorie bleibt Website-Mockup – die Quelle ist die Live-Seite.
Wann welcher Ansatz passt
Templates / Screenshot-Kits, wenn:
- die Seite öffentlich ist,
- Sie einen Stand nur einmal brauchen,
- kein Login und kein Staging im Spiel sind.
Live-Browser-Mockups, wenn:
- Sie hinter einen Login oder auf Staging müssen,
- Desktop und Mobile echte Layouts zeigen sollen,
- sich der Stand häufig ändert,
- Sie PNG/JPEG in festen Formaten (bis 8K, optional transparent) brauchen.
Praxis bei imping.digital
Für genau diesen Alltag habe ich Webdm gebaut – eine native Mac-App in den Imping Labs. Webdm lädt die Live-Website in WebKit, zeigt sie auf MacBook, iPhone und iPad und exportiert pixelgenaue Mockups. Jetzt im Mac App Store – Einmalkauf, kein Abo.
Webdm ersetzt keine Design-Tools. Es ersetzt den Screenshot-Umweg, wenn die echte Seite der Inhalt ist.
Was Sie mitnehmen
Website-Mockups sind nur so gut wie der Zustand, den sie zeigen. Screenshot-Templates skalieren schlecht mit Login, Responsive und Updates. Live-Browser bringen die echte Seite auf die Geräte – und damit glaubwürdige Mockups ohne Collage-Arbeit.
Produktseite: Webdm – Website-Mockups direkt aus dem Live-Browser. Mac App Store: Webdm – Website Device Mockups.
Danke fürs Lesen.