Wie lässt sich mit einem globalen SaaS-System für die Website-Erstellung die Qualität der responsiven Darstellung überprüfen?

Wenn die Seite auf dem Desktop normal aussieht, auf dem Smartphone jedoch die Produkttabelle überläuft oder die Anfrage-Schaltfläche verdeckt wird, liegt das oft nicht daran, ob es eine „mobile Version“ gibt. Vielmehr wurden Vorlage, Inhalte und Interaktionen nicht gemeinsam angepasst. Um die Responsive-Darstellung eines globalen Website-Baukastens als SaaS-System zu prüfen, reicht eine Vorschau im Backend nicht aus. Die Abnahme sollte anhand echter Geschäftsseiten erfolgen und stufenloses Verändern der Fenstergröße, Bedienung auf realen Geräten, Sprachwechsel und den vollständigen Conversion-Prozess umfassen.

Entscheidend ist: Sind die Inhalte bei unterschiedlichen Ansichtsfenstern vollständig lesbar, lassen sich wichtige Aktionen ausführen und können Nutzer ihre Aufgaben erledigen? Bei der Auswahl sollten Sie vom Anbieter eine bearbeitbare und veröffentlichbare Testumgebung verlangen, statt sich nur eine ausgewählte Demo-Startseite zeigen zu lassen.

Zuerst festlegen, was getestet wird – damit nicht nur eine ansprechende Startseite abgenommen wird

Die Testseiten sollten mindestens die Startseite, Produktübersichten, Produktdetailseiten und Anfrage- oder Checkout-Seiten umfassen. Jede Seitenart sollte mit Inhalten befüllt werden, die dem Stand kurz vor der Veröffentlichung entsprechen, darunter längere Produktnamen, echte Spezifikationstabellen, mehrere Bilder und Pflichtformulare. Dass sich eine leere Vorlage automatisch anpasst, bedeutet nicht, dass sie auch mit echten Geschäftsinhalten stabil bleibt.

Als Ausgangspunkt für eine Testmatrix können Ansichtsfensterbreiten von 320, 375, 768, 1024 und 1440 CSS-Pixeln gewählt und je nach den von Zielkunden verwendeten Geräten ergänzt werden. Dies sind lediglich Testwerte, keine verbindlichen Layout-Breakpoints. Auch Browser-Zoom, Systemschriftgröße und Hoch- oder Querformat sollten dokumentiert werden, damit sich Probleme reproduzieren lassen.

• Desktop: Prüfen, ob Inhalte bei breiten Ansichten übermäßig gestreckt werden und ob das Verhältnis von Navigation, Seitenleiste und Haupttext angemessen ist.
• Mobilgeräte: Schmale Ansichten, gängige Smartphone-Größen und Querformat abdecken; besonders Menüs, Overlays und Eingabefelder prüfen.
• Browser: Entsprechend dem Zielmarkt gängige Browser-Engines auswählen und zusätzlich auf echten Smartphones testen. Simulierte Ansichtsfenster bilden das Verhalten von Touch-Bedienung, Bildschirmtastatur und Browserleiste nicht vollständig ab.

Das Fenster ziehen: So lassen sich Probleme leichter erkennen als mit einigen voreingestellten Gerätegrößen

Öffnen Sie die Entwicklertools des Browsers und verändern Sie langsam die Breite des Ansichtsfensters. Beobachten Sie, wie das Layout von mehreren Spalten zu einer einzelnen Spalte wechselt. Entscheidend ist nicht die Anzahl der Breakpoints, sondern ob es dazwischen zu zusammengedrängtem Text, überlappenden Karten, umgebrochenen Navigationsleisten oder plötzlich verschwindenden Schaltflächen kommt. Notieren Sie bei Auffälligkeiten die problematische Breite und passen Sie die Ansicht in diesem Bereich wiederholt an.

Bevor beispielsweise eine vier-spaltige Produktübersicht auf zwei Spalten umgestellt wird, können die Karten bereits zu schmal sein, um die Schaltflächen vollständig aufzunehmen. In diesem Fall sollten die Spaltenbreite oder die Umschaltbedingung angepasst werden, statt einfach die Schriftgröße zu verkleinern. Eine feste Kartenhöhe kann bei langen Titeln oder übersetzten Inhalten ebenfalls zu abgeschnittenem Text führen.

Prüfen Sie außerdem, ob die Seite korrekt für den Viewport konfiguriert ist und Darstellungsprobleme nicht durch das Deaktivieren der Zoomfunktion kaschiert werden. Bei vergrößerter Schrift sollte sich der Inhalt neu anordnen können und nicht aufgrund einer festen Containerhöhe verloren gehen.

Nicht nur prüfen, ob sich etwas anklicken lässt, sondern ob sich Aufgaben erledigen lassen

Auf Mobilgeräten wird am häufigsten der Zustand nach dem Öffnen der Bildschirmtastatur übersehen. Öffnen Sie das Anfrageformular, geben Sie die einzelnen Felder aus, lösen Sie die Validierung aus, korrigieren Sie Fehler und senden Sie das Formular ab. Prüfen Sie, ob das aktive Eingabefeld und Fehlermeldungen sichtbar bleiben und ob eine am unteren Rand fixierte Schaltfläche Felder verdeckt. Verwenden Sie für den Test den vereinbarten Empfangsweg und stellen Sie sicher, dass die Erfolgsmeldung mit dem tatsächlichen Empfang übereinstimmt.

Die Navigation darf nicht allein auf Mouseover basieren. Dropdown-Menüs, Sprachumschaltung und Filter müssen sich auch per Touch bedienen lassen. Zwischen benachbarten Schaltflächen sollte ausreichend Abstand sein; prüfen Sie auf echten Geräten, ob sie leicht versehentlich angetippt werden. Prüfen Sie auf dem Desktop außerdem per Tastatur die Fokusreihenfolge und ob der Fokus nach dem Schließen eines Dialogfensters an eine sinnvolle Stelle zurückkehrt.

Bei einem grenzüberschreitenden Onlineshop sollten Sie auch die Auswahl von Varianten, Änderungen am Warenkorb und den Checkout vollständig durchspielen. Bei einer B2B-Website stehen Dateianhänge, das Absenden von Anfragen und Kontaktmöglichkeiten im Mittelpunkt. Testen Sie auch mit aktivierten Drittanbieter-Chatdiensten, Cookie-Hinweisen und Marketing-Pop-ups: Dass jedes Element einzeln funktioniert, bedeutet nicht, dass es auch in Kombination funktioniert.

Mehrsprachigkeit und Ladeverhalten auf der veröffentlichten Seite prüfen

Bei globalen Websites reicht es nicht, nur die Standardsprache abzunehmen. Wählen Sie längere Übersetzungen aus, die tatsächlich veröffentlicht werden sollen, und prüfen Sie, ob Navigation, Schaltflächen und Produkttitel den Container sprengen. Bei Sprachen mit Schreibrichtung von rechts nach links, etwa Arabisch, sollten auch Leserichtung, Position der Symbole und die Kombination von Zahlen und Text geprüft werden – es genügt nicht, den Text einfach rechtsbündig auszurichten.

Die Tests müssen veröffentlichte Seiten einschließen. Eine Vorschau im Backend bildet die Auswirkungen von Caching, Bildverarbeitung und Drittanbieter-Skripten in der Regel nicht vollständig ab. Laden Sie die Seite bei begrenzter Netzwerkgeschwindigkeit erneut und beobachten Sie, ob sich Inhalte beim Laden von Bildern und Schriftarten oder beim Einblenden von Pop-ups deutlich verschieben und ob Schaltflächen, die Nutzer anklicken möchten, dadurch verdrängt werden.

Bilder sollten sich passend an den Container anpassen und bei Bedarf in geeigneter Größe geladen werden. Mit Performance-Tools können Sie LCP, CLS und INP überprüfen. Eine einzelne Laborbewertung sollte jedoch nicht als abschließendes Urteil gelten. Wenn noch keine realen Zugriffsdaten vorliegen, müssen die Testbedingungen klar angegeben und die tatsächliche Nutzungserfahrung nach dem Start weiter überprüft werden.

Bei der Auswahl die Behebung von Problemen als Abnahmekriterium festlegen

Bitten Sie den Anbieter bei gefundenen Problemen zu erläutern, ob die Ursache in der Vorlage, der Inhaltskonfiguration, dem benutzerdefinierten Code oder einer Drittanbieterkomponente liegt, und die Behebung praktisch vorzuführen. Die bloße Aussage „Responsive Design wird unterstützt“ ist nicht aussagekräftig. Entscheidend ist, ob normale Redakteure das mobile Layout anpassen können, ob Änderungen andere Sprachen beeinträchtigen und ob sie bei einem Vorlagen-Update überschrieben werden.

Im Abnahmeprotokoll sollten Seitenadresse, Version, Sprache, Gerät, Ansichtsfenster, Schritte zur Reproduktion und Screenshots festgehalten werden. Probleme wie nicht abschickbare Anfragen, unsichtbare Kerninhalte oder eine nicht schließbare Navigation sollten als Startblocker eingestuft werden. Kleinere freie Flächen oder Zeilenumbrüche ohne wesentliche Auswirkungen können später behoben werden; Verantwortliche und Umfang der Nachprüfung müssen jedoch vereinbart sein.

Ändern Sie zum Schluss in der Testumgebung einmal einen Produkttitel oder eine Spezifikationstabelle und veröffentlichen Sie die Seite erneut zum Test. Wenn bei normalen Inhaltsänderungen für jede einzelne Seite zusätzliche Stilanpassungen nötig sind, hängen die Anpassungsregeln weiterhin von manueller Pflege ab. Das sagt mehr über die langfristigen Wartungskosten des Systems aus als die Frage, wie ansprechend eine Demoseite aussieht.