Klar, Responsive Webdesign ist zum Standard geworden. Keine neue Website, kein Relaunch, der nicht responsiv umgesetzt wird. Aber der Weg dahin, der Workflow, ist unterschiedlich. Teils noch geprägt durch „alte Strukturen“, teils weil es einfach so viele Möglichkeiten gibt eine moderne Website zu erstellen.

Dieser Artikel will nicht DEN Weg zeigen, eine responsive Website zu erstellen, sondern einen effektiven Weg. Einen Workflow, der sich bewährt hat und den immer mehr Agenturen und Webdesigner umsetzen.

Die Grundidee hinter Responsive Webdesign ist im Grunde, zuerst einmal, dass Web wieder zu dem zu machen, was es von Haus aus ist: Flexibel.

Das Web verändert sich

Früher, also im Web vor einigen Jahren, hat man Websites noch für feste Bildschirmgrößen gestaltet. Eine Methode, die man vor allem aus dem Printbereich übernommen hatte. Also ein Dokument mit festen Maßen zu haben. In einem Grafikprogramm (meistens Photoshop) wurden ein fixes Design entworfen, dass dann möglichst 1zu1 mit HTML und CSS umgesetzt wurde.

Man hat die Inhalte also per CSS in starres Raster gepackt hat. Denn Websites an sich sind flexibel. HTML, also die Inhalte und die semantische Struktur, passen sich eigentlich dem Browser und den Browsermaßen flexibel an.

Diese starren Seiten waren so lange „gut“, so lange es eben recht ähnliche Bildschirme gab. Die Entwicklung der vergangenen Jahre ging aber weg vom Desktop-PC hin zum mobilen Web. Es gibt nicht mehr den kleinsten gemeinsamen Nenner einer festen Bildschirmgröße, für die man Websites optimieren könnte.

Die Nutzungsszenarien sind vielfältig geworden
Es gibt im Grunde überhaupt keinen Nenner mehr, sondern einfach verdammt viele „Nutzungsszenarien“. Es ist nicht mehr eindeutig, wann, wo und wie die User die Website benutzen. Das beginnt schon bei den Nutzungsgeräten, vom Desktop-Rechner über Laptop, Netbook, Smartphone, Tablet, Phablet, Uhr, Google Glass bis zum Fernseher bekommt quasi alles, was einen Display hat, auch Internetzugang. Und die Entwicklung ist erst am Anfang. Die mobile Internet-Nutzung liegt schon seit Jahren über der stationären Nutzung.

Mit unterschiedlichen Geräten ergeben sich auch unterschiedliche Displaygrößen und unterschiedliche Eingabegeräte (neben Tastatur und Maus auch Touchscreen und Touchpad).

Und die Unterschiede werden größer:
Mobile Endgeräte, die teilweise immer kleinere Bildschirmgrößen haben, wie bspw. die Apple Watch mit 38 Millimetern Bildschirmdiagonale.

Und auf der anderen Seite immer größere und hochauflösendere Bildschirme, die wie mancher SmartTV schon bei fast zwei Metern Bildschirmdiagonale sind.

Heute hat man theoretisch alle Breiten zwischen 300 und 6.000 Pixel zu bedienen.

Ein Überblick über Endgeräte mit Android, die Vielfalt ist schier unüberschaubar.

Ein Überblick über Endgeräte mit Android, die Vielfalt ist schier unüberschaubar
Quelle: http://www.topowiki.de/wiki/RWD

Responsive ist keine Wahl mehr

Die Nutzungsszenarien sind also sehr unterschiedlich. Und genau darum geht es beim Responsive Webdesign. Eine Website nicht mehr nur für ein oder wenige Nutzungsszenarien zu optimieren, sondern für möglichst viele/alle.

Responsive kann man mit „anpassungsfähig“ übersetzen. Ein Responsive Webdesign soll gewährleisten, dass die Website unabhängig vom Ausgabegerät, von der Displaygröße optimal genutzt werden kann und optisch ansprechend dargestellt wird.

Die Website passt sich also an.

Diese Anpassung ist vor allem zuerst einmal eine technische. Dazu gehören flexibles Raster, flexible Medien und die sogenannten Breakpoints, an denen sich die Darstellung ändert.

but it also requires a different way of thinking
https://alistapart.com/article/responsive-web-design

Man sollte aber Responsive Webdesign deutlich weiter fassen, als „nur“ die Anpassung der Inhaltsdarstellung an den Viewport (möglicher Anzeigebereich von Inhalten auf einem Display).

Konzeption, die Inhalte selber und das Design sind ebenso Teil des Prozesses und sollten ebenso „anpassungsfähig“ sein.

Responsive Webesign ist eigentlich so viel mehr, als ein paar Frontend-Technologien.

Responsive Webesign ist eigentlich so viel mehr, als ein paar Frontend-Technologien.

An den oberen Ausführungen wird deutlich, dass der alte Workflow ungeeignet und ineffizient ist. Die Anforderungen haben sich geändert und dem sollte sich auch der Prozess der Website-Erstellung anpassen.

Kann man Responsive Webdesign später noch nachrüsten?
Jein, möglich ist es. Diese Anpassung ist dann aber vor allem eine technische, die dann dafür sorgt, dass die bestehende – nicht flexible – Website auf möglichst vielen Geräten und Displays gut angezeigt wird. Es ist aber mehr eine „Optimierung“, denn die ganze Website bleibt ja weiterhin für Desktop-PCs angelegt und nur die Darstellung wird angepasst.

Ein „echtes“ Responsives Webdesign, bei dem auch die Inhalte, die Menüs, die Performance usw. berücksichtigt wird, ist dies dann weniger. Daher sollte Responsive Webdesign von Anfang berücksichtigt werden!

Die Änderungen zwischen dem alten und dem neuen Workflow im Detail:

Der alte Workflow

Der klassische Workflow stammt aus der Zeit, als für bestimmte Viewports und feste Raster gestaltet wurde. Der Ablauf sah im einzelnen meistens folgendermaßen aus:

1. Planung / Konzeption

Die Website wird geplant. Ziele, Zielgruppen usw. werden definiert und die Inhalte zusammengetragen.

2. Scribbles / Wireframes

Anhand der Ideen und Inhalte werden dann erste Skizzen und Entwürfe erstellt.
Mal per Hand, mal digitale Wireframes.

3. Design

Anhand der Scribbles, der Wireframes wird dann das Layout der Website gestaltet, meistens in Photoshop, manchmal aber auch in einem anderen Grafikprogramm.

Auf jeden Fall wird das Design pixelgenau gestaltet. Der Kunde erhält die einzelnen gestalteten Seiten als Bildgrafik zur Abnahme.

4 Technische Umsetzung / Programmierung

Nach der Freigabe der einzelnen Layouts durch den Kunden, werden die Design in HTML, CSS & Co. umgesetzt. Hierbei wurde vor allem darauf geachtet, dass das Design 1zu1 umgesetzt wurde, auch möglichst pixelgenau und in allen Browsern gleich aussehend. Nicht selten, das Kunden genau auf diese „Gleichheit“ besonders geachtet haben.

5. Abnahme und Launch

Nach eventuellen Korrekturen wird die fertige Website abgenommen und online gestellt. Fertig.

Der klassische Webdesign-Workflow

Der „alte“ Workflow: Die einzelnen Disziplinen werden nacheinander abgearbeitet.

Eine Tätigkeit folgt auf die andere, Berührungspunkte zwischen den Disziplinen gab es lediglich bei der Übergabe oder an der Kaffeemaschine.

Der Ablauf ist linear. Erst muss die Planung und die Inhalte fertig sein, dann geht es an das Design. Erst muss das Design fertig ausgestaltet sein, bevor es „programmiert“ wird. Es erfolgt ein Schritt nach dem anderen, klar voneinander getrennt.

Vorteile des klassischen Workflows

Dieser lineare Workflow hat auch deshalb funktioniert, weil die surfende Zielgruppe recht klare Voraussetzungen hatte. Es gab sicherlich immer schon unterschiedliche Monitore, aber eine minimale Bildschirmgröße gab den Rahmen vor, den die meisten erfüllen konnten, dazu saßen sie am Schreibtisch vor dem Desktop-PC.

Dazu kam, dass der Designentwurf und die fertige Website statisch waren. Und so war der alte Workflow auch deshalb „beliebt“, weil für den Webdesigner/-programmierer und den Kunden alle Schritte gut nachzuvollziehen waren. Die einzelnen Disziplinen (Konzeption, Design und Technik) konnten gut getrennt voneinander arbeiten, einer nach dem anderen kam zum Zuge, die Arbeitsschritte waren klar getrennt.

Und der Kunde konnte zuerst eben ein eindeutiges Design sehen und wusste genau wie seine fertige Website einmal aussehen wird.

Der alte Workflow – im mobilen Web unbrauchbar

Die Einführung des iPhones im Jahre 2007 wird gerne als Beginn des mobilen Internets bezeichnet. Über die Jahre haben die mobilen Endgeräte eine solche Verbreitung gefunden, dass die oben beschriebene Kernzielgruppe so nicht mehr existiert. Besucher betrachten mit unzähligen unterschiedlichen Geräten und damit auch unzähligen unterschiedlichen Viewports die Website.

Eine statische Website sieht dann bei sehr großen Monitoren verloren aus. Auf eher kleineren Monitoren wird die Website verkleinert dargestellt und man muss hinein zoomen, um die Inhalte lesen zu können. Teilweise erscheint ein horizontaler Scrollbalken oder die Inhalte sind horizontal verdeckt.

Ungünstiges Zoomen

Ungünstig: Die Website wird zu klein dargestellt und die Inhalte sind kaum erkennbar. Nach dem heranzoomen muss man die Inhalte dann horizontal scrollen.

Egal, welcher dieser Fälle auftritt, ein statisches Layout, dass für eine feste Breite gestaltet und umgesetzt wurde, ist hier natürlich denkbar ungeeignet.

Will man also den alten Workflow für die neuen Rahmenbedingungen anpassen, hieße das nicht mehr nur einen Entwurf für eine fixe Breite zu gestalten, sondern mehrere unterschiedliche Breiten zu definieren und für diese unterschiedliche Entwürfe zu gestalte, z.B. kleine und große Desktop-Ansicht und jeweils eine Tablet- und eine Smartphone-Version in Portrait- und Landscape-Modus):

Unterschiedliche Viewports

Diese für einzelne Viewports optimierten Designs müssten dann einzeln abgenommen und umgesetzt werden. Als Ergebnis hätte man dann nicht eine statische Seite, sondern mehrere, die eben für unterschiedliche Viewports erstellt wurden.

Ein kleines Rechenbeispiel:
2 Designentwürfe
5 Seitentypen
3 Break-Points
= 30 PSD-Dateien
Das ist noch ein eher bescheidenes Beispiel. Man kann sich leicht ausrechnen, was bei deutlich komplexeren Websites mit mehr Seitentypen und mehr Breakpoints für ein Aufwand entstehen würde.

Bei Änderungswünschen müsste dann nicht eine Ansicht, sondern immer mehrere angepasst werden, was schnell in einem enormen zeitlichen Mehraufwand und Mehrkosten enden würde.

Und wird statt für eine feste Breite für mehrere optimiert, bleiben doch weiterhin unzählige Breiten unbeachtet.

Dazu macht sich spätestens hier der große Nachteil von statischen Design-Entwürfen negativ bemerkbar: Sie sind eben statisch und nicht dynamisch. Und solche Aspekte wie Animationen, Interaktionen lassen sich damit nicht wirklich gut simulieren.

Kurz zusammengefasst:
Der lineare Workflow ist für das mobile Web und responsive Websites ineffizient!

Ein anderer Workflow – eine andere Vorgehensweise

Aus diesem Grunde hat sich nun das Responsive Webdesign (abgekürzt gern auch mal nur RWD genannt) durchgesetzt. Also eine flexibles Design, das verschiedene (alle) Viewports berücksichtigt. Doch mit einem Grafikprogramm lässt sich dieser Flexibilität nicht vernünftig beikommen. Fixe pixelgenaue Designs sind nicht mehr praktikabel und auch nicht mehr wünschenswert.

Dieser Veränderung betrifft aber nicht nur die pixelschubsenden Designer. Ein responsiver Workflow betrifft alle am Projekt Beteiligten. Denn es geht nicht nur darum, Designs jetzt eben nicht mehr pixelgenau umzusetzen und flexibel darzustellen, es geht viel mehr um das große Ganze.

Responsive design is not about mobile. It’s not about tablets. It’s not about desktops. It’s about The Web.
Jeremy Keith

Ein responsiver Workflow beginnt schon mit der Konzeption und bezieht regelmäßig alle am Projekt beteiligten ein. Im Idealfall arbeiten Entwickler, Designer und Konzepter von Anfang an zusammen. Eventuell vereinen sich die drei Tätigkeits­bereiche auch in einer Person.

Und dann ist da ja noch der Kunde. Er wartet (ja, manchmal auch heute noch) auf bunte Photoshop-­Designs im JPG- oder PDF-­Format.

Hier hilft Erklärung und Aufklärung! Die Bedeutung responsiver Webseiten und veränderter Arbeitsabläufe müssen erklärt werden. Sicherlich nicht in allen Einzelheiten. Den Kunden interessieren (meistens) keine Breakpoints, und er muss sie auch nicht kennen. Er muss die Bedeutung kennen für den Endkunden. Dieser soll die Seite hinterher nutzen (können), egal, wo und wie und mit welchem Gerät. Responsive Webdesign ist dafür gemacht, dem Endanwender die Nutzung der Webseite in jeder Situation zu ermöglichen und zu erleichtern.

Content first

Zur Aufklärung gehört also, dem Kunden klarzumachen, dass die Inhalte das Wichtigste sind, dass diese am besten vor dem De­sign und der Umsetzung feststehen (nicht unbedingt alle Texte bis ins Letzte ausformuliert, aber zumindest deren Art, Bedeutung, Umfang und benötigter Platz).

Der Kunde muss und soll dann auch nicht mehr auf Bilddateien warten, sondern kann recht früh im Browser die Entstehen der Website mitverfolgen. Dies legt den Schwerpunkt weg vom rein ästhetischen Empfinden einer Bilddatei hin zu der Interaktion mit der Website und den Inhalten.

Durch den veränderten Ablauf wird auch häufig der Kundenkontakt intensiver. Regelmäßigere Abstimmungen und weniger „böse“ Überraschungen bei den „großen“ Abnahmen sind das Ergebnis, wenn der Kunde bei vielen Entscheidungen früher dabei ist und die Zwischenergebnisse verfolgen und Einfluss nehmen kann.

Aus der Praxis
Regelmäßig habe ich die »Dis­kussion« über den Projektablauf: Erst das Design, dann die Umsetzung oder das Design bei der Umsetzung. Und es hat sich gezeigt, wenn zuerst das Design gestaltet wird (manchmal – ganz selten – tatsächlich noch ausführlich in Photoshop, weil Kunde und Agentur es so möchten), wird viel Zeit und Arbeit in »Pixel«­ Details gesteckt. Bei der techni­schen Umsetzung und der Betrachtung im Browser sind dann aber meistens all diese Details unwichtig. Der Kunde kann kli­cken und achtet auf andere Sa­chen, aber kaum noch auf die ihm vorher ach so wichtigen Design-­Aspekte.
Webdesign Survival Kit

Der neue responsive Workflow

Die „Lösung“, um den Workflow für responsive Websites anzupassen, besteht darin den Ablauf aufzubrechen und schon möglichst früh mit der technischen Umsetzung zu beginnen. Es ist ein agiler Ablauf, der gerne auch iterativ genannt wird.

Das bedeutet, dass der Workflow in kleinen Schritten gegangen wird. Zwischendurch werden die einzelnen Schritte immer wieder besprochen und getestet und so lange wiederholt, bis das Ergebnis zufriedenstellend ist und zum nächsten Schritt gegangen werden kann.

Im einzelnen kann ein klassischer responsiver Workflow folgendermaßen aussehen:

1. Projektrahmenbedingungen

Zuerst sollten die Rahmenbedingungen des Projektes festgelegt werden. Dazu gehört unter Umständen auch dem Kunden den folgenden Ablauf zu erklären und ihm zu verdeutlichen, wie sich Design und die technische Umsetzung sprichwörtlich gemeinsam entwickeln.

Die Entscheider auf Kundenseite werden festgelegt, damit klar ist, wer später einzelne Schritte abnimmt. Man einigt sich zudem auf die wichtigsten Geräte und Browser, die später vollumfänglich getestet werden und auf die benötigten Breakpoints (also die Stellen, an denen das Design/die Inhalte ihr Aussehen bedeutend ändern können).

Auch Design-Aspekte werden besprochen, also ob es optische Vorgaben gibt, ob ein Moodboard vorhanden ist oder erst entwickelt werden muss.

Da es keine, oder zumindest nicht mehr so viele eindeutige klare Zwischenergebnisse gibt, kann es sein, dass der Vertrag auch eher „agil“ sein muss. Also unter Umständen auch flexibel, was den Zeitrahmen und den Aufwand betrifft.

Mitarbeit des Kunden
Nicht selten, dass Kunden den Aufwand der Erstellung einer Website unterschätzen. Und zwar nicht nur den Aufwand beim Auftragnehmer, sondern auch ihren eigenen.

Ja, der Kunde sollte, besser muss, mitarbeiten. Er sollte nicht nur den Projektstartschuss geben und ab und zwischendrin ein paar Designs absegnen. Beim responsiven Workflow muss er regelmäßig aktiv mitarbeiten. Klar, dass sollte eigentlich auch unabhängig davon von der Art des Workflows sein, damit man sich kontinuierlich austauschen und die Richtung abgleichen kann. Beim responsiven Workflow ist dies aber eben besonders notwendig.

Dies sollte man dem Auftraggeber zu Beginn des Projektes, am besten auch schon vor Auftragerserteilung klar machen. Nicht wenige Projekte , die sich verzögern und (fast) alle aus einem Grund: Der Kunde muss noch liefern (Inhalte, Feedback).

2. Konzeption / Content Strategie

Nach dem Motto „Content first“ werden zuerst die Inhalte (sofern vorhanden) gesammelt, bewertet und gegliedert. Es wird eine Art Inhalts-Inventur gemacht. Dabei wird auch deutlich, wo noch Inhalte erstellt werden müssen. Hier müssen die Ziele der Website, die Unternehmensziele und die Erwartungen und Bedürfnisse der Zielgruppe, wie auch die deren Nutzungsverhalten berücksichtigt werden.

Aufgrund der Inventur ergeben sich dann Seiten-Strukturen, so dass die Navigationen festgelegt werden können.

Nicht selten wird dabei der Inhalt auch für den kleinstmöglichen Viewport erstellt/optimiert („Mobile First“) und dann bei Bedarf für größere Geräte mit Inhalten und Funktionalitäten erweitert.

3. Wireframes – Die Content Choreographie

Aufgrund der Inhaltsanalyse können Wireframes erstellt werden, um so die Inhaltsstruktur der einzelnen Seiten herauszuarbeiten und die Grundlage für die Umsetzung zu haben. Bei Wireframes geht es nicht, um gestalterische Aspekte wie Farben oder Typografie, sondern alleine darum welche Position die Inhalte auf der Seite einnehmen sollen.

Dabei wird für jeden wichtigen Breakpoint ein Wireframe erstellt, um die wichtigen Änderungen der Inhaltsdarstellung zu visualisieren.

Content Choreographie

Die Content Choreographie zeigt an, wie sich die Inhalte über einzelne Breakpoints verändern.

4. Prototyp

Aufgrund des Wireframes kann der erste interaktive Klickdummy mit HTML und CSS erstellt werden. Der Prototyp verdeutlicht die Struktur, die Flexibilität und die gesamte Funktionalität der Website. Der erste Prototyp ist noch nicht fein ausgearbeitet. Hier geht es erstmal darum, die Semantik, die Struktur und die Funktionalitäten der Website testen zu können, was ein großer Vorteil gegenüber einem statischen Entwurf in einem Grafikprogramm ist.

Da hier noch keine Gestaltung vorhanden ist, können eventuelle Korrekturen schnell vorgenommen werden und haben noch keine Auswirkungen auf das Design, was doppelte Korrekturen vermeidet.

Wenn der Prototyp in allen Testszenarien zufriedenstellend läuft, kann das Design entwickelt werden.

Am lebenden Objekt
… nenne ich das gerne. Im Gegensatz zu statischen Entwürfen läuft der Prototyp im Browser und passt sich bereits an verschiedene Displaygrößen an.
So kann er in unterschiedlichen Situatonen mit unterschiedlichen Eingabe-/Bedienungsgeräten und auf unterschiedlichen Displays und mit verschiedenen Ausrichtungen eines Geräts (z. B. Hoch- oder Querformat) in verschiedenen Browsern getestet werden.
Aus statischer Theorie wird lebendige Praxis…

5. Design – Look & Feel erarbeiten

Anders als beim alten Workflow wird nicht gleich ein vollständiges, fein ausgearbeitetes Design entworfen, sondern es werden nach und nach einzelne Elemente ausgewählt und gestaltet.

Damit der Designer nicht völlig im „luftleeren“ Raum gestalten muss, kann er sich Hilfsmittel wie Moodboards oder Style Tiles einsetzen. Beide dienen dazu, die optische Richtung und die gewünschte Wirkung der Website zu visualisieren, nicht aber das fertige Design.

Die Stilrichtung kann auch schon iterativ mit dem Kunden parallel besprochen und entwickelt werden. Und wenn man sich zusammen für einen Stil entscheiden hat, kann dieser nach und nach auf den voll funktionsfähigen Prototypen angewendet werden.

Style Tile:
Style Tiles sind im Grunde eine Art konkreteres Moodboard. Hier werden alle relevanten grafischen Elemente der Website zusammengefasst. Dazu können Typo, Bilder, Icons, Farben, Buttons usw. gehören.

Hiermit lassen sich auch recht schnell verschiedene Stilrichtungen entwerfen, die sich dann gut vergleichen lassen. Entscheidend ist, dass es eben nur eine Designrichtung ist und kein fertiges Layout.

Mehr zu den Style Tiles

6. Testen und Besprechen

Der Prototyp wird nun von den Entwicklern und Designern (manchmal ist ist auch beides in einer Person vereint) ausgearbeitet. Es wird in verschiedenen (vorher festgelegten) Browsern und Geräten ausführlich getestet und optimiert.

Inhalte (Menge, Verhältnis, Umbruch, Hierarchie), Design, technische Funktionalität und das Verhalten der interakiven Elemente sind die „Prüfungskriterien“.

Design und Code werden parallel entwickelt und der Prototyp durchläuft nun normalerweise diverse Korrekturschleifen. Dieser Prozess wiederholt sich so lange, bis die Website fertig ist.

Mit dem Auftraggeber werden in einem iterativen Prozess in einzelnen Zwischenschritten nach und nach alle Komponenten erarbeitet und besprochen. Es findet also eine Art regelmäßiges „Dreiergespräch“ statt. Die Kommunikation wird hier zu einem ganz entscheidenen Erfolgsfaktor.

Durch die schon geleistete Vorarbeit ist der Aufwand für das Testing nun deutlich kleiner und es müssen nun weniger „große“ Zwischenergebnisse freigegeben werden, die lange besprochen werden müssen, sondern eher viele kleinere Schritte.

Hier ist aber eben auch eine gewisse Flexibilität möglichst bei allen Projektbeteilgten notwendig, damit spontane Änderungen und Erkenntnisse einfließen und umgesetzt werden können.

Keine Seiten designen, sondern Komponenten
Es geht darum keine vollständigen Seiten mehr zu gestalten, sondern einzelnen Modulen. Eine moderne Website besteht aus vielen verschiedenen Komponenten, die zusammen das Design bilden: Navigationen, Inhaltsfelder, Slider, Buttons, Formulare usw.
Alle diese Kompontenten werden gestaltet und in unterschiedlichen Zusammenstellungen auf den einzelnen Seiten eingesetzt.
Dieses Vorgehen nennt sich Atomic Design, da man die einzelnen Inhaltselemente aus einzelnen „Atome“ zusammengesetzt sind.

Die Elemente des Atomic Designs

Die Elemente des Atomic Designs am Beispiel der Instagram-App.
Atomic Design Methodology

4. Abnahme und Launch
Nach der endgültigen Abnahme durch den Auftraggeber erfolgt eine eventuelle Einpflege des Frontend-Gerüstes in ein Content Management System und die Onlinestellung.

Responsiver Webdesign Workflow

Konzeption, Design und Technik arbeiten „Hand in Hand“ und entwickeln Prototypen, die regelmäßig getestet werden. Wie bei einer Waschmaschine werden die einzelnen Abläufe „durchgeschleudert“ bis sie fertig sind.

Der große Unterschied ist, dass bei diesem responsiven Ablauf die technische Umsetzung wesentlich früher erfolgt. Die konkrete Anwendung, die Interaktion des Anwenders, kann so viel früher überprüft und angepasst werden.

Responsive Strategien

Das Vorgehen eine responsiven Website zu erstellen, ist aber auch mit oben aufgezeigten Workflow nicht zwangsläufig einheitlich. Es gibt sehr unterschiedliche Vorgehensweisen und auch sehr unterschiedliche Vorstellungen, was denn responsiv überhaupt genau ist. Nicht jeder meint immer das Gleiche damit. Und vor allem das Ziel, eine responsive Webseite umzusetzen, kann sehr unterschied­liche Ergebnisse hervorbringen.

Adaptive Layout vs. Responsive Layout

Eine Webseite kann man ganz allgemein unterscheiden zwischen responsiv (reaktionsfähig) und adaptiv (anpassungsfähig).

Responsive Webseiten setzen also auf ein flexibles Raster. Im Zusammenhang mit Media Queries wird erreicht, dass der zur Verfügung stehende Platz optimal ausgenutzt wird, da sich das Layout über die volle Breite erstreckt. Einzige Ausnahme ist eine fixe Grenze bei sehr großen Auflösungen (max-width), so dass das Layout nicht zu breit wird.

Ein Umbruch des Layouts, also ein Breakpoint mit Media Queries, wird dann gesetzt, wenn das Design und die Inhalte danach verlangen. So wird beispielsweise die Hauptnavigation dann hinter einem Hamburger-Icon „versteckt“, wenn der Platz nicht mehr ausreicht.

Ein responsives Webdesign ist daher eher „im Fluss“, flexibel.

Ein adaptives Layout dagegen wird von Anfang an für bestimmte Bildschirmgrößen optimiert. Im Grunde sind es starre Gestaltungsraster wie früher mit dem 960-Pixel-Raster, nur jetzt eben mehrere für unterschiedliche Auflösungen.

Spezifische Ausgabegeräte stehen im Mittelpunkt und nicht der Inhalt bzw. die Inhaltsdarstellung. Meistens sind es häufig genutzte und beliebte Geräte wie das iPhone und iPad, deren Auflösungen für Breakpoints herhalten müssen. Für diese Geräte ist die Darstellung dann optimiert, aber nicht für Geräte, die eine etwas größere oder kleinere Auflösung haben.

Während reaktionsfähige (responsive) Layouts also stufenlos auf jede Größenänderung des Browsers reagieren können, sind anpassungsfähige (adaptive) Layouts nicht so flexibel und reagieren nur an bestimmten Punkten (Breakpoints).

Der Einsatz adaptiver Layouts lohnt sich vor allem dann, wenn man entscheidend unterschiedliche Inhalte, Funktionen, Darstellungen bei unterschiedlichen Endgeräten haben möchte. Die sog. User Experience kann deutlich erhöht werden, da das Gerät und damit auch ein bestimmtes Nutzungsszenario im Vordergrund steht.

Das folgende Beispiel verdeutlich dies gut:

Die responsive Website der bahn.

Adaptive Webdesign am Beispiel der Website bahn.de: Einmal das Desktop-Angebot und die mobile Ansicht.

Interessant ist dazu auch der Artikel Strategische Entscheidungshilfe – Responsive vs. Adaptive Webdesign.

Graceful Degradation oder: Desktop First

Bei der Erstellung einer responsiven Website gibt es im Grunde zwei Wege:
von groß nach klein oder umgekehrt.

Der typische Webdesigner entwickelt an einem modernen Arbeitsplatz mit großem Bildschirm und modernen Browser. Von diesen Voraussetzungen ausgehend, wird die neue Seite erstellt, optimiert und dann nach und nach für kleinere Auflösungen und auch ältere Browser angepasst. Dieses Vorgehen nennt sich Graceful Degradation (deutsch etwa „würdevolle Herabstufung“).

Dieses Vorgehen mutet zuerst einmal logisch an.

Die neuesten Technologien und Effekte werden eingesetzt, und das Design sieht bei viel Platz (also auf großen Bildschirmen) wunderbar aus.

Je kleiner die Auflösung und je älter der Browser, desto eher kommt es zu Kompatibilitätsproblemen. Moderne Techniken werden nicht mehr oder nicht vollständig unterstützt (zum Beispiel bestimmte CSS3-Anweisungen), und auf kleineren Auflösungen funktioniert das Layout nicht mehr.

Entweder werden dann Inhalte ausgeblendet, per JavaScript funktionstüchtig gemacht, oder sie funktionieren ganz einfach gar nicht mehr. Inhalte und Funktionalitäten werden so allmählich „abgespeckt“.

Für die Zugänglichkeit einer Webseite ist dieses Vorgehen denkbar schlecht. Ältere Browser, kleinere Bildschirme und langsame Geräte/Verbindungen werden bei diesem Vorgehen abgestraft.

Dieser Ablauf ergibt sich auch, wenn eine bestehende, nicht-responsive Website nachträglich mobiltauglich gemacht werden soll. Man nennt diesen Prozess dann auch „Responsive Retrofitting“, da das Desktop first-Konzept schon zwangsläufig vorher feststeht.

Graceful Degradation

Eine schematische Darstellung von Graceful Degradation. Zuerst wird für große Bildschirme und moderne Browser entwickelt.

Vorteile des Graceful Degradation:

  • Entspricht eher dem gewohnten Arbeitsablauf und Umfeld des Webdesigners.
  • Moderne Systeme, Techniken und Features können eingesetzt und ausgereizt werden.
  • Das Nutzungserlebnis (die User Experience) steht an oberer Stelle.

Nachteile des Graceful Degradation:

  • „Schwache“ Systeme werden nur zweitrangig behandelt.
  • Es kann schneller zu Performance-Problemen kommen.
  • Die Zugänglichkeit/Barrierefreiheit wird eher vernachlässigt.
  • Schwieriger/aufwendiger nachträglich inhaltliche und funktionale Anpassungen umzusetzen.

Progressive Enhancement oder: Mobile First

Den umgekehrten Weg beschreitet die progressive Verbesserung (englisch Progressive Enhancement). Die Idee ist, eine Website auch für Endgeräte nutzbar zu machen, die nur über eingeschränkte Funktionalitäten verfügen (zum Beispiel keine vollständige Unterstützung von CSS3 oder JavaScript). Eine Webseite soll mit jedem Browser und jedem Gerät bedienbar und zugänglich sein.

Dabei wird meistens von einer möglichst kleinen Auflösung und einem „schwachen“ System ausgegangen und die Seite hierfür optimiert.

Das Prinzip „Mobile First“ geht dann noch einen Schritt weiter und so stehen hier Mobilgeräte mit wenig Raum, langsamerer Datenübertragung und potenziell stärker abgelenkten Nutzern im Vordergrund.

Schrittweise wird die Website dann für größere Auflösungen und „stärkere“ Systeme erweitert. Hier können dann auch komplexere Technologien und Layouteigenschaften zum Einsatz kommen.

Progressive Enhancement

Eine schematische Darstellung von Progressive Enhancement. Von Mobile first wird die Seite nach und nach für größere und auch modernere Geräte erweitert.

Dies klingt passenderweise sehr nach den Ansätzen „Mobile first“ und „Content first“ und damit so, als ob Progressive Enhancement die bessere Variante ist und damit auch die modernere.

Inhalte - Darstelung - Verhalten

Inhalt, Darstellung und Verhalten – In dieser Reihenfolge sollte gearbeitet werden.
Da auf kleineren Displays wenig Raum vorhanden ist, führt dieses Vorgehen zwangsläufig zu relevanteren Inhalten, guter Performance und funktionalem Design.

Inhalt, Darstellung und Verhalten sollten in dieser Reihenfolge berücksichtigt werden.
Das auf kleineren Displays wenig Raum vorhanden ist, führt dieses Vorgehen zwangsläufig zu relevanteren Inhalten, guter Performance und funktionalem Design.

Start with the small screen first, then expand until it looks like shit. Time for a breakpoint!
Stephen Hay

Vorteile des Progressive Enhancement / Mobile first-Prinzips:

  • Die Inhalte stehen im Mittelpunkt.
  • Hohe Zugänglichkeit/Barrierefreiheit für alle Besucher.
  • Mobile Bedienung und Nutzungskontexte werden gut ermöglicht.
  • Sehr gute Performance auf allen Systemen.
  • Leichter Erweiterbarkeit der Website was Inhalte, Design und Funktionen betrifft.

Nachteile des Progressive Enhancement:

  • Erfordert großes Umdenken (aller Projektbeteiligten) und damit größeres Risiko für Fehleinschätzungen.
  • Aufwändige(re) Konzeption.
  • Eventuell vereinfachte Optik.

Fazit des Workflows und der Strategie im Responsive Webdesign

Der Wandel des Webs bringt auch einen Wandel des Prozesses mit sich. Die Herausforderungen, die der Wechsel zu einem responsiven Workflow mit sich bringt, sind dabei nicht zu unterschätzen:

  • Die Anforderungen an die Projektbeteiligten steigen. Projektmanager, Konzepter, Designer und Entwickler müssen Hand in Hand arbeiten, sich einbringen und ergänzen. Websiteerstellung wird immer mehr zur Teamarbeit (was es eigentlich schon immer war).
  • Sind all die Tätigkeiten in einer Person vereint, dann besteht sicherlich kein Abstim­mungsbedarf (außer nach wie vor mit dem Kunden), aber die Anforderungen sind für einen Einzelnen sicherlich größer.
  • Auch der Kunde muss flexibler werden, mehr mitarbeiten, sich über Inhalte (und damit über die Ziele, Zielgruppen, Inhalte seiner Webseite) frühzeitig Gedanken machen, was ja grundsätzlich nicht verkehrt ist.
  • Design und Code sollten parallel bearbeitet und entwickelt werden. Das Ergebnis ist eine größere Einheit.
    Und die alte Designformel „form follows function“ findet nun Anwendung, da Design, Funktionen und die Struktur den Anforderungen des Inhalts folgen.

Diese Veränderungen sind vermutlich auch ein Grund, warum sich dieser neue Workflow auch nach Jahren immer noch nicht flächendeckend durchgesetzt hat (wenn er es denn über­haupt jemals tun wird).

Nicht nur die Website, auch der Workflow, Arbeitnehmer und Auftraggeber müssen flexibler werden.

Die Ergebnisse eines responsiven Workflows sprechen im Idealfall aber für sich – in Form einer Website, die ihre Anwen­der glücklicher macht, weil sie in allen erdenklichen Situationen zugänglich und gut bedienbar ist.

Es gibt eigentlich keine sinnvolle Alternative zu dem responsiven Workflow. Designer, Entwickler, Agenturen und Kunden mussten und müssen dabei auch immer wieder umdenken. Die Anforderungen und Arbeitsabläufe haben sich verändert. Nicht nur an die Auftragnehmer, auch an die Auftraggeber.

Kunden sind jetzt eher Partner, mit denen man konstruktiv und regelmäßig zusammenarbeiten muss und darf.

Der Workflow im Responsive Webdesign
534 Stimme[n]

Weiterempfehlen ausdrücklich erlaubt:

Die Webdesign Checkliste

Webdesign-Newsletter +
WEBDESIGN-CHECKLISTE
mit 90 Checkpunkten für
Dein nächstes Projekt:

Keine Sorge, Spam gibt es hier nicht und Adressen gebe ich natürlich auch nicht weiter!
(Beispiele, Datenschutz, Analyse und Widerruf)

Webdesign Survival Kit

Autor:
Martin Hahn ist Webdesigner, Dozent, Fachbuchautor und dreifacher Papa. Seit vielen Jahren hilft er anderen effektivere Webdesigns zu erstellen – in Schulungen und mit Artikeln in diesem Blog. Tägliche Webdesign-Links von Martin gibt es auch auf twitter.

11 Kommentare

  1. Hallo Martin,

    mal wieder ein großartiger Artikel, für Leihen und deren besseres Verständnis (gute Aufklärungsarbeit deinerseits!).

    Aber auch für unseres Gleichen, von denen – ich unterstelle – viele bereits responsive oder adaptable Design basierte Webprojekte nach dem „Rapid-Prototyping“ Verfahren umsetzen.

    Diese Art der Projektumsetzung spart Auftraggebern nicht nur Geld, sie bindet sie sehr früh in den Prozess „NEUE WEBSEITE MACHEN“ ein. Fördert dadurch meiner Ansicht nach auch deren Verstand und Weitblick für die Sache.

    Auf unserer Seite hingegen spart es Zeit (manchmal gewaltig), steigert im Einzelfall sogar den „Profit“ (ein wenig) und sorgt unterm Strich dafür, dass „Deadlines“ nicht nur realistisch und haltbar sind sondern am Ende dann tatsächlich auch gehalten werden.
    Ich denke, du erlebst das in deiner Agenturpraxis (hahnsinn) ähnlich.

    Ich hatte vor kurzem einen Präsentationstermin bei einem Kunden aus dem Baugewerbe. Was wie aussehen soll (Navi, Contentstruktur & Design, ausgeblendete Elemente ab einem bestimmten Breakpoint, usw.) war vorher schon besprochen.

    Der Dienst (Basis: WP- mit einem Premiumtheme) wurde zum ersten Mal einem größerem Mitarbeiter Team präsentiert. Alle waren begeistert, bis auf eine Dame – die einfach ein Problem mit einer Vertikal-Navigation hatte. Und dies mit Worten zum Ausdruck brachte … die ein wenig unfair waren. Aber egal.

    Womit niemand der Anwesenden gerecht hat, dass ich so reagiere: Ist ein Argument, sehen wir es uns doch einfach „schnell“ mit einer Horizontal-Navigation an.

    Ich habe mich eingeloggt, das Ganze über die entsprechenden Theme-Options umgestellt und gezeigt.

    Der „Chef“ brachte den Spruch … na, das ist ja was. Da hätten wir vorher 3 Wochen drauf warten müssen … etc.

    Im Endeffekt hat die Kriterien verstanden, warum wir die Vertikale gewählt haben und hat dies dann auch Kund getan – wertschätzend. Mit dem Spruch (den du Martin sicherlich schon sehr oft gehört hast) „naja, sie sind ja die Profis, ich bin nur Leihe“.

    Meine Antwort darauf war: dieser Internetdienst ist nicht für Profis gemacht, sondern für Leihen. Genau deshalb sind uns solche Feedbacks sehr wichtig.

    Soviel zum Effekt des „Rapid-Prototyping“.

    VG
    Andreas

    • Hallo Andreas,
      freut mich, dass Dir der Artikel gefällt.
      Und danke für dein anschauliches Beispiel aus Deiner Praxis.
      Gruss
      Martin

      • Hallo Martin,

        gerne geschehen. Ich danke dir für den großartigen Artikel.

        Vielleicht gestattest du mir hier ganz offen die Frage:
        Wie stehst du den Themen KI (im Webdesign) und „der Beruf Webdesign im Wandel“ gegenüber?

        Bei jemanden wie dir gehe ich davon aus, dass du dich mit „Websitebutler“, „thegrid“ & Co. schon beschäftigt hast, wahrscheinlich auch mit dem „Watson“ Projekt (IBM).

        Weiter vermute ich, dass du „Rukzuk“ (von Seitenbau) ebenfalls kennst. Jenes („ultimative“) design-CMS, bei dem Flyeralarm (damals) als Aktionär einstieg und ordentlich Werbung dafür machte – für eine gewisse Zeit. Jetzt wurde daraus die Sparte „FLYERALARM Creatives“ 🙂 -> die meisten davon arbeiten glaube ich eher mit WordPress und Typo3, evtl. auch mit Contao … aber nicht mit rukzuk.

        Ich meine jedenfalls: Noch müssen wir uns keine großen Sorgen machen, dass wir „ausgedient“ haben. Dass wir als Dienstleister wachsam sein müssen, ist klar.

        Vor kurzem hatte ich zu einem Freund Kontakt, der seit längerer Zeit als Informatiker / Entwickler im Valley lebt und arbeitet. Was der mir erzählt hat, hat mir schon ein wenig „Bauschmerzen“ bereitet. Die Chatbot-Technologie der nächsten Generation soll nicht nur schnell und gezielt einem User gute Antworten geben können … diese soll wohl auch die Fähigkeit besitzen, Content (Textinformationen und Bilder mit Metabeschreibungen) individuell formatiert über ein Webinterface ausgeben zu können – personalisiert, klar … und das schon bei Erstkontakt.

        Gruss
        Andreas

        • „Noch müssen wir uns keine großen Sorgen machen, dass wir „ausgedient“ haben. Dass wir als Dienstleister wachsam sein müssen, ist klar.“
          -> Ja, das sehe ich auch so! Vor einigen Monaten hatte ich ja über den Status quo im Webdesign geschrieben.
          Aber der – meiner Menung nach – gute aktuelle Zustand des Webdesigns udn für Webdesigner wird vermutlich nicht ewig halten. Dazu muss man das Thema Digitalisierung nur ein bisschen verfolgen (ich kann u.a. die Richard David Precht Vorträge/Videos dazu sehr empfehlen).
          Momentan „verdränge“ ich die Entwicklung noch ein bisschen. Denn wenn es so kommt, wie nicht wenige Experten vorausssagen, dann stehen nicht nur Webdesigner, sondern auch noch verdammt viele andere Tätigkeiten und Branchen vor großen Umbrüchen, bzw. werden obsolet…
          Und dann? Dann wird sich die Gesellschaft eh andere Antworten übrlegen müssen (Bedingungsloses Grundeinkommen kann eines sein, wird aber nicht alle Probleme lösen können).

          Was man aktuell „dagegen“ machen kann? Keine Ahnung, ich merke aber in meiner Webdesigner-Praxis, dass es sich immer mehr wandelt vom reinen Umsetzer zum Berater. Kunden haben „größere“ Probleme, als die reine Website: Wie tritt mann online auf, welche sozialen Netzwerke braucht man, welche Inhalte werden benötigt? usw.
          Das kann evtl. ein Weg sein, um sich auch längerfristig (also auch in 10, 20 Jahren) ein Einkommen zu sichern. Weniger der reine gestalterische, technische Webdesigner, sondern mehr „Stratege“ – Vielleicht ist das dann aber auch überflüssig 😉

  2. Hi Martin,

    es ist auf jeden Fall mal ein interessanter Ansatz, den ich vielleicht beim nächsten Projekt mal austesten werde. Der alte (mein aktueller) Workflow muss auf jeden Fall früher oder später ersetzt werden.

    Das Problem ist meistens, dass viele kleine Kunden keine Wireframes lesen können, bzw. nicht die Vorstellungskraft haben, was hinterher raus kommen soll. Aber das Problem hat man wohl bei allen Varianten.

    Zum Artikel: Wieder mal Wow! Man erhält wirklich fundiertes Wissen und es ist kein Content Füller nur damit man mehrere Artikel auf dem Blog hat.

    • Hallo Daniel,
      ja, die Vorstellungskraft bzgl. Wireframes ist bei Kunden nicht immer gegeben…
      Hier hilft nur aufklären, erklären und evtl. ein paar Beispiel zeigen…
      Alternativ ist das parallele Präsentieren von Moodboards hilfreich, damit Kunden eben auch was „visuelles“ bzgl. der Gestaltung sehen.
      Gruss
      Martin

  3. Hallo Martin,

    auch wenn ich nicht in der Branche tätig bin, interessiert mich das Thema Webdesign sehr. Dein Beitrag ist wieder mal sehr informativ und wie gewohnt verständlich aufbereitet, sodass auch ich als Laie Dir folgen kann. Danke!

    Gruß, Andreas

    • Hallo Andreas,
      danke, freut mich!
      Gruss
      Martin

  4. Hallo Martin,

    das ist wirklich ein toller Artikel, den du da geschrieben hast.

    Die Anforderungen an Websites, an das Projektmanagement, die Entwickler und die einzelnen Prozesse haben sich schon deutlich verändert. Sicherlich ist dadurch nicht alles einfacher, aber Ich finde diese Entwicklung sehr interessant. Es belebt unsere Branche und unsere Arbeit. Man muss heute in jedem Aspekt einfach deutlich flexibler sein. Auch im Umgang mit seinen Kunden. Man ist Dienstleister, Entwickler und Berater zugleich. Wir werden immer mehr selbst „responsive“. Je nach Kunde und Projekt muss differenziert werden, welche Mittel und Werkzeuge überhaupt Sinn machen. Alles in allem ist das für mich eine sehr spannende Entwicklung.

    Kollegiale Grüße
    -Tobias-

    • Hallo Tobias,
      danke, freut mich, dass Dir der Artikel gefällt.
      Die Ergänzung finde ich gut: Wir werden immer mehr selbst „responsive“.

      Gruss
      Martin

Trackbacks/Pingbacks

  1. Lieblinks – Oktober 17 | hahnsinn – Büro für Design & Webentwicklung in Leipzig und Frankfurt a.M.

Kommentar schreiben

Email-Adresse wird nicht veröffentlicht!