Stehen Sie gerne 20 Minuten an der Feinkost für 10 dag Kantwurst an? In etwa…
Strikter Page-Flow – der Nachteil von Responsive Design
Mit Responsive Design ist es heute möglich, eine Webseite bzw. Webapplikation zu gestalten, die auf allen denkbaren Geräten optimal dargestellt wird und effizient nutzbar ist. Da nun immer mehr Unternehmen ihre Webseiten responsive machen wollen, gilt Responsive Design momentan wohl als heißester Trend.
Doch leider hat Responsive Web Design auch Nachteile, die man unbedingt kennen sollte. Schauen wir uns daher die Restriktion “Strikter Page-Flow” etwas genauer an.
Was bedeutet strikter Page-Flow?
Responsive Web Design vereint die User Experience der verschiedenen Kanäle, über die Unternehmen mit ihren Kunden in Verbindung treten. So wird es möglich, auf Smartphones, Tablets und am Desktop-Rechner eine einheitliche und gute User Experience zu schaffen. Durch den Einsatz von Server-Side-Components (RESS) kann die User Experience einzelner Kanäle weiter im Detail optimiert werden.
Der konkrete Nachteil dieser Vereinigung ist jedoch der damit in Kauf genommene “strikte Page-Flow”. Dies bedeutet, dass eine Webapplikation immer die gleiche Anzahl an Seiten haben muss.
Beispiel: Strikter Page-Flow
Wir designen den Checkout-Prozess eines Online-Shops, der sich auf den Verkauf von Tablets spezialisiert hat. Damit die Kunden ihre Geräte auch unterwegs nutzen und im Internet surfen können, wird beim Kauf zusätzlich ein Vertrag angeboten. Beim Checkout müssen Kunden daher mehr Daten als üblich angeben. Wir benötigen einerseits die Kundendaten, die Zahlungsinformationen und die gewünschte Versandmethode. Da wir jedoch zusätzlich einen Vertrag mit dem Kunden abschließen, muss auch geklärt werden, wie monatliche Abrechnungen bezahlt werden. Man könnte sich also folgenden Page-Flow für den Checkout-Prozess vorstellen:
- Kundendaten
- Versand
- Zahlung einmalige Kosten
- Zahlung monatliche Kosten
- Prüfen & abschließen
- Kundendaten
- Versand
- Zahlung
- Prüfen & Abschließen
Für dieses Beispiel habe ich angenommen, dass die Angabe der Zahlung sofortiger und laufender Kosten ausreichend komplex ist, sodass zwei eigene Seiten notwendig sind.
Nun haben wir den Prozess grob abgesteckt und wissen, welche Seiten wir benötigen. Aufgrund der vielen Daten, die der Kunde eingeben muss, haben wir uns für 5 Seiten im Prozess entschieden. Während es sinnvoll ist, komplexere Prozesse auf mobilen Geräten mit kleinen Bildschirmen auf mehrere Seiten aufzuteilen, könnte es auf größeren Bildschirmen zu Ineffizienz führen.
Es wäre denkbar, dass die beiden Schritte zur Angabe der Zahlung einmaliger und monatlicher Kosten ausreichend komplex sind, um auf kleinen Bildschirmen aufgeteilt zu werden. Gleichzeitig könnten jedoch beide Schritte durch den zusätzlich verfügbaren Platz auf einem großen Bildschirm in nur einem einzigen Schritt eingegeben werden. Folglich bräuchten wir 5 Schritte auf dem Smartphone, um die Komplexität heraus zu nehmen und 4 Schritte auf dem Desktop, um die Effizienz zu steigern. Der Prozess würde also auf dem Desktop so aussehen:
Hier zeigt sich nun der Nachteil von Responsive Web Design: Es ist nicht möglich, unterschiedliche Seitenanzahlen auf spezifischen Geräten zu haben – der Page-Flow ist auf jedem Gerät der selbe.
Wie sollen wir damit umgehen?
Es zeigt sich hier ein Problem, das leider nicht umgangen werden kann. Wir müssen uns daher dieser Einschränkung bewusst sein und sie von Anfang an mit berücksichtigen.
Sobald wir generelle Page-Flows gezeichnet haben, die unsere Prozesse abbilden, sollten wir Content Inventories für alle Seiten erstellen. Wir schreiben also für jede Seite auf, welche Inhalte dort auftreten werden und stellen dadurch sofort klar, wie umfangreich die Seite voraussichtlich wird.
Anschließend können wir mit Hilfe von Content-Reference-Wireframes überlegen, wie die Inhalte auf verschiedenen Bildschirmen angeordnet werden. Wir zeichnen in diesem Schritt für die voraussichtlichen Breakpoints auf, wie die großen Content-Blöcke angeordnet werden sollen. Dadurch sehen wir schon sehr früh, ob wir mit unserem Konzept auf dem richtigen Weg sind und ob der geplante Page-Flow für alle Bildschirmgrößen funktionieren wird.
Show all articles