• Welche Bereiche sind klickbar?
• Wie passt sich die Seite an die Bildschirmauflösung des Benutzers an?
• Welche Bereiche müssen so realisiert werden, dass sie mühelos pflegbar sind?
• Und, bei Web-Applikationen besonders wichtig, welche Bereiche müssen dynamisch geändert werden können?

Wer allerdings einmal richtig verdutzte Gesichter bei seinem Kunden sehen möchte, sollte nach etwas wie einem Styleguide fragen. Wenn überhaupt, existiert ein Styleguide für das grobe Corporate Design, für das Logo und vielleicht die Typografie nicht aber für die Feinheiten der verschiedenen elektronischen Medien. Und selbst das nur bei großen Konzernen. Dabei ist gerade der Styleguide (und wenn er noch so kompakt ist) unerlässlich für die Einhaltung von Konventionen – und Konsistenz ist einer der Eckpfeiler einer exzellenten User Experience.

Die Folge eines schlechten Briefings oder unzureichender Vorbereitung ist deutlicher Verlust an Qualität des Endprodukts. In meinem Bereich, dem Frontend beispielsweise, bedeutet ein schlechtes Briefing oder eine unzureichende Vorbereitung des Arbeitsmaterials, dass die Arbeitsergebnisse vom Kunden iterativ stark korrigiert werden müssen, oder dass zumindest durch eine rege, zeitaufwändige Kommunikation etwaige Missverständnisse im Vorhinein aus der Welt geschafft werden müssen. All das geht vom Zeitbudget ab, dass ursprünglich für die Produktion vorgesehen war. Natürlich stehe ich für die Qualität meiner Arbeit und setze mich dafür ein, sie auch unter widrigen Umständen konstant aufrecht zu erhalten. Weicht durch Abstimmungsprobleme oder ein ungenaues Briefing jedoch der realistische Aufwand zu stark von der ursprünglichen Einschätzung ab, bleiben nur zwei Möglichkeiten: Nachkalkulation oder Qualitätseinbußen. Und im ersten Fall muss der Kunde zusätzlich noch eine spätere Lieferung der Arbeitsergebnisse in Kauf nehmen.

Folgendes Szenario ist nicht nur wenig unrealistisch, sondern darüber hinaus auch keine Ausnahme:

1. Der Art Director gestaltet für einen Neukunden verschiedene Layoutvarianten.
2. Der Creative Director mag die Layouts, sie werden präsentiert.
3. Dem Marketingleiter auf Kundenseite gefallen die Layouts, er wählt eins aus und ist ab sofort verliebt.
4. Das Entwicklerteam, das nun mit der Umsetzung beschäftigt wird, erhält das Layout.

Bis hierher klingt das normal, oder? Der größte Fehler ist allerdings schon geschehen!

Nun beginnt der zweite Akt der Tragödie … nach und nach fallen den Entwicklern, die nun unter starkem Zeitdruck an der Umsetzung arbeiten, Probleme mit dem Layout auf, das sich so nicht exakt umsetzen lässt. Da der Launch kurz bevorsteht, beginnt die „Frickelei“.

An dieser Stelle ist das Kind bereits in den Brunnen gefallen! Die Entwickler sind frustriert, weil sie gezwungen werden, das Projekt weit unter ihrem eigentlichen Qualitätsstandard umzusetzen, was marginale Korrekturen des Layouts in einer früheren Phase des Projekts überflüssig gemacht hätten – nun will es aber der Kunde genau so, wie er es auf dem Layout gesehen hat. Die „Frickelei“ kostet das Projekt Code-Qualität, es wird schwer pflegbar, denn unter Zeitdruck sind die Projektkomponenten, die am stärksten leiden, die QA und die Dokumentation. Und, was langfristig natürlich wesentlich schlimmer ist: es kostet die Motivation und das Engagement der Entwickler.

Versucht man nun, dem Kunden eben jene marginalen Layout-Korrekturen stillschweigend unterzuschieben, die man vor der Präsentation ohne weiteres hätte vornehmen können, wird er es im schlimmsten Fall bemerken, bemängeln und auf korrekte Umsetzung bestehen. Hier beginnt nun auch die Unzufriedenheit des Kunden – und sie wird sich bis zum Launch weiter steigern.

Lösung

Das Entwicklungsteam muss früher in das Projekt integriert werden. Es bietet sich an, einen oder mehrere Entwickler bereits in der Endphase der grafischen Konzeption einzubinden. So kann vermieden werden, dass Features/Gimmicks vorgestellt werden, die in der Entwicklung zu einer Katastrophe werden. Setzt die Agentur das Projekt nicht selbst um, kann sie sich um ein Gutachten zur technischen Machbarkeit durch einen unabhängigen, freien Experten bemühen, oder den Partner um ein Urteil bitten, der im Anschluss an die Konzeption mit der Umsetzung betraut wird.

Vorteile

Gleichzeitig zur Lösung des initial geschilderten Problems bietet diese Vorgehensweise noch weitere Vorteile:

1. Grafiker sammeln im Gespräch mit Entwicklern Erfahrung und bilden eine Basis, auf der sie später die technische Machbarkeit ihrer Ideen selbst (eingeschränkt) beurteilen können.
2. Entwickler können Möglichkeiten aufzeigen, wie man die Umsetzung eines Layouts drastisch vereinfachen kann und dabei auf keine grafische Komponente verzichten muss – oft entstehen Probleme durch Überlagerung, Ausrichtung, Verschachtelung oder Positionierung.
3. Entwickler können Features vorschlagen, die sich die Grafiker aus der vagen Ahnung heraus, es könnte in der Umsetzung Probleme geben, nicht getraut hat, in das Layout zu integrieren.

Ergebnis

Das Ergebnis ist eine Win-Win-Situation:

• Der Kunde ist zufrieden, wurde nicht getäuscht und nimmt das Projekt exakt in dem Zustand ab, in dem er es erwartet hat.
• Die Agentur ist zufrieden, weil der Zeitplan eingehalten wurde, die Kalkulation aufgeht und die Marge hoch ist.

Bitte verstehen Sie diesen Vorschlag nicht als Plädoyer für simple Layouts oder faule Entwickler. Ich gehe natürlich davon aus, dass die hier erwähnten Entwickler technisch fähig und in der Lage sind, die Machbarkeit eines Projekts fachlich kompetent einzuschätzen. Die Unlust, ein bestimmtes Feature/Gimmick umzusetzen, darf niemals als Grund dienen, eine Empfehlung gegen die Integration eines solchen Features/Gimmicks auszusprechen.