Es war eine gesunde Mischung aus leichter Aufregung, angenehmer Vorfreude und intensivem Tatendrang, die mich plötzlich überkam, als ich erfuhr, dass wir den Zuschlag zur Mitarbeit an einem sehr umfangreichen und anspruchsvollen Responsive-Web-Design-Projekt erhalten hatten. Zwar hatten wir zuvor schon einige interessante Responsive-Web-Projekte erfolgreich abgewickelt, doch bei diesem handelte es sich um ein etwas größeres Kaliber.

Ziele und Methoden

Nicht nur der schier unüberschaubare Umfang und die Komplexität des Projekts waren es, die meine Neugierde und Begeisterung weckten, sondern mindestens in gleichem Maße die Tatsache, dass es sich hier um einen sehr gut besuchten Online-Shop handelte. Das grundlegende Re-Design, das der Kunde anstrebte, sollte lästige Usability-Issues beseitigen, den Online-Shop an die neuen Gegebenheiten des aktuellen Produktportfolios anpassen, dem Kunden einen Vorsprung gegenüber der Konkurrenz verschaffen und vor allem geräteunabhängig optimal nutzbar sein.

Unsere klare Empfehlung an den Kunden lautete daher: Design im Browser. Diese Methodik war unumstritten die am besten geeignete Herangehensweise, um möglichst effizient zu arbeiten, früh auf unterschiedlichen Geräten zu testen und am Ende der Design-Phase mit wiederverwendbaren Deliverables dazustehen. Im Gegensatz zu bisher üblichen Wireframes eröffnet die prototypische Implementierung als Design-Artefakt ganz neue Präsentations- und Feedback-Möglichkeiten. Nach kurzer Diskussion war der Kunde von der Argumentation für Design im Browser auf der ganzen Linie überzeugt.

Klare Vorteile von Design im Browser

• Sofortiges Testen und direktes Feedback auf allen Bildschirmgrößen und Geräten
• Wiederverwendbare Templates, die den Entwicklungsaufwand reduzieren
• Deutlich reduzierter Aufwand in der Implementation von Design-Änderungen

Rahmenbedingungen

Wir einigten uns auf regelmäßige Workshops mit allen Stakeholdern, in denen detaillierte Anforderungen und grobe Konzepte erarbeitet werden sollten. Aufbauend auf diesen Workshops sollte der Prototyp gebaut und regelmäßig präsentiert werden. Die Rahmenbedingungen waren geklärt, der Tatendrang schon groß. Das Projekt konnte starten.

Projektbeginn

In den Workshops wurde viel aufgearbeitet, analysiert und konzipiert. Jegliche Ideen wurden auf Whiteboards, Papierblöcken und ähnlichen Utensilien aufgekritzelt und festgehalten. Mit diesen umfassenden Inputs verließen wir die Workshops und diskutierten, designten, verfeinerten und konkretisierten die Konzepte solange weiter, bis sie ein professionelles Level erreicht hatten. Gleichzeitig hatte die Setup-Phase für den Design-Prototypen begonnen und es wurde fleißig programmiert. Es schien alles hervorragend voranzugehen, doch schon sehr bald kam ein grundlegendes Problem zum Vorschein.

Schwierige Konditionen, hohe Erwartungen

Als Designer wurden wir in diesem Projekt etwas spät ins Team geholt, was zur Folge hatte, dass wir praktisch ohne jegliche Vorbereitung loslegen und sofort Abgabedokumente produzieren mussten. Normalerweise nehmen wir uns zwischen ein und zwei Wochen vor Projektstart Zeit, um unser Framework aufzusetzen und alle notwendigen Maßnahmen zu treffen, damit einer effizienten Arbeit im Team mit dem Kunden nichts im Weg steht. Wir hatten den Kunden von Anfang an darauf hin gewiesen, dass uns die entsprechende Vorbereitung fehlt und wir erst nach frühestens zwei bis drei Wochen imstande sein würden, gemeinsam erarbeitete Konzepte in Form eines Prototypen dem Team zu präsentieren. Zu Beginn waren damit auch alle noch einverstanden, doch es kam unerwartet zu einem Stimmungsumschwung. Während wir noch dabei waren, die fehlende Zeit für die Vorbereitung des Prototypen aufzuholen, schritten Konzeption und Analyse in den Workshops stetig voran und die einzigen Dokumente, die daraus entstanden, waren Scribbles auf Whiteboards und Papierblöcken. Der Kunde war jedoch daran gewöhnt, von den Designern nach den Workshops rein gezeichnete und konzeptionell vervollständigte Wireframes zu erhalten. Plötzlich wurde der Kunde ungedulgig und wollte nicht mehr warten bis der Prototyp präsentierbar war. Es kam die Forderung auf, in der Zwischenzeit Wireframes zu liefern, um nicht wochenlang ohne offizielle Abgabedokumente dastehen zu müssen.

Planänderung

Wer das Buch Design Is A Job aufmerksam gelesen hat, weiß ganz klar, dass es eine äußerst schlechte Idee ist, den eigenen Workflow kompromisslos den Vorstellungen des Kunden anzupassen und es mag rückblickend auch nicht die beste Entscheidung gewesen sein. Nichtsdestotrotz war der Druck sehr hoch und Wireframes scheinbar die einzig mögliche Zwischenlösung. Wir gaben nach.

Aus dieser Planänderung ergaben sich schmerzliche Konsequenzen. Wir waren in eine Situation geraten, in der wir konstant sehr viele Wireframes produzieren mussten, um mit den Workshops Schritt zu halten. Gleichzeitig blieb uns weniger Zeit, um am Prototypen selbst weiter zu programmieren. Die von uns gelieferten Wireframes wurden bei nachfolgenden Workshops als Diskussionsgrundlage verwendet und schon war es notwendig, immer wieder Konzeptänderungen und kleinere Adaptierungen einzubauen. Wir verbrachten also Stunden um Stunden damit, Wireframes zu zeichnen zu verändern und anzupassen und schon bald kam die Befürchtung auf, wir würden den Prototypen nie so weit bringen, dass wir die Wireframes wieder ablösen konnten.

Die Wende

Als es zu einer unvorhergesehenen Pause der regelmäßigen Workshops kam, konnten wir die Lücke endlich schließen und den Prototypen so weit entwickeln, dass er alle bisher entworfenen Konzepte abdeckte. Wir hatten es trotz holpriger Umstände letztlich geschafft, die hohen Erwartungen des Kunden zu erfüllen. Es ist nun nicht mehr notwendig, Wireframes zu zeichnen, die statischen Konzeptionsartefakte wurden durch einen umfassenden und interaktiven Prototypen abgelöst, der das Testen auf vielen verschiedenen Geräten ermöglicht.

Was können wir daraus lernen?

• Interaktive Prototypen sind ein gutes Design-Tool.
• Die Entwicklung von Prototypen benötigt jedoch anfangs mehr Zeit.
• Änderungen können an einem Prototypen einfacher als an Wireframes durchgeführt werden.
• Es ist äußerst wichtig, dem Kunden ganz genau die Vor- und Nachteile, sowie jegliche Implikationen von Design im Browser zu erklären.