Responsive Design Workflow-Probleme: Wir können davon lernen, wie wir Projekte machen wollen

von timo / 22. März 2013 / Tags: , ,

Workflow Das Schwierige an Responsive Design Projekten ist nicht das Design, sondern der Arbeitsablauf. Die größten Workflow-Probleme.

Responsive Design ist zu einem Qualitätsstandard für zeitgemäße Websites geworden. Diesen zu erreichen ist anspruchsvoll. Auf dem Weg dorthin entstehen schnell selbstproduzierte Workflow-Probleme - insbesondere bei großen Agenturen, großen Kunden und arbeitsteiligen Projektteams.

Eine Website responsive zu gestalten fordert Designern, Konzeptern und Frontend-Entwickern vieles ab. Die größten Anstrengungen sind dabei aber nicht leistungsfähiges CSS, fluides Design oder flexibles Layout, sondern der Responsive-Workflow. Hier entstehen die Probleme, die anstrengend sind. Fehler in der Herangehensweise und in der Zusammenarbeit führen schnell mal zu einem doppelt so teurem Projekt oder einer Website, die dürftig funktioniert und miserabel performt.

Responsive Webdesign ist dabei nicht das Problem. Das Problem sind falsche Erwartungen, veraltete Prozesse und schlechte Gewohnheiten.

Die größten Responsive-Design-Workflow-Fehler:

Design in 3 Versionen denken

Ein 3-Versionen-Vorgehen ist naheliegend und ehrenhaft: Desktop, iPad und iPhone sind heute die populärsten Geräte. Auf diese Weise wird versucht für Desktop, iPad und iPhone das Beste zu konzipieren und zu gestalten.

Probleme: Das 3-Versionen Vorgehen erhöht den Aufwand massiv: Drei Versionen bedeutet meist aber auch 3 völlig unterschiedliche Navigations- und Interaktionsmechanismen, da alle 3 gestaltet und gescriptet werden müssen. Auch wenn auf die gleiche Code bzw. inhaltliche Reihenfolge der 3 Versionen geachtet wird, steigt der Aufwand immens. Dies ist bereits in der Konzeptions- und Designphase zu beobachten und setzt sich im Umsetzungsprozess weiter fort.

Ein Beispiel: Die Artikelebene geht in der Desktop-Version in einer Lightbox auf. Auf dem iPad lädt aus Platzgründen eine neue Artikelseite und auf dem iPhone schiebt sich, wie bei nativen iPhone-Apps, die Artikelansicht von rechts rein. Universell ist besser: Ein Rollo-Effekt (der neue Inhalte schiebt den Inhalt darunter einfach nach unten) wäre für alle drei Geräte nutzerfreundlichste Wahl gewesen.

Das 3-Versionen-Vorgehen greift zu kurz: Die Geräte- und Bildschirm-Diversität nehmen weiter zu: Tablets werden kleiner (iPad mini, / 7-inch-tablets wie Nexus 7) und Smartphones werden größer (Samsung Galaxy Note) Wer weiß, wie groß das nächste iPhone sein wird oder ob der nächste Trend 5.5-inch-Tablets sind?

Workflow-Verbesserung: Das Design muss als universell, modular und fluide begriffen werden, also ein Design, welches sich den unterschiedlichen Stadien anpasst. Responsive Design schafft so ein Sorgenfrei-Paket: Die Website sieht überall okay aus.

“Who knows what will be under our Christmas tree two years from now? … but its likely to be connected to the internet.” - Brad Frost, Beyond Media Queris, 2012

Ein universelles Vorgehen bedeutet weder, dass das Design zweitklassig ist, weil es sich auf dem kleinsten gemeinsamen Nenner einpendelt, noch dass die Website überall gleich aussieht und ohne spezielle gerätespezifische Bedienkonzepte auskommen muss.
Im Gegenteil: Das grundlegende Design ist universell und leistungsstark und kann dann via media queries geräte- und viewport-spezifisch verfeinert werden.

Kann man dieses fertige Design responsive umsetzen?

Designen wie immer: pixelgenau und mit einem 960er-Raster. Wenn das Design fertig ist, wird in der Frontend-Abteilung gefragt: Lässt sich das responsive umsetzen?

Problem: Ohne das Design gesehen zu haben, wird es bei typischen Websites mindestens schwer werden oder viel schwerer und aufwendiger, als es sein müsste. Denn das Design ist bereits fertig und es wurde viel Mühe und Zeit in die Gestaltung investiert.

Responsive Design fängt mit Design an und kann nicht ausschließlich durch die Frontend-Entwicklung gewährleistet werden. Ist ein Design nicht systematisch responsive entwickelt, kann die Frontententwicklung zwar einiges retten, aber das Ergebnis wird immer ein aufwendig erreichter Kompromiss sein.

Erschwerend kommt hinzu, dass sich die Zusammenarbeit im Projekt konfrontativ gestaltet:

Frontend vs. Design. Die Frontendentwickler kämpfen für notwendige Vereinfachung und die Designer sehen ihre schön gestaltete Website in Gefahr. Das ist eine schlechte Basis um eine gute, anpassungsfähige und nutzerzentrierte Website zu bauen. Klar ist: Es wird lange dauern und die Website wird aufgrund der vielen Kompromisse maximal mittelmäßig sein.

“We’ve been treating responsive design like it’s a [...] an implementation problem. [...] In fact, it’s an issue for everyone involved: designers, developers, content specialists, the people who commission websites and those who structure the teams who make the websites.”
- Andy Clark, Encouraging better client participation in responsive design projects

Workflow-Verbesserung: Bereits im Anfangsprozess interdisziplinär (Design, Konzept, Frontend) zusammenarbeiten und früh einen HTML-Prototyp bauen und im Browser designen.

Responsive im 2. Release

Das Vorgehen Responsive ja, aber erst im 2. Release ist ein typischer Kundenwunsch und macht aus dessen Perspektive auch durchaus Sinn, denn das primärer Bedürfnis lautet: Die Website soll so schnell wie möglich online gehen. Das Ziel soll nicht durch zusätzliche Features gefährdet werden. Also werden alle potenziellen Störfaktoren in den zweiten, dritten oder vierten Release verschoben.

Problem: Responsive Design lässt sich nicht als zusätzliches Feature an eine bestehende Website ranprogrammieren. Vieles muss von Grund auf neu gestaltet und gebaut werden. Das meiste des CSS und des HTML-Codes aus Release eins werden damit unbrauchbar und müssen umgeschrieben werden. Auch der gesamte Testprozess muss von vorne beginnen.

Workflow-Verbesserung: Bereits im 1. Release eine Responsive-Basis-Variante gestalten. Durch fluide Raster und einer einfachen Column-Drop-Logik sieht die Website auf unterschiedlichen erstmal in Ordnung aus: alles ist les- und bedienbar. Im 2. Release werden dann spezielle Module für spezielle Auflösungen und Geräte verbessert z.B. Touchevents, Gestaltungsalternativen, um die Nutzerfreundlichkeit weiter zu erhöhen.

Responsive Design ohne den Kunden machen

Es gibt zwei typische Ausprägungen wie Responsive Design ohne Kunden gemacht werden kann: (1) Dem Kunden sagen: die Website wird responsive und sieht damit überall gut aus. Er sieht die fertige Website erst am Ende des Projekts beim Abnahmeprozess wieder. (2) Dem Kunden nichts sagen: 2013 ist es selbstverständlich, dass eine Website responsive gestaltet ist. Dies gehört einfach zum Qualitätsstandard von zeitgemäßen Websites.

Beides produziert Probleme: Der Kunde wird immer merkwürdige Endgeräte besitzen auf denen seine Website nicht gut aussehen wird - sei es nur ein typisches Blackberry. Der Kunde wird die Leistung, die in eine responsive Website geflossen ist, nicht schätzen, weil er nichts davon weiß. Er versteht die fantastischen Fähigkeiten eines Responsive Ansatzes nicht, weil er nicht weiß, was es ist, und die Vorteile nicht kennt. Er wird außerdem noch kritisieren, warum so viel Entwicklungszeit in ein fluides Raster und in die Anpassungsfähigkeit geflossen ist.

“Don’t wait until after weeks of work before having a “big reveal.” Down this road lies frustration and resentment. Instead, keep clients involved at every step, all the way through the design process, and not only at those traditional sign-off points.
[...] Clients love to feel involved in the design process. [...]
- Andy Clark, Encouraging better client participation in responsive design projects

Workflow-Verbesserung: Gutes tun und mit dem Kunden darüber reden. Den Kunden von Anfang in den responsive Gestaltungsprozess involvieren. Wenn die Kunden den Prototyp bereits im Frühstadium auf ihrem iPhone erleben, werden sie von Anfang begeistert sein. Die Kunden-Agentur-Beziehung kann so in eine neue Dimension der Zusammenarbeit vordringen. Und der Bugtracker wird am Ende des Projekts weniger voll und sowohl der Kunde als auch die Agentur werden zufriedener sein.

Desktop first

Nur menschlich, mit dem Vertrauten wird begonnen: Zuerst wird die Desktop-Version gestaltet. Das Design für andere Geräte und Auflösungen wird dann anschließend vom Desktop-Design abgeleitet.
Durch ein desktop-zentriertes Design allerdings entstehen vielerlei Probleme:

Probleme: Ein Desktop-Design ist immer komplizierter als ein Design für iPhone oder iPad, ganz einfach schon deshalb, weil mehr Platz zur Verfügung steht, der gefüllt werden will. Ein Interaktionsdesign, welches auf Mausbedienung ausgelegt ist, ist nicht automatisch mit Fingern leicht bedienbar.

Workflow-Verbesserung: Mobile-first oder iPad-first-Strategien als Designprinzip ausrufen. Die Folgen: Das Design wird fokussierter. Es wird sich auf viel stärker auf das Wesentliche beschränkt. Die Hauptfunktionen der Website werden stärker herausgearbeitet. Sekundäre Navigationselemente und Zusatzinfos, die für Desktop-Designs ganz typisch sind, wie Metanavigationen, Co-Branding und Partner-Leisten, die oft nur aus Gewohnheit da sind, verschwinden. Denn plötzlich wird Platz ein knappes Gut und es muss sich auf das Wesentliche konzentriert werden.

Auch wirkt sich Touch als Interaktionsprinzip komplextätsreduzierend aus. Wenn eine Website leicht mit den Fingern bedienbar ist, kann sie immer auch mit der Maus bedient werden. Umgekehrt ist dies nicht so.
Diese Reduzierung und Fokussierung spart Zeit und schafft eine bessere Website für alle Geräte.

Unter Kopfhören verstecken

Der klassische Wasserfall-Prozess in Agenturen hat eine große Stärke: Zusammenarbeiten kann vermieden werden. Jede Disziplin arbeitet alleine und nacheinander ihre Aufgaben ab. Jeder kann den größten Teil der Arbeitszeit in Ruhe unter seinen Kopfhörern verbringen.

Problem: Es werden viele unnötige Dokumente produziert. Probleme werden verschleppt, und mit wichtigen responsive Design Fragen, wird sich erst gar nicht beschäftigt werden. Je länger der Wasserfall fließt, desto mehr Probleme und Frustration stauen sich an.

Workflow-Verbesserung: Kopfhörer abziehen. Zusammen Musik hören und zusammen arbeiten. So werden Spezifikationen kürzer und das Team konzentriert sich schneller auf die wichtigen Probleme. Eine Website responsive zu gestalten, ist anspruchsvoll, das kann keine Disziplin alleine schaffen. Soll das Projekt wirklich gut werden, dann muss frühzeitig zusammen und interdisziplinär im Browser und auf unterschiedlichen Endgeräten gestaltet, getestet und verbessert werden.

Responsive ist ganz easy

Responsive Design ist gleich fluides Design, also % statt px. Mehr ist es nicht. Das haben wir früher schon gemacht. Das nannten manche barrierefrei.

Problem: Eine solche Betrachtungsweise greift viel zu kurz. Es wird nur die Oberfläche betrachtet und diese gar nur grob. Responsive Design ist nicht nur fluides Raster, flexible Bildgrößen und media queries, sondern auch Ladezeit, Inhaltsstrategie, Interaktion, gerätespezifische Interaktionsmöglichkeiten, Benutzerfreundlichkeit und Lesbarkeit. Wird diese Komplexität missachtet, werden im Projektverlauf immer und immer wieder Probleme auftauchen.

Workflow-Verbesserung: Das Thema Responsive Design von Anfang an ernst nehmen. Responsive Design ist keine neue Umsetzungsstrategie, sondern verändert die Projektarbeit radikal.

Ich kann alles kontrollieren: Jeden Pixel bei jeder Auflösung

Der Wunsch jede Pixel kontrollieren zu können, stammt aus einem alten Medium: Print. Im Print steht alles fest: Die Ausmaße, die Papierqualität, die Druckmaschine. Designer können zu 100% die Ausgabe kontrollieren. Das Web ist nicht wie Print nur digital. Das Web ist das Web, ein eigenständiges Medium, mit eigenen Möglichkeiten und eigenen Restriktionen.

Problem: Das Web lässt sich nicht einsperren, es verflüchtigt sich – beyond desktop. Das Web findet nicht mehr nur am Desktop-Computer - in einer scheinbar kontrollierbaren Umgebung - statt. Das Web ist immer und überall. Aufgrund des stetig wachsenden Marktes an webfähigen und mobilen Endgeräten kann das Design nicht mehr starr und pixelgenau für eine Auflösung und ein spezielles Zielmedium ausgerichtet sein. Versucht man es, resultiert dies in langwierigen Pixelschiebereien, Hacks und schlechter Performance. Das Schlimmste: Die Mühe ist vergebens. Das Ziel, eine Website sieht überall gleich aus und genau so, wie vom Design vorgeben, kann bei der heutigen Geräte, Browser- und Auflösungs-Diversität niemals erreicht werden.

Workflow-Verbesserung: Es bleibt nur ein Ausweg: Kontrolle aufgeben.

“Give up control – not quality” Jeremy Keith, The Spirit of the Web

Der Kampf um die Kontrolle kann nur verloren werden. Statt Kontrolle zu simulieren, müssen wir Möglichkeiten designen. Das Design muss universell so stark sein, das wir ihm vertrauen, weil es sich flexibel anpasst auf unterschiedlichen Geräten und Bildschirmgrößen funktioniert.

The web is responsive - by default. Das ist der Ur-Geist des Web. Tim Berners Lee hat das World Wide Web 1994 flexibel konstruiert, um diese fantastische Plattformunabhängigkeit zu ermöglichen, die wir heute so selbstverständlich nutzen.

Die Flexibilität ist kein Mangel des Mediums, sondern das Killerfeature des Webs. Nur im Web ist responsive Design, ein Design also welches sich automatisch an seinen Kontext anpasst überhaupt möglich. Es müssen keine 3 oder 37 Formate einer Website gestaltet und hergestellt werden, wie dies beispielsweise bei Plakaten üblich ist.

“It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all. The journey begins by letting go of control, and becoming flexible.”
- John Allsopp, A dao of webdesign

Mit Responsive Design wird alles viel komplizierter und viel aufwendiger

Plötzlich reicht das nicht mehr, was immer gut war: Eine Website, ein Design, optimiert und fixiert für eine 1024er Auflösung. Mit responsive Design wird nun alles viel komplizierter: zahlreiche Endgeräte, Bildschirmgrößen von 320 bis 1680 Pixeln, unterschiedliche Auflösungen, Retina, flexibles Verhalten, touch, kein Verlass auf Hover mehr, neue Interaktionsmöglichkeiten, neue UX-Trends angetrieben vom Applikation-Design, unterschiedliche Nutzungskontexte, sich stark unterscheidene Prozessorleistungen, neue Technologien wie Canvas, SVG und neuen APIs … Die Folge aus veralteten Agenturprozessen: Je mehr Anforderungen, desto mehr Aufwand, desto teurer.

Problem: Veralterte Prozesse treffen auf neue Herausforderungen. Mit einer solchen Herangehensweise steigt der Aufwand und die Kosten für eine Website um ein Vielfaches. Ein solcher Workflow ist schlechtweg nicht mehr zeitgemäß.

Darum bezeichnet Andy Clark auch Responsive Design als Business-Problem:

“We have to refactor our design process! [...] We need a Post-PC-Workflow. - Andy Clark, 2012, Better better Client-Participation in responsive design projects

Workflow-Verbesserung: Responsive Design im Konzeptions- und Designprozess als Komplexität-Reduzierer verstehen, der Design, Layout, Interaktionskonzepte und Informationsarchitektur vereinfacht. Responsive Design ist nicht das Problem, sondern die Lösung für die Tatsache, dass Web nicht mehr auf dem Desktop-Rechner stattfindet. Das Beyond-Desktop / Post-PC Zeitalter hat längst begonnen. Es gibt kein Zurück. Der Workflow und die Erstellung von abgaberelevanten Dokumenten wie Feinkonzepte muss grundlegend überdacht werden. Neue Herausforderungen können nicht mit überalterten Instrumenten gemeistert werden.

Ein responsive Design ist flexibel und anpassungsfähig genauso müssen auch die Arbeitsprozesse sein. Wird das Prinzip Anpassungsfähigkeit auf alle Bereiche übertragen, dann wird durch responsive Design die Gestaltung von Websites zwar anspruchsvoller aber nicht komplizierter.

Mehr zum Thema Responsive Design und Responsive Workflow

Director’s Cut

Dieser Text ist eine erweiterte und überarbeitete Version des Textes “Responsive Design - der optimale Workflow”. Auf Papier erschienen in Screenguide Ausgabe 17 03/05/2013 Qualität.

5 Kommentare »

  1. Danke, sehr guter Artikel!

    Comment von Jonas Hamm — 13.04.2013, 12:50 Uhr

  2. Die Hauptprobleme mit Loesungsansaetzen prima aufgezeigt!
    Grade mit der traditionellen Arbeitsaufteilung koennen wir diese Problematik nicht loesen. Konzepter, Designer und Entwickler (und Kunden) muessen hier von Anfang an zusammen arbeiten (wollen)!

    Danke.

    Comment von Hannes — 17.04.2013, 03:36 Uhr

  3. Ein exzellenter Artikel - die wichtigsten Probleme anschaulich & knapp gefasst. Öffnet schneller die Augen, als ein ganzes Buch!

    Vielen Dank!

    Comment von Michael Kaiser — 28.05.2013, 15:45 Uhr

  4. Einfach dem Kunden sagen “wird schon mobil optimiert” und dann ist er am Ende sowieso glücklich. Bloß nicht zu viel reinreden lassen, sondern einfach mal den Profi ans Werk lassen. Wenn der Kunde sich auskennen würde, würde er die Seite ja schließlich selbst bauen und keine Agentur beauftragen ;)

    Comment von Internetagentur Browserwerk | Gerrit — 25.09.2014, 20:51 Uhr

  5. [...] der totalen Kontrolle über alle Devices verabschieden: „Give up control, not quality“ (Zitat: Jeremy Keith). Für Seiten und Elemente werden prozentuale statt fester Pixelwerte verwendet. Der Vorteil: die [...]

    Pingback von Die 3 Säulen des Responsive Webdesign — 08.04.2016, 12:04 Uhr

RSS-Feed für Kommentare zu diesem Beitrag. TrackBack URL

Kommentar schreiben




Suche

About

"Vorsprung durch Webstandards" ist ein Webzine zu Webstandards, Barrierefreiheit und Usability. In loser Folge erscheinen hier theoretische Texte, praktische Tipps und hilfreiche Links zum Thema.

Twitter

Follow Vorsprung on Twitter

Classics

Falling in love with CSS

I love CSS

alle Interviews

Updates

Feed Neue Texte als RSS-Feed

Autoren

Heike Edinger, heike.edinger at gmail.com

Timo Wirth, timo.wirth at gmail.com