Der Workflow im Responsive Web Design – Prototyping & Co.
Von: Jonas Eine detaillierte Beschreibung des Workflows im Responsive Web Design (RWD).
Die Entwicklung vom lokalen Desktop-Computer zum allgegenwärtigen „mobile Web“ zwingt uns dazu Webdesign-Projekte heute anders zu planen, zu gestalten und technisch umzusetzen als noch vor ein paar Jahren. Die schier unüberschaubare Anzahl an Displaygrößen, Geräten, Browsern und individuellen Einstellungen macht den bisherigen Workflow ineffizient, führt zu falschen Erwartungshaltungen bei Kunden und ist für langfristig angelegte Web-Projekte nicht mehr empfehlenswert. Die Anforderungen haben sich verändert und wir sollten darauf reagieren.
Der klassische Webdesign-Workflow ist ineffizient
Um zu verstehen warum der bisherige Workflow heute Schwierigkeiten bereitet, möchte ich zunächst ein exemplarisches Projekt beschreiben:
Zunächst wird die Website geplant. Die Navigation und das Gestaltungsraster werden entwickelt, die Inhalte zusammengetragen und die Ziele der Website festgelegt. Am Ende dieser Planung steht häufig ein Mockup oder Wireframe.
Anschließend wird das Layout der Website in Photoshop & Co. gestaltet. Der Kunde erhält exemplarische Unterseiten als Grafik zur Voransicht, es werden gestalterische Korrekturen vorgenommen und irgendwann ist das Design abgenommen. Dann beginnt die Programmierung. Ein Web-Entwickler setzt die Entwürfe des Designers technisch in HTML, CSS und Co. um, und stellt die fertige Website in einer Testumgebung zur Verfügung. Nun werden i. d. R. noch einmal Korrekturen eingearbeitet, anschließend ist die Website fertig und wird ins Internet geladen. Zum Schluss folgen noch einige Anpassungen die nur möglich sind, wenn die Website online ist.
Es gibt keinen typischen Viewport mehr
Der „klassische“ Workflow hat sich entwickelt, als Websites für Desktop-Computer gestaltet wurden. Zwar existierten immer schon unterschiedliche Monitore, doch es gab eine Kernzielgruppe mit einer bestimmten minimalen Bildschirmgröße. Für diese Zielgruppe und den entsprechenden Platzbedarf wurde die Website gestaltet, und es war ohne Probleme möglich, mit nur einem Layout über 95% der Website-Besucher zufrieden zu stellen.
Besucher mit einem größeren Viewport sahen einen Freiraum um die Seite, Besucher mit kleinerem Viewport mussten horizontal scrollen. Das war zu verkraften.
Mit dem Einzug der mobilen Endgeräte, insbesondere der Smartphones, wurde diese Kernzielgruppe aufgelöst. Heute betrachten die Besucher mit unzähligen Displays die Website. Selbst wenn man die drei häufigsten Viewport-Größen gestalterisch berücksichtigt, deckt man weit unter 50% der Besucher ab. Das ist natürlich inakzeptabel.
Aus diesem Grund bietet sich ein flexibles Design (responsive Design) an, das alle Displaygrößen berücksichtigen kann. Doch mit welchen Abmessungen gestaltet man dann das Layout in Photoshop?
Statische Layouts sind unbrauchbar geworden
Ein Mockup oder ein grafischer Entwurf in Photoshop zeigt immer die Ansicht der Website in einem bestimmten Viewport. Es ist natürlich möglich, neben der Desktop-Ansicht auch noch eine Tablet- und eine Smartphone-Version zu gestalten, doch auch diese Layouts zeigen nur eine Momentaufnahme – die Bereiche dazwischen sind nicht erkennbar.
Auch der Aufwand steht in keinem Verhältnis. Wenn dem Kunden fünf unterschiedliche Seitentypen gezeigt werden sollten, müssten mit statischen Layouts für die drei typischen Geräteklassen bereits 15 Mockups bzw. Layouts angefertigt werden! Sobald es eine Korrektur gibt, müssen alle Dateien angepasst werden.
Im Responsive Design ist es zudem sehr schwer zu planen, wann ein Gestaltungselement umbricht, oder ab welcher Display-Größe die Zeilenlänge des Textes verringert werden muss um eine gute Lesbarkeit zu garantieren. Bei komplexen Layouts ist es daher oft reine Glückssache wenn der Aufbau der Website am Ende tatsächlich so umgesetzt werden kann wie im Photoshop-Entwurf gezeigt.
Abgesehen davon weicht ein statischer Entwurf auch bei der detaillierten Ausarbeitung der einzelnen Elemente stark vom Endergebnis ab. Eine Website sieht nicht in allen Browsern gleich aus und muss das auch nicht. Ein statisches Design erweckt aber genau diese Erwartung und führt daher häufig zu Missverständnissen beim Kunden.
Zuletzt sei noch angemerkt, dass interaktive Elemente, Scrolling-Effekte, Animationen und die Performance mit statischen Entwürfen überhaupt nicht abgebildet werden können. Noch einmal zusammengefasst ergeben sich im klassischen Workflow also folgende Vor- und Nachteile.
Nachteile des klassischen Workflows
- Überflüssige Arbeit (z.B. viele Layouts)
- Falsche Erwartungshaltung beim Kunden durch statische Grafiken
- Flexible Layouts, Interaktionen, Animation lassen sich schlecht darstellen
- Eine fehlerhafte Planung führt zu aufwändigen Korrekturen
- Strukturelle oder funktionelle Änderungen haben oft Auswirkungen auf das Design, das führt zu doppelten Korrekturschleifen
- Die User Experience (z.B. die Benutzung per Touch-Screen) kann schlecht optimiert werden
- Der klassische Workflow ist langsam, unflexibel und somit teuer
Vorteile des klassischen Workflows
- Wir haben uns an diesen Ablauf gewöhnt
- Ein Projekt kann linear bearbeitet werden, einzelne Abteilungen oder Mitarbeiter arbeiten nacheinander an verschiedenen Bereichen der Website
- Der Workflow ist auch für Außenstehende leicht vorstellbar und anschaulich zu präsentieren
Responsive Webdesign Workflow
Da unzählige Mockups bzw. Layouts viel Arbeit bereiten, und dabei nicht einmal abbilden können was abgebildet werden muss, sieht der responsive Webdesign Workflow heute deutlich anders aus. Die Website wird von innen nach außen aufgebaut. Design und Code werden parallel entwickelt.
Das Internet ist in erster Linie ein Informationsmedium. Interessante und aktuelle Inhalte bilden somit das Herzstück jeder erfolgreichen Website. Das Design und die Technik dienen dazu, die Informationen bestmöglich zu präsentieren und benutzbar zu machen. Unterschiedliche Displaygrößen und Browser sollten daher hinten anstehen.
Es ist im Grunde genommen wie bei einem Buch: Es macht wenig Sinn sich schon Gedanken um die Covergestaltung und die Anzahl der Seiten zu machen, wenn noch nicht einmal der Text geschrieben wurde.
Mit Prototypen arbeiten
Damit die Inhalte der Seite unabhängig von der Situation des Besuchers immer optimal dargestellt werden, dreht man im Responsive Design den Workflow teilweise um.
Unmittelbar nach der Planung der Seite, wird mit HTML und CSS ein sog. interaktiver Protoyp entwickelt. Der Prototyp ist nicht gestaltet und dient dazu die Semantik, die Struktur und die Funktion der Website testen zu können. Man kann diesen Arbeitsschritt also als interaktives Mockup verstehen. Im Gegensatz zu statischen Mockups läuft der Prototyp im Browser und passt sich bereits an verschiedene Displaygrößen an. Er kann per Touch Screen bedient werden, reagiert auf unterschiedliche Ausrichtungen eines Geräts (z. B. Hoch- oder Querformat) und kann browserübergreifend getestet werden.
Der Prototyp durchläuft nun normalerweise diverse Korrekturschleifen. Da die Gestaltung allerdings äußerst reduziert ist, können Anpassungen schnell vorgenommen werden und haben keine Auswirkung auf das Design (was doppelte Korrekturen vermeidet).
Das Design entwickeln
Sobald der Prototyp in allen Testsituationen eine gute Figur abgibt und voll funktionsfähig ist, wird das Design entwickelt. Hierbei wird normalerweise kein vollständiges Layout mehr entworfen, sondern es werden der Reihe nach einzelne Elemente ausgewählt und gestaltet. Wenn für eine Präsentation doch ein vollständiges Layout benötigt wird, reicht i. d. R. die Ansicht einer typischen Unterseite aus.
Der Designer beginnt also beispielsweise mit der Gestaltung des Headers in Photoshop. Anhand des Prototypen kann er genau erkennen, welche Elemente flexibel gestaltet werden müssen und welche nicht. Sobald das Design des Headers fertig ist, wird die Gestaltung technisch umgesetzt und im Browser getestet. Fehler im Design werden dabei sofort erkannt und können schnell korrigiert werden. Sobald ein Element funktioniert, widmet man sich dem nächsten.
Ab diesem Zeitpunkt werden die Gestaltung und die technische Ausarbeitung der Website parallel vorangetrieben. Im Idealfall sind der Designer und der Entwickler dabei ein und dieselbe Person, denn so kann flexibel zwischen Code-Editor und Grafikprogramm gewechselt werden.
Wenn unterschiedliche Personen das Projekt bearbeiten wird der Ball immer zwischen Designer und Entwickler hin und her gespielt. Die Kommunikation zwischen den beteiligten Personen muss also exzellent sein.
Nachdem alle Bestandteile der Website gestaltet wurden, ist die Seite eigentlich auch schon fertig. Es fehlt lediglich noch ein wenig Feinschliff.
Direkt im Browser gestalten
Designer, die auch die technische Umsetzung übernehmen, gestalten häufig direkt im Browser. Das spart natürlich Zeit. Mit Hilfe von Plugins, Online-Tools und der Debug-Konsole des Browsers ist der passende CSS3-Code für die gewünschte Optik schnell erzeugt. Je nach Komplexität des Layouts entstehen nur noch einzelne Grafiken (z.B. Illustrationen) im Bildbearbeitungsprogramm. Die Website wird dann fast ausschließlich im Browser entwickelt.
Keine Seiten designen, sondern Module
Eine moderne Website besteht aus vielen verschiedenen Komponenten, die gemeinsam das Design bilden: Buttons, Formulare, Hinweis-Meldungen, Navigationsleisten etc. Alle diese Module werden gestaltet und anschließend in unterschiedlichen Zusammenstellungen auf der Website eingesetzt.
Ein moderner Webdesigner muss wissen, an welcher Stelle ein Element technisch abgeschlossen ist, damit er das Element so gestalten kann, dass es sich später auch flexibel einsetzen lässt. Diese modulare Vorgehensweise bei der Gestaltung ist auch anhand vieler Frameworks zu erkennen. Es gibt i. d. R. eine Vielzahl an Basis-Elementen für die verschiedenen Komponenten einer Website.
Mit der Smartphone-Ansicht beginnen
Damit das Layout auf kleinen Displays optimal dargestellt wird und zügig lädt, beginnt man heute üblicherweise mit der Smartphone-Version einer Website. Dieses Prinzip nennt man „Mobile First“.
Die Struktur und das Design werden dabei zunächst für kleine Bildschirme und schwache Systeme entwickelt. Wenn diese Ansicht optimiert ist, erweitert man die Website um größere Versionen, bis hin zur Desktop-Ansicht. Diese Vorgehensweise führt zu exzellenter Performance, funktionalen Designs und interessanten Inhalten. Allerdings erfordert sie auch ein deutliches Umdenken bei Designern und Entwicklern.
Start with the small screen first, then expand until it looks like shit. Time for a breakpoint! – Stephen Hay
Das Prinzip „Mobile First“ beschränkt sich dabei nicht nur auf das Design einer Website. Auch die Informationsarchitektur und die technische Umsetzung spielen in diesem Zusammenhang eine sehr große Rolle.
Nachteile des Responsive Web Design Workflows
- Designer, Entwickler und Agenturen müssen umdenken
- Designer und Entwickler müssen sehr gut zusammenarbeiten oder sind im Idealfall ein und dieselbe Person
- Die Anforderungen an den Kunden steigen
Vorteile des Responsive Web Design Workflows
- Das flexible Design, Animationen und Interaktionen lassen sich bereits in einer frühen Projektphase perfekt abbilden
- Das Design und die Struktur folgt den Anforderungen des Inhalts (Form follows Function)
- Fehler in der Konzeption werden frühzeitig (im Prototypen) erkannt und können behoben werden
- Design und Funktion werden Anfangs getrennt bearbeitet und können sich daher nicht gegenseitig negativ beeinflussen.
- Der responsive Workflow ist schnell – Design und Code können parallel bearbeitet werden.
Prototyping
Der moderne Workflow setzt sehr schnell auf einen funktionsfähigen Prototyp. Damit dieser Prototyp schnell entwickelt werden kann, haben sich in der jüngeren Vergangenheit sog. Frameworks, Boilerplates und Grid Systeme entwickelt. Die Grenzen zwischen diesen Hilfsmitteln verschwimmen – gemeint ist mit allen drei Begriffen eine Code-Grundlage, die Webdesigner bei der Entwicklung von interaktiven Prototypen unterstützt. Das Ziel ist, in möglichst kurzer Zeit einen Prototypen herzustellen, der auch als Grundlage für die fertige Website geeignet ist.
Die berühmtesten Vertreter solcher Frameworks sind wahrscheinlich Foundation und Bootstrap. Eine Liste aller mir bekannten Hilfsmittel findet ihr hier.
Neben Hilfsmitteln für das technische Grundgerüst existieren auch verschiedene Lösungen um Test-Inhalte in den Protoyp zu laden. Neben Platzhalter-Grafiken und Lorem-Ipsum-Texten existieren noch einige andere praktische Tools.
Style Tiles
Der Prototyp zeigt die Struktur, die Flexibilität und die gesamte Funktionalität der Website. Allerdings überhaupt kein Design. Es fehlt also noch ein Hilfsmittel, dass all das abbilden kann, was bisher nicht berücksichtigt wurde.
Da ein Design immer auch Strukturen abbildet, ist ein Layout schon zu viel des Guten. Die Lösung sind sog. Style Tiles. Hierbei handelt es sich um ein Hilfsmittel zur Entwicklung von Stilrichtungen für Websites.
In einem Style Tile werden alle für den Charakter der Website relevanten grafischen Elemente zusammengefasst. Das können u.a. Schriften, Farben, Icons, Buttons etc. sein. Ziel des Style Tiles ist es, verschiedene Stilrichtungen zu entwerfen und vergleichen zu können. Hat man sich für einen Stil entschieden, muss dieser nur noch auf den voll funktionsfähigen Prototypen angewendet werden. Die Website ist dann bereits sehr weit fortgeschritten.
Fazit
Der responsive Workflow stellt Designer und Agenturen vor einige Herausforderungen. Auf der einen Seite müssen lineare Strukturen (vor allem in Agenturen) abgebaut werden, andererseits müssen Web Designer heute über ein zumindest elementares Verständnis von der Funktionsweise einer Website verfügen.
Der neue Workflow erfordert zudem ein Umdenken bei allen Beteiligten des Projekts und zwingt sie dazu, besser zusammenzuarbeiten. Um Fehler schnell zu erkennen und aufwändige Korrekturschleifen zu vermeiden, wird möglichst schnell programmiert und immer wieder getestet. Das Design rückt ans Ende des Projekts und wird modular entworfen.
Mobile First + Progressive Enhancement
Dieser Artikel hat den allgemeinen Workflow im Responsive Design beschrieben. Um die Performance und die Usability einer Website zu verbessern, bietet es sich an die Seite nach den Konzepten „mobile First“ und „Progressive Enhancement“ umzusetzen. Das Projekt wird dabei zuerst für kleine Displays und schwache Geräte entwickelt und im zweiten Schritt für größere Displays und leistungsstärkere Systeme erweitert. Die Ergebnisse sind eine optimale Performance auf allen Geräten, die unkomplizierte Wartung und Erweiterbarkeit der Website und zufriedenere Besucher. Wenn ihr mehr erfahren möchtet, lest unbedingt den Folgeartikel Mobile First + Progressive Enhancement.
Hallo! Vielen Dank für diesen informativen und toll verfassten Blogpost! Bei dem Punkt mit dem Mobile First Design muss ich absolut zustimmen – tolle Ergänzung mit dem Zitat von Stephen Hay, musste da echt schmunzeln :) Weiter so und viele Grüße aus Köln
Hallo Jonas,
ich bin am Bookmarks aufräumen, und der Artikel bleibt drin. Immer noch gut. #Klassiker.
Der Link zum Zitat von Stephen Hay hat sich geändert:
https://bradfrost.com/blog/post/bdconf-stephen-hay-presents-responsive-design-workflow/
Statt bradfrost*web*.com. Brad Frost hat irgendwann seine Domain geändert und die alte anscheinend nicht behalten. War heute schon die dritte oder vierte URL mit dem Problem ;-)
Viele Grüße
Peter
Hey Peter, vielen Dank für dein Lob und natürlich auch für den Hinweis zur Quelle. lg Jonas
Sehr interessant beschrieben.
Spannend ist auch das Zitat von Stephen Hay im Beitrag. Das man mit dem kleinsten und schwächsten Gerätemodell anfängt hört sich gut an.
Würde mich auch interessieren, wie Ihr den Prototyping Prozess im Detail handhabt.
Danke für den Text.
Viele Grüsse
Sascha Thattil
Hey Leute,
erstmal soll gesagt sein der Artikel ist klasse, gute Arbeit an dieser Stelle.
Das Prinzip ist mir einigermaßen klar allerdings habe ich doch noch zwei Frage und zwar:
An welcher Stelle des Prozesse wird das Layout (nur der Aufbau) des Prototypen vom Kunden abgenommen? Workshops in denen man mit dem Kunden den Aufbau des Prototypen erarbeitet, ist ja nicht immer eine Option.
Die meisten meiner Kunden sind es gewohnt komplette Designs von den einzelnen Seiten zu sehen. Wie kann ich mit einem Prototypen der keine bis kaum gestalterische Aspekte berücksichtigt überzeugen? Immerhin haben die Kunden meist wenig Vorstellungskraft.
Hallo Patrick, wir haben wenig Probleme damit unseren Kunden den Prototypen vor der Erstellung des Layouts zu zeigen und diesen auch abnehmen zu lassen. Wichtig ist, dass der Kunde versteht warum der Workflow so herum mehr Sinn ergibt und dass ihm klar ist was im Prototyp relevant ist und wie der nächste Schritt im Projekt aussieht. Vor dem Hintergrund modularer Layouts werden Ansichten einzelner Unterseiten auch zunehmend schwierig. Beispiel ACSS.
Hey Jonas,
danke für die schnelle Antwort, mir ist damit vieles klarer geworden.
Ihr macht klasse Arbeit weiter so!
Ps: Wäre es vielleicht Interessant, wie ihr in eurer Agentur Cross-Browser-Testing erledigt? Ich bin in letzter Zeit auf der Suche nach professionellen Möglichkeiten bzw. Tools die dies ermöglichen. Ihr seit Profis und mich würde es brennend interessieren wie ihr das meistert (vielleicht auch eine Idee für einen neuen Artikel :=) ).
Beste Grüße und Dank
Patrick
Ich würde sagen, dass die Abnahme der Prototypen ja ein Teil eines iterativen Prozesses sind und damit nicht überraschend kommen. Die sponatne Frage, die ich habe: Wer ist denn das Gremium, dass die Prototypen abnehmen muss? Daran solltet Ihr euch orientieren.
Danke, super Artikel für mich als Einsteiger ins Webdesign. Bisher eine Seite „klassisch“ mit Photoshop gedacht und immer wieder dabei den Kopf geschüttelt und gedacht „das kanns doch nicht sein…“
Ich hoffe, dass ich für mich diesen Workflow adaptieren kann und v.A. mir die entsprechenden Skills für die Arbeit mit Prototypen aneignen kann.
Jetzt kann ich zumindest modern einsteigen :P
Danke für den Beitrag. Wir sind mittlerweile auch überwiegend zum direkten arbeiten an Prototypen übergegangen – spart viel Zeit und Kunden können viel besser begreifen was sie erhalten. Lediglich Grundelemente wie Menü, Header und Footer lohnen sich zuvor zu gestalten.
[…] […]
Ein sehr interessanter und hilfreicher Beitrag. Ich war in den letzten Jahren schon von selbst dazu über gegangen, das Design erst nach bzw im Laufe der Struktur zu entwickeln. Vor allem weil es mir zu umständlich war das ps Design 1 zu 1 ins html zu quetschen. Ich dachte bisher immer, dass das daran läge, dass ich als Laie zu schlecht in ps bin und eigentlich unprofessionell arbeite. Dein Artikel hat mir daher neben der Information auch viel Hoffnung gegeben ich freue mich wieder richtig demnächst meine grobe Designskizze zum (lange überfälligen) redesign meines Blogs umzusetzen. Danke!
Sehr interessanter Beitrag. Vielen Dank dafür! Wurde alles sehr übersichtlich dargestellt und der Text ist eine Bereicherung.
[…] Hier gibt es einen tollen Beitrag zum Response Webdesign und auch das pdf von Jonas Hedwig aus seinem Workshop bei der Webinale war eine […]
Ich will ja nicht meckern, ach was, ich will meckern: wo spielen in diesem Modell die Inhalte eine Rolle, oder gehst Du weiterhin davon aus, das Content das ist, was jemand in die super-responsive gebauten Container quetschen muss?
Die Inhalte spielen im Responsive Workflow eine entscheidende Rolle, da der Prototyp auf Basis der inhaltlichen Vorüberlegungen erstellt wird. Das heißt nicht, dass jeder Satz 100% ausformuliert werden sein muss, aber es sollte eine sehr klare Vorstellung des Inhalts vorhanden sein. Im Idealfall arbeitet man bereits im Prototypen mit echten Inhalten. Diese Grafik zeigt es eigtl. recht deutlich.
Hallo, ich bin gerade über dein Präsentation zum Thema responsive Webdesign gestoßen. Und deine „Quizfrage“ hätte ich auch gern beantwortet. Wie groß muss meine Photoshopdatei sein?
Ich kenn mich nicht wirklich damit aus und hätte gern von einem Fachmann eine „sichere“ Antwort :)
Vielen Dank!!!!
Hallo Charlott,
die Photoshop-Datei wird im responsive Design (normalerweise) nicht mehr 1:1 technisch nachgebaut. Daher ist die Größe egal. Das Layout ist im Browser später ohnehin flexibel und deckt alle Viewport-Größen ab. Das Photoshop-Layout, sofern es überhaupt noch komplett in PS erstellt wird, dient daher eher als Orientierung und nicht mehr wie früher als exakte Vorlage. Die Größe der Datei orientiert sich allerdings häufig an der Desktop-Version der Website.
Hallo Jonas,
toller Artikel – danke.
Ein Problem bei diesem Workflow gibt es nur, wenn dem Kunden das Layout nicht gefällt, dann wäre auch der Prototyp „umsonst“. Oder lässt du dir vom Kunden das statische Mockup absegnen bevor du mit dem Prototyp beginnst?
Verwendest du für dein Mini-Framework also gar keine Hilfsmittel/Tools, sondern beginnst immer bei null?
Danke.
Layout und Prototyp entwickle ich getrennt. Der Prototyp ist dabei nur elementar gestaltet, daher hat ein abgelehntes Design keine Auswirkungen auf diesen Arbeitsschritt. Abgesehen davon lasse ich die großen Milestones aber auch vom Kunden absegnen. Sicher ist sicher :)
Mein »Mini Framework« basiert sehr wohl auf Vorlagen. Nur eben nicht auf kompletten Frameworks mit Rastern und Design-Elementen. Ich nutze fast immer die HTML5Boilerplate mit normalize.css als Basis, sowie Modernizr mit integriertem respond.js und HTML5SHIV.
[…] möchte ich den Mobile First Ansatz verfolgen. Besonders haben mich zwei Artikel inspiriert, “Der Workflow im Responsive Web Design – Prototyping & Co. ” und “Mobile First + Progressive Enhancement “. […]
Hallo Jonas,
Super Artikel. Eine Frage hätte ich dazu noch:
Wenn du den Prototyp mittels den genannten Frameworks erstellst, benutzt du dann das CSS weiter für die grafisch aufbereitete Version oder wird das Framework nur für den Prototyp verwendet? Welches verwendest du z.B. In dem gezeigten grauen Screenshot?
Hallo Alex,
ich persönlich baue mir eigtl. immer für jeden Kunden ein Mini-Framework selbst zusammen. Das entspricht dann genau dem Projekt und bring keinen Overhead mit. In dem von dir genannten Screenshot nutze ich daher kein spezielles Framework. Im Idealfall wird der Prototyp immer weiterentwickelt und bildet die Grundlage der fertigen Website. Ob diese Vorgehensweise sinnvoll ist, ist jedoch stark vom Projekt und vom eigenen Workflow abhängig. Man muss von Beginn an sehr ordentlich arbeiten, damit nicht später „Leichen“ im Code zurück bleiben. Bei den großen Frameworks sehe ich genau da die größte Gefahr.
Hi Jonas,
dieses Vorgehen finde ich gut. Dann muss man nicht zweimal anfangen, sondern kann Dinge aus dem Prototyp gleich weiter verwenden. Die grundlegende Struktur z.B. kann man ja direkt übernehmen oder andere Dinge.
Aus dem Grund hatte ich auch gefragt, da bei großen Frameworks am Ende für die fertige Seite dann doch wieder einiges angepasst werden muss (meine Seite soll ja nicht aussehen wie 100 andere) und es viel Overhead gibt.
[…] https://blog.kulturbanause.de/2013/06/workflow-responsive-web-design-prototyping/ http://www.designtagebuch.de/responsive-webdesign-eine-herausforderung-fuer-webdesigner/ http://www.responsive-webdesign.mobi/was-ist-responsive-webdesign/ http://bradfrostweb.com/blog/mobile/bdconf-stephen-hay-presents-responsive-design-workflow/ Share and Enjoy: […]
Klasse Artikel, wir werden das berücksichtigen und unseren Prozess demnächst anpassen. :)
Leider gehen viele Agenturen immernoch nach dem alten Muster vor und am Ende ist dann Nacharbeit erforderlich… Ein gutes deutschsprachiges Tool um zu testen, ob das erstellte Responsive Design dann auch responsiv ist: merky.de/656605 Hier kann für mobile Engeräte und Tablets getestet werden.
Hallo Jonas, toller Artikel. Er bestätigt mich in der Absicht, das zwischenzeitlich total veraltete Layout unseres 1995 gelaunchten Webprojekts überarbeiten zu lassen. Und zwar in ein neues responsives Layout wie in dem Artikel beschrieben (ohne wp, joomla usw.). An wen kann ich mich wenden?
Hallo Thomas,
wir melden uns per E-Mail bei dir.
Jörg und Jonas: Ist es nicht so, dass „mobile first“ nicht den Workflow der Webentwicklung bezeichnet, sondern dass hinsichtlich Stylsheets „mobile first“ geladen wird und dann bei größeren Bildschirmauflösungen die weiteren Styles für Tablet, Screen, etc.? So hatte es doch zumindest Marcotte Ethan „erfunden“!?
In der Tat fällt das Umdenken schwer. Bei sich selbst, viel mehr aber beim Kunden. Der ist es eben auch gewohnt, Designs für einzelnen Seiten vorgesetzt zu bekommen.
Wir haben aber das Glück, unkomplizierte Kunden zu haben, die keine eigens erstellten Responsive-Designs vorgelegt bekommen möchten. Also fällt immerhin schon mal diese Mehrarbeit weg, wenn man aus dem – für den Kunden gewohnten – Screendesign die responsive Variante erzeugt. Und dass interaktive Elemente nicht gut gelayoutet werden können, ist den meisten auch klar.
D.h. sobald der Kunde den Gesamteindruck/das Gesamt-Webdesigns in Form von ein paar Screendesigns freigegeben hat, wird darauf alles weitere flexibel kodiert und programmiert.
Guter Beitrag! Für ein Projekt haben wir das letztens so realisiert: Prototyp im Browser, aber von Desktop Richtung mobile (also nicht mobile first). Das liegt sowohl dem Kunden wie dem Designer näher.
Kommen die Kunden bei dir mit den Style Tiles zurecht? Das verlangt ja schon Abstraktionsvermögen.
Prototypen sind ja nicht neu. Allerdings ist es gerade in Agenturen doch schwierig dem „potentiellen Auftraggeber“ ein Budget für einen Programmierer etc. abzuringen. Gerade wenn man für die Umsetzung noch auf einen Auftrag warten muss.
Sehr gut geschrieben! Bei den Vorteilen des klassischen Workflows musste ich etwas schmunzeln: „Wir haben uns an diesen Ablauf gewöhnt“ :)
toller artikel! ich glaube aber, dass der vorgestellte workflow den meisten (technisch wenig versierten) kunden im moment noch zu viel abverlangt. eine zwischenlösung wäre vllt., einen ersten (starren) entwurf für eine übliche desktop auflösung zu gestalten und dem kunden zu präsentieren – so wie bisher. basierend darauf entwickelt man dann das responsive design parallel in ps und browser, in permanenter rücksprache mit dem kunden – ohne weitere entwürfe in ps zu gestalten zu müssen.
Ich löse das immer so, dass ich Screenshots des Prototypen mache. Dann habe ich ein 100% realistisches Ergebnis und der Kunde eine statische Grafik. Gleichzeitig habe ich keinen Mehraufwand, da mein Workflow sich ja nicht verändert.
Den hier beschriebenen Workflow setze ich übrigens mittlerweile ohne Ausnahme bei allen Kunden ein. Unabhängig davon, ob die Kunden technisch versiert sind oder nicht. Probleme gab es da bisher noch nicht.
Bis jetzt habe ich meine Seiten immer auf dem lokalen Server (MAMP) entwickelt. In der Korrekturphase habe ich dem Kunden auch Screenshots zum Abstimmen geschickt. Finale Präsentation lief dann bei mir auf dem lokalen Server. Wenn alles OK war, Seite hochgeladen, getestet, korrigiert etc…
Diesmal ist die Seite, an der ich arbeite, etw. umfangreicher. Der Kunde sitzt auf mehrere Länder verteilt. Jedesmal kurz nach Deutschland jetten, ist nicht drin, aber natürlich wollen Alle mitreden und vorallem die Seite nach Bedienbarkeit testen. Also, nur mit Screenshots komme ich nicht mehr weit.
Eine Subdomain auf der URL des Kunden, oder auf meiner Website nur zur Präsentationszwecken hochzuladen, scheint mir etwas zu aufwendig (hochladen, testen, korrigieren…), weil die Seite einfach zu mächtig ist. Wahrscheinlich wäre hier Server-Staging angebracht. Aber wie?… Wie machst Du Deine Präsentationen heutzutage?
Hallo Tonguc, wir arbeiten mittlerweile in den meisten Fällen von Anfang an im Browser und stellen dem Kunden einen Link zum Testserver bereit. Er sieht dann verschiedene Schritte der Entwicklung. Wir haben unser Vorgehen hier beschrieben und du kannst es dir z. B. hier in Form unserer Case Studies anschauen. Ich hoffe das hilft dir weiter!
sehr toller Artikel!
und ich stimme dem voll und ganz zu, selbst in meiner Ausbildung lerne ich „Mobile first“. Da es sich sonst anders schlecht umsetzen lässt, wozu gibts die Möglichkeit auch bestimmte Zeilen/Raster per Größe zu definieren :)
Die Meisten die dies nicht so gemacht haben (aber überhaupt die Meisten), gestalten eine extra Website für’s Handy das sich dann meistens mit einem „m“ vor dem Namen ausstattet, wie auch bei facebook. Es ist natürlich leichter, da man nicht darauf achten muss das bestimmte Elemente nur in xs sichtbar sind und andere unsichtbar… Aber einige verlangen da doch eher eine kommerziell anpassbare Website.
echt Top Artikel
(aber man sollte in manchen Situationen auch mehrere Frameworks gestalten und dem Kunden vorlegen, z.B. dann wenn er unschlüssig ist wie diese aussehen soll.
Um Gefahren vorzubeugen in die Falsche Richtung zu arbeiten ;)
was mir da sehr gut gefällt das jede Element für sich selbst funktionieren muss, damit man zur Not auch die Position ändern kann, sollte der Kunde etwas anderes wollen. *thumb-up*