Mein diesjähriger IPC-Besuch stand ganz im Zeichen von Responsive (Web-)Design. Nicht nur, dass mich das Thema sehr interessiert und ich mich schon viel damit beschäftigt habe, es wurden dem Thema diesmal auch gleich zwei Special Days gewidmet. Die beginnen die Notwendigkeit für Responsive Design allmählich zu erkennen, und Experten sind sich einig: 2013 ist das „Jahr des Responsive Designs“.
Auch wenn in den verschiedenen Konferenzvorträgen und auch in meiner Session auf ganz unterschiedliche Schwerpunkte des Responsive Designs eingegangen wurde, und teils die Meinungen auseinandergehen, so ist bei einer für mich entscheidenden Frage doch eindeutig ein Konsenz herauszuhören:
Designer gehören mit an den Tisch
Designer gehören mit an den Tisch, oder Frontendler. Eigentlich beide – also zusammen. An einen Tisch. Ein Design kann und soll nicht mehr einfach als eigenes Werk im Photoshop angelegt, ausgearbeitet, abgeschlossen und an die Entwicklung übergeben werden. Designer, UXler und Frontendler müssen zusammen ein Konzept entwickeln, Prototypen erarbeiten, die Prototypen testen und dann Schritt für Schritt verbessern. Agil? Bietet sich hier sicher an….
Prototypen!
Auch in Hinblick auf den Kunden macht das Sinn. Dem Kunden ein Photoshop-File zu zeigen, absegnen zu lassen und dann in die Entwicklung zu geben, führt zwangsläufig dazu, dass der Kunde irgendwann sein XY Phone/Tablet rausholt und feststellt, dass das (responsive?) Design gar nicht mehr so unbedingt der Photoshop-Vorlage entspricht – oder obwohl es dies tut auf dem Gerät eher suboptimal aussieht/bedienbar ist.
Man kann seinen Kunden ruhig einen Prototypen an die Hand geben, auch wenn sich viele Agenturen dagegen sträuben. Der Kunde kann damit herumspielen, er kann es auf seinen Lieblingsgeräten testen und er kann sagen, was ihn stört, was ihm fehlt, usw. Klar, auch Scribbles und Wireframes sind gut, aber nur ein Teil und keinesfalls ausreichend, um dem Kunden vorab einen aussagekräftigen Eindruck von der Seite zu vermitteln.
Wir müssen also die internen Prozesse verändern. Doch was bedeutet Responsive Design noch?
Alles aus einer Hand…
Die teilweise übliche Herangehensweise, von der einen Agentur das (responsive) Design einzukaufen, und eine andere mit der Umsetzung beauftragen, funktioniert nicht mehr. Zwischen den beiden Agenturen findet (leider) meist keine oder eine nur sehr eingeschränkte Kommunikation statt, und oft ist das Design auch schon lange abgeschlossen und „fertig“, bevor die Umsetzung überhaupt beauftragt wurde. Das führt zu Problemen:
Vermutlich ist das (responsive?) Design nicht vollständig für alle Zustände und mögliche Optionen im „Responsive Web“ gerüstet. Wodurch natürlich Spielräume offen bleiben. Teil-Designleistungen, die dann von der umsetzenden Agentur erbracht werden müssen und vielleicht nicht das treffen, was der Kunde eigentlich wollte.
Der andere Fall ist, dass die Agentur eine unglaubliche Menge an Vorgaben machen muss, um tatsächlich für alle Eventualitäten gerüstet zu sein, oder gleich direkt selbst HTML-Prototypen mitliefern muss. Was wieder doppelte Arbeit ist, da die Prototypen ja dann noch in die jeweiligen CMS/Backend/Sonstwas-systeme eingepflegt und mit Funktionalität versehen werden müssen.
Zwangsläufig führt das dazu, dass tatsächlich immer mehr ehemalig reine Design-Agenturen auch Programmierung/Umsetzung mit anbieten und umgekehrt die reinen Programmier-/Umsetzungsdienstleister nun auch Design/Konzept mit anbieten (müssen), um dem Markt gerecht zu werden.
Teilweise wird auch der Ansatz gefahren, dass die Frontendler „einfach noch Photoshop mitlernen“ sollen und Design & Umsetzung machen. Oder umgekehrt die Designer neben ihrem Photoshop auch noch „ein wenig Web-Kram machen“. Diese Entwicklung missfällt mir allerdings zutiefst!
Sowohl Design als auch Frontend benötigen (zumindest wenn man es richtig machen will) viel Erfahrung und Know-how. Sich auf beide Bereiche gleichzeitig zu konzentrieren, erzeugt viel Overhead. Klar, jeder Designer sollte auch ein wenig was über die Umsetzung wissen und umgekehrt jeder Frontendler das Design grob überblicken. Dennoch wird ein Designer immer schneller, effizienter und qualitativ hochwertiger sein in seiner Arbeit, als ein Frontendler, der am Photoshop rumspielt. Das gleiche entsprechend umgekehrt bei der Umsetzung.
Teamwork!
Aber zurück zum Thema. Wie erreicht man dieses Teamwork zwischen Entwicklung und Design/Konzept? Setzt man die Frontendler zu den Designern mit ins Büro? Schlechte Idee! Die Frontendler müssen ja nicht nur mit den Designern, sondern auch mit den Backendlern zusammenarbeiten. Diese komplett aus dem „Programmierteam“ zu nehmen und in das „Designteam“ zu stecken halte ich für einen großen Fehler. Alternativ könnte man die Designer mit in das Programmierteam zu setzen. Was sich in der Realität leider ebenso schwierig erweist.
Das Design befindet sich meist im ersten Drittel des Projektes, während die Umsetzung sich über die gesamte Projektphase bezieht. Der Designer wird dann wieder abgezogen und auf das nächste Projekt gesetzt. Das geschieht zumeist aus Kostengründen. Das Design ist ja „fertig“, also warum weitere Ressourcen verschwenden? Übersehen wird hier meist, dass im Laufe des Projektes neue Features eingebaut werden, die ebenfalls designed werden müssen und dass sich ein Feinschliff der Benutzeroberfläche massiv positiv auf die User Experience (UX) auswirken kann. Gerade in agilen Projekten lohnt es sich meiner Meinung nach, auch über die Anfangsphase hinaus Designer/UXler mit im Boot zu haben.
Ein Kompromiss?
Eine Art Kompromiss wäre es vielleicht, spezielle „Task-Forces“ für die Projekte ins Leben zu rufen. Designer, UXler und Frontendler designen, konzeptionieren und planen, entwickeln Prototypen, testen diese. Zusammen. Als Mini-Projekt. Stehen das Design und die Prototypen fest, können die Designer sich primär anderen Aufgaben zuwenden und die Frontendler können zurück in ihr „Programmierteam“. Dort können sie dann mit der Adaptierung und Ausimplementierung der Prototypen beginnen. Optimal ist das aber nicht, da mit Sicherheit noch Rückfragen an die Designer kommen werden und die Prototypen überarbeitet werden müssen – gerade im agilen Umfeld mit sich ändernden Features/Anforderungen, etc.
Fazit
Ich für meinen Teil bin sehr gespannt, welche Formen die Auswirkungen des Responsive Design noch annehmen werden, und wie lange es dauern wird, bis Design und Frontend tatsächlich wieder zusammen gefunden haben.
Schreibe einen Kommentar