Zur Suche springen Zur Navigation springen Zum Hauptinhalt springen Zum Footer springen

Der Workflow im Responsive Web Design – Prototyping & Co.

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.

Der klassische Webdesign-Workflow
Der klassische Webdesign-Workflow

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.

Verschiedene Viewport-Varianten einer nicht optimierten Website
Verschiedene Viewport-Varianten einer nicht optimierten Website

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.

Unzählige Mockups im Responsive Design
Unzählige Mockups im Responsive Design

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.

Unterschiedliche Website-Darstellung in verschiedenen Browsern am Beispiel eines Buttons
Unterschiedliche Website-Darstellung in verschiedenen Browsern am Beispiel eines Buttons

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

Vorteile des klassischen Workflows

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).

Der Workflow im Responsive Web Design
Der Workflow im Responsive Web Design

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.

Prototyp und Design eines echten Projekts im direkten Vergleich
Prototyp und Design eines echten Projekts im direkten Vergleich

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.

Verschiedene Komponenten einer Website: Buttons und Medieninhalte
Verschiedene Komponenten einer Website: Buttons und Medieninhalte

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

Vorteile des Responsive Web Design Workflows

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.

Exemplarisches Style Tile für Facebook. Der Stil der Website ist klar erkennbar
Exemplarisches Style Tiles für Facebook. Der Stil der Website ist klar erkennbar

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.

Geschrieben von Jonas

Benutzerbild

Jonas ist Gründer der Agentur kulturbanause und des kulturbanause Blogs. Er arbeitet an der Schnittstelle zwischen UX/UI Design, Frontend und Redaktion und hat zahlreiche Fachbücher und Video-Trainings veröffentlicht. Jonas Hellwig ist regelmäßig als Sprecher auf Fachveranstaltungen anzutreffen und unterstützt mit Seminaren und Workshops Agenturen und Unternehmen bei der Planung, der Gestaltung und der technischen Umsetzung von Web-Projekten.

Jonas Hellwig bei Xing

Feedback & Ergänzungen – 39 Kommentare

  1. Webdesign Köln
    schrieb am 29.03.2021 um 13:52 Uhr:

    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

    Antworten
  2. Peter Müller
    schrieb am 04.02.2021 um 21:50 Uhr:

    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

    Antworten
    • Jonas Hellwig
      schrieb am 08.02.2021 um 09:24 Uhr:

      Hey Peter, vielen Dank für dein Lob und natürlich auch für den Hinweis zur Quelle. lg Jonas

      Antworten
  3. Sascha Thattil
    schrieb am 06.06.2019 um 06:24 Uhr:

    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

    Antworten
  4. Patrick
    schrieb am 06.10.2016 um 16:59 Uhr:

    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.

    Antworten
    • Jonas Hellwig
      schrieb am 07.10.2016 um 09:57 Uhr:

      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.

      Antworten
      • Patrick
        schrieb am 11.10.2016 um 22:37 Uhr:

        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

    • Sascha Stoltenow
      schrieb am 07.10.2016 um 15:09 Uhr:

      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.

      Antworten
  5. Sarah
    schrieb am 05.02.2016 um 18:00 Uhr:

    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

    Antworten
  6. P.Gersöne
    schrieb am 15.03.2015 um 03:49 Uhr:

    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.

    Antworten
  7. Erstellung eines Designs / Zweifel nach der Umsetzung
    schrieb am 03.09.2014 um 17:04 Uhr:

    […] […]

    Antworten
  8. Salim
    schrieb am 02.09.2014 um 20:51 Uhr:

    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!

    Antworten
  9. Swallie
    schrieb am 18.08.2014 um 10:14 Uhr:

    Sehr interessanter Beitrag. Vielen Dank dafür! Wurde alles sehr übersichtlich dargestellt und der Text ist eine Bereicherung.

    Antworten
  10. So war’s beim Workshop „Modernes Webdesign-Photoshop und Design in the Browser“ bei der Webinale « KB&B – The Kids Group
    schrieb am 26.06.2014 um 14:36 Uhr:

    […] Hier gibt es einen tollen Beitrag zum Response Webdesign und auch das pdf von Jonas Hedwig aus seinem Workshop bei der Webinale war eine […]

    Antworten
  11. Sascha Stoltenow
    schrieb am 19.02.2014 um 06:45 Uhr:

    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?

    Antworten
    • Jonas Hellwig
      schrieb am 19.02.2014 um 20:58 Uhr:

      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.

      Antworten
  12. Charlott
    schrieb am 06.01.2014 um 09:26 Uhr:

    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!!!!

    Antworten
    • Jonas Hellwig
      schrieb am 07.01.2014 um 09:22 Uhr:

      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.

      Antworten
  13. Martin Ortner
    schrieb am 15.10.2013 um 13:27 Uhr:

    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.

    Antworten
    • Jonas Hellwig
      schrieb am 15.10.2013 um 19:22 Uhr:

      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.

      Antworten
  14. Grundlage des neuen Themes | Marcus Kramer
    schrieb am 17.08.2013 um 16:14 Uhr:

    […] 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 “. […]

    Antworten
  15. Alex
    schrieb am 15.08.2013 um 09:58 Uhr:

    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?

    Antworten
    • Jonas Hellwig
      schrieb am 15.08.2013 um 11:00 Uhr:

      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.

      Antworten
      • Alex
        schrieb am 15.08.2013 um 11:27 Uhr:

        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.

  16. WEB Blog » Responsive Webdesign - Ein Überblick über ein beliebtes Buzzword
    schrieb am 08.08.2013 um 17:00 Uhr:
  17. Michael Grohe
    schrieb am 11.06.2013 um 21:30 Uhr:

    Klasse Artikel, wir werden das berücksichtigen und unseren Prozess demnächst anpassen. :)

    Antworten
  18. boomerang
    schrieb am 10.06.2013 um 10:04 Uhr:

    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.

    Antworten
  19. Thomas
    schrieb am 04.06.2013 um 17:47 Uhr:

    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?

    Antworten
    • Jonas Hellwig
      schrieb am 06.06.2013 um 09:09 Uhr:

      Hallo Thomas,

      wir melden uns per E-Mail bei dir.

      Antworten
  20. ayberg
    schrieb am 04.06.2013 um 15:51 Uhr:

    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“!?

    Antworten
  21. ayberg
    schrieb am 04.06.2013 um 13:31 Uhr:

    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.

    Antworten
  22. Jörg Auf dem Hövel
    schrieb am 04.06.2013 um 13:08 Uhr:

    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.

    Antworten
  23. Bernd Hellmuth
    schrieb am 04.06.2013 um 12:50 Uhr:

    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.

    Antworten
  24. Stelios
    schrieb am 04.06.2013 um 12:18 Uhr:

    Sehr gut geschrieben! Bei den Vorteilen des klassischen Workflows musste ich etwas schmunzeln: „Wir haben uns an diesen Ablauf gewöhnt“ :)

    Antworten
  25. nitnat
    schrieb am 04.06.2013 um 10:30 Uhr:

    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.

    Antworten
    • Jonas Hellwig
      schrieb am 04.06.2013 um 11:09 Uhr:

      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.

      Antworten
      • Tonguc
        schrieb am 12.02.2016 um 18:45 Uhr:

        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?

      • Jonas Hellwig
        schrieb am 12.02.2016 um 19:28 Uhr:

        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!

    • unkownSoul
      schrieb am 24.01.2014 um 09:29 Uhr:

      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*

      Antworten

Kommentar zu dieser Seite

Wir freuen uns über Anregungen, Ergänzungen oder Hinweise zu Fehlern. Wir lesen jeden Eintrag, veröffentlichen aber nur, was den Inhalt sinnvoll ergänzt.

Design-Projekte mit kulturbanause

Unsere Leinwand ist der Browser und wir beschäftigen uns seit 2010 intensiv mit dem Thema Responsive Design. Wir realisieren flexible Web-Layouts und modulare Design Systeme.

Responsive Webdesign-Leistungsangebot →

Schulungen von kulturbanause

Wir bieten Seminare und Workshops zu den Themen Konzept, Design und Development. Immer up-to-date, praxisnah, kurzweilig und mit dem notwendigen Blick über den Tellerrand.

Übersicht Schulungsthemen →