Signal dossier // 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. Für Agentur-Alltag und Produktarbeit ist es Reibung.
Live-Browser statt Screenshot-Upload
Der alternative Ansatz: Die Website wird in einem echten Browser geladen und auf 3D-Gerätemodelle gelegt. Du navigierst zum gewünschten Zustand — auch angemeldet — und exportierst 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,
- du einen Stand nur einmal brauchst,
- kein Login und kein Staging im Spiel sind.
Live-Browser-Mockups, wenn:
- du hinter Authentifizierung oder auf Staging musst,
- Desktop und Mobile echte Layouts zeigen sollen,
- sich der Stand häufig ändert,
- du PNG/JPEG in festen Formaten (bis 8K, optional transparent) brauchst.
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 du mitnimmst
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.
Signal vollständig empfangen