Das könnte dich auch interessieren

Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Design

Responsive Webdesign verkaufen: So sieht der optimale Workflow aus

    Responsive Webdesign verkaufen: So sieht der optimale Workflow aus

Responsive Webdesign.

Mit „Responsive Webdesign“ werden oft nur die technischen Komponenten in Verbindung gebracht – wie Breakpoints, Responsive Images und progressive Enhancement. Kein Wunder, dass RWD-Projekte zum Scheitern verurteilt sind. Denn Responsive Webdesign ist deutlich mehr. Es ist eine (im Grunde gar nicht so) neue Sicht auf den Inhalt und benötigt vor allem ein komplett neues Vorgehensmodell. Und das will erst gelernt und anschließend verkauft werden.

Responsive Webdesign: Falsche Erwartungshaltung

Responsive Webdesign.
Responsive Webdesign: Jeder will möglichst schnell auf den Zug aufspringen.

Denn wie es bei Trends so ist, will jeder möglichst schnell auf den Zug aufspringen und daher muss selbstverständlich jeder Launch oder Relaunch in diesen Zeiten „responsive“ sein. Der Weg ist bei dieser Vorgehensweise aber leider nicht das Ziel und so werden Begrifflichkeiten vermischt, Hausaufgaben nicht bzw. nicht richtig gemacht, Kunden falsch beraten und insgesamt falsche Erwartungen gemacht.

Wenn wir uns das Internet und den Zugang dahin einmal vergegenwärtigen, stellen wir (für manche) erstaunliche Dinge fest: Es gibt immer mehr Zugangsgeräteklassen zum Internet: Desktop-Rechner, Laptop, Smartphone, Tablet, Phablet, Uhr, Navigationsgerät, Google Glass, Fernseher u.v.a.m. – nahezu alles, was ein Display hat, kann (und wird) internetfähig gemacht werden und wird auch aktiv genutzt.

Es gibt keinen definierten Zugangskontext mehr – so wird beispielsweise vermehrt mit dem Tablet oder Smartphone daheim auf der Couch oder aber auch während der Arbeitszeit gesurft, und das mit richtiger schneller Geschwindigkeit. Oder aber mit dem Laptop per Tethering unterwegs im Edge-Netzwerk. Aussage wie: „Wenn der User mit dem iPhone auf unsere Seite kommt, hat er nicht viel Zeit, da er ja mobil unterwegs ist“ sind mittlerweile komplett überholt. Egal wir groß das Display des Zugangsgeräts gerade ist – wir wissen nicht, wieviel davon gerade für die Anzeige der Website verwendet wird, der sichtbare Bereich entweder absichtlich oder programmatisch (z.B. durch Einbettung in andere Apps, wie z.B. Browser-Sicht innerhalb der Facebook App) eingeschränkt wird.

Wir können also keinerlei Voraussagen über die Nutzung unserer Website machen. Noch weniger Sinn macht es daher eine „Desktop-Seite“ zu entwickeln und anschließend eine „auf Mobil optimierte Seite“. Alles soll und wird eine Einheit werden – wir brauchen daher ganz schlicht eine Website, die sich an den zur Verfügung stehenden Platz anpassen – die also „responsive“ ist.

Der klassische Workflow im Responsive Webdesign

„Es geht nicht mehr darum, ein Design pixelgenau umzusetzen, es geht um den Kern des Internets“

Die RWD-Projekte lassen sich zurzeit in drei Kategorien einteilen. Neben denen, die den dahinterliegenden Prozess adaptiert haben, gibt es die, die die RWD gleichsetzen mit dem Ein- und Ausblenden von Elementen auf den verschiedenen Geräteklassen bzw. dem Verschieben von Content-Blöcken. Sicherlich führt dieser Ansatz zu einer „besseren“ Lösung – sie ist aber fern von „responsive“. Und die letzte Kategorie schließlich sind die Projekte, die Budget und Zeit auffressen und die am Ende postulieren, dass RWD entweder nicht funktioniert oder aber es keine Kunden dafür gibt, die „soviel“ Geld investieren müssen. Dabei ist RWD weder teuer noch schwierig – es benötigt „lediglich“ ein Aufbrechen jahrelang gelernter Prozesse.

Der erlernte und gelebte Workflow im Bereich Website-Erstellung ist allerorten gleich. Es werden Lasten und Pflichten ermittelt, anschließend werden die Anforderungen in ein hübsches Design verpackt. Nun erfolgt die Umsetzung des Designs in HTML/CSS und integriert dies ggf. in ein CMS. Schließlich kommt die Endabnahme – meist mit Pflichtenheft und Grafikdatei auf der einen Seite und dem Ergebnis (Website) auf der anderen Seite. Sind beide deckungsgleich, gilt die Arbeit als abgenommen.

Wo aber liegt das Problem in diesem Workflow, wenn man RWD machen will? Für RWD muss ein Umdenken auf allen Ebenen und bei allen Rollen (Entwickler, Management, Designer, Vertrieb, Kunde) stattfinden. Es geht nicht mehr darum, ein Design pixelgenau umzusetzen, es geht um den Kern des Internets – und zwar: Inhalte zielgruppengerecht in jedem zur Verfügung stehenden Medien optimal zu transportieren.

Der optimale RWD-Workflow ist agil

Der RWD-Workflow in seiner optimalen Ausprägung kann in zehn Abschnitte aufgeteilt werden. Je nach Projektgröße und Budget kann man den einen oder anderen Schritt auch weglassen, zusammenfassen oder minimieren – grundsätzlich wird damit aber die Qualität des Endergebnisses sinken. Alle nachfolgenden Schritte müssen zudem vom Kunden jeweils abgenommen werden.

  1. Entscheidungen – Festlegung aller RahmenparameterAm Angang muss man ganz klare Entscheidungen treffen – z.B. erstellt man eine Stakeholder-Matrix und legt fest, wer was entscheidet. Es darf dabei nur einen Entscheider für eine Sache geben. Man einigt sich zudem auf die wichtigsten Geräte und Browser, die später vollumfänglich getestet werden und auf die wahrscheinlich benötigten Breakpoints. Zudem erfolgt das Moodboard-Briefing und man erstellt natürlich das Wichtigste – den Vertrag.
  2. Content StrategyGetreu dem einzig richtigen und sinnvollen Motto im RWD – nämlich „Content first“ – fängt man nun an, den Content (sofern bereits vorhanden) zu sammeln, und zu bewerten. Dies führt zu einem Content Inventory, in dem alle Conten-Elemente eingetragen werden.
  3. Content WireframesMit Referenz aus dem Content Inventory können nun Content Wireframes erstellt werden, die die Position des Contents grob skizzieren. Dabei wird stets nach dem Prinzip „Mobile first“ vorgegangen. Nun geht man die in Schritt 1 vereinbarten Breakpoints durch und erstellt ähnliche Wireframes. Stellt man bereits hier fest, dass man mehr oder weniger Breakpoints benötigt, so kann man dies – ebenso vertraglich – an dieser Stelle ändern.
  4. Content erstellenHier wird nun jeglicher Content erstellt bzw. bereits vorhandener nach Prüfung genutzt. Dabei verwendet man nur Text und macht erste Auszeichnungen beispielsweise mit Markdown, AsciiDoc oder ReST. Diese werden dann mit einem geeigneten Konverter in pures Content-HTML (Text-Dummy) umgewandelt.
  5. Content-TestingDer Content-Dummy wird nun ausführlich getestet. Hier werden vor allem Menge, Verhältnis und Umbruch sichtbar.
  6. Moodboard / Style Tile Nun erfolgt die Illustration des visuellen Stils und der Stilrichtung mit Hilfe eines Moodboads oder besser eines Style Tiles. Damit entsteht bereits ein Look & Feel der Website und es werden einzelne Elemente (wie Farben, Überschriften, Textblöcke, Links, Listen, Abstände, Kästen, u.v.a.m) erstellt. Niemals allerdings ein Layout!
  7. Linear DesignAnschließend wird der Content-Dummy mit dem Basis-Design aus dem Style Tile angereichert. Dies geschieht anfangs noch linear. Erst hier ist nun also sichtbar, wie sich richtiger Content mit den richtigen Auszeichnungen verhält. Natürlich wird auch diese HTML-Datei in den vereinbarten Breiten und Browsern getestet.
  8. PrototypingJetzt sind alle Komponenten vorhanden, um einen richtigen Clickdummy aus dem Linear Design zu erstellen, der bereits das finale Layout umsetzt. Dieser entspricht idealerweise der späteren Website mit alle Funktionen und Elementen. Zusammen mit dem Kunden werden nun in einem iterativen Prozess alle Komponenten erarbeitet. Durch die Vorarbeit ist der Aufwand für das Testing nun deutlich kleiner.
  9. Geräte TestingWährend es in den vorangegangenen Schritten noch ausreichte, beispielsweise in Simulatoren zu testen, muss nun auf den realen Endgeräten getestet werden.
  10. ProduktionAn dieser Stelle ist der RWD-Prozess bereits zu Ende. Es wird nun ggf. die Integration in ein CMS oder Shop-System vorgenommen. Zudem wird die Backend-Programmierung und Integration in eventuelle Fremdsysteme vorgenommen.

RWD verkaufen

Während es „früher“ relativ einfach war, eine Website zu verkaufen, haben wir heute im RWD-Zeitalter ein leicht verändertes Portfolio. Der Beratungsanteil ist natürlich deutlich höher als früher, da einerseits dem Kunden Basis-Wissen in RWD mitgegeben werden muss. Zum anderen wird auch die Arbeit mit dem Kunden im RWD-Zeitalter intensiver, da der iterative Prozess engen Kundenkontakt voraussetzt.

Weiterhin werden Workshops einen großen Teil der Zusammenarbeit einnehmen – hier geht es vor allem um die Anforderungen, Entscheidungen, Inhalte, Wireframes, Clickdummy und die Prozesse generell. Als weiterer Bestandteil wird die Erstellung und Abstimmung von Mood Boards, Style Tiles und Linear Design Einzug in das Leistungsportfolio halten. Abschließend wird dann natürlich noch das Testing und die Produktion durchgeführt werden.

Nicht verkaufen allerdings sollte man die Erstellung und Umsetzung von PSD – oder generell von allen statischen Dokumenten und Layouts. Ebenso kann man RWD weder als AddOn auf einen bestehenden Auftritt „drauf setzen“ oder „später machen“.

Was kostet RWD?

Was kostet nun aber eine Website die dem Prozess des Responsive Webdesign folgt? Natürlich hängt die seriöse Beantwortung der Frage sicherlich mit der Größe und Komplexität der geplanten Website zusammen und vor allem – das ist wichtig – mit der Akzeptanz der Änderung des Prozesses. Hält man an der bisherigen klassischen Prozesskette kann man schnell auf 300 bis 800 Prozent der ursprünglichen Schätzung kommen - schlicht weil es nicht funktionieren kann.

Als Faustregel kann man zwischen 30 und 100 Prozent Mehraufwand bezogen auf alle Frontend relevanten Tätigkeiten zu einem Projekt ohne RWD ansetzen. Damit wird man immer günstiger fahren, als wenn das Projekt mit einer eigenen mobilen Website entwickelt wird. Aber – wie gesagt – immer vorausgesetzt man hat den RWD Prozess verinnerlicht und folgt diesem akribisch. Wichtig ist zudem diesen Prozess auch mit einem entsprechenden Vertrag abzusichern, der die agil Arbeitsweise zum Bestandteil hat.

Responsive Webdesign fängt also vor allem im Kopf an. Die Reduktion auf das Wesentliche zwingt alle Beteiligten die Pfade der letzten Jahre zu verlassen und eigentlich gar nicht so neue, bessere Wege zu gehen. Das Ergebnis ist es aber in jedem Fall wert.

Über die Autoren:

Florian Bender_webFlorian Bender ist langjähriger Kenner der Softwareentwickler-Szene und verfügt über ein exzellentes Netzwerk in die IT-Branche. Als Projektleiter des Entwickler-Events Developer Week, verbindet er Branchenwissen und neueste Trends aus den Bereichen .NET, Mobile und Web-Entwicklung zu einer Pflichtveranstaltung für Software Developer.

Patrick LorbacherlPatrick Lobacher ist Geschäftsführer der +Pluswerk GmbH, Consultant, Autor, Trainer, Programmierer, Speaker auf internationalen Kongressen und nicht zuletzt ein Digital Native bzw. liebevoll oft auch als Nerd bezeichnet. Patrick ist Referent auf der Developer Week am 14. bis 17. Juli 2014 in Nürnberg und spricht über Responsive Webdesign. Mehr Informationen: www.developer-week.de

Finde einen Job, den du liebst zum Thema Webdesign

Alle Jobs zum Thema Webdesign
6 Reaktionen
Texter und Webdesigner
Texter und Webdesigner

Das Zeitalter von Photoshop ist einfach vorbei. Schon vielfach und aus anderen Gründen diskutiert (Stichwort svg), aber inzwischen gehen immer mehr dazu über, nach Skribbles direkt im Browser zu designen: Browserkompatibilität, responsive Verhalten, CSS-Animationen und hover-Effekte. Wenn man kann, ist die Arbeit direkt im Code einfach besser zu designen.
Interessanter Artikel dazu auch unter https://medium.com/web-design/53e4fdd4457

Antworten
Almir
Almir

Toller Artikel. Die Frage ist nur, ob kleine Unternehmen auch bereit sind, die Mehrkosten zu tragen. Responsive Webdesign ist definitv die Zukunft und sollte nicht ausschließlich am Budget scheitern. Ich bin mal gespannt, wie sich alles in 1-2 Jahren entwickeln wird.

Antworten
Bert Hofmänner
Bert Hofmänner

Guter Artikel. Illustrierende Beispiele zu den Prozessschritten wären schön und hilfreich!

Antworten
DWf3
DWf3

@andy - endlich spricht das mal einer aus!

//

faustregel 30-100% mehraufwand aber auf jeden fall günstiger als eine mobile webseite.

wie bitte?

Antworten
Co
Co

Guter Beitrag zu RWD, aber bitte lasst eure Beiträge vorm Veröffentlichen probelesen. Es sind echt viele Rechtschreibfehler und fehlende Leerzeichen zu finden, schade.

Back to topic: Stimmt, Webseiten lassen sich nicht einfach zu RWD umbauen. Habe ich bereits am eigenen Leib erfahren, an einer Seite habe ich anfangs sicher 8 Stunden am CSS rumgeschraubt bis ich mich entschlossen habe, alles rauszuschmeißen und von Vorn anzufangen. Dann ging es auch relativ flott, vor allem, da der Content schon da war und ich das Design auf den Inhalt bauen konnte.

Antworten
Andy
Andy

Hi,

ich bin Webentwickler und muss mir viele solcher Themen in kurzer Zeit durchlesen. Ich finde eure Artikel interessant, wenn gleich etwas redundant und aufgebläht. Ich fände es besser diese etwas kürzer, dafür aber mehr auf den Punkt zu formulieren.

BG Andy

Antworten

Melde dich mit deinem t3n-Account an oder fülle die unteren Felder aus.

Abbrechen