Designer nerven, Programmierer auch und Konzepter erst recht

Die Zusammenarbeit im Team ist nicht immer reibungslos. Als Konzepter sitzt man dabei manchmal zwischen den Stühlen – um so mehr, wenn man gleichzeitig auch die Projektleitung übernommen hat.

Nicht in jedem Projekt lassen sich die Rollen klar trennen – es gibt Konzepter, die auch das Design machen und Designer, die programmieren. Ich gehe im Folgenden von diesen drei Rollen aus: Konzepter (erstellt Konzepte, Informations-Architektur, ist für Usability verantwortlich); Designer (macht den Entwurf für die Seiten, gibt das Aussehen vor); Programmierer (erstellt HTML, CSS, JavaScript, Server-Scripts und setzt ggf. das CMS auf).

Die folgende Liste dient nicht dazu, es den beteiligten Berufsständen einmal so richtig reinzudrücken. Im Gegenteil, sie soll die Zusammenarbeit erleichtern und den Frieden im Team sichern. Ich freue mich natürlich auch über Kommentare auf der Website! Sind Sie anderer Meinung? Haben Sie einen weiteren Tipp? Immer gerne her damit.

Die Beobachtungen kommen aus meiner eigenen Erfahrung, aus Gesprächen mit Kollegen und aus den zwei lesenswerten Artikeln von Jason Cranford Teague, die am Ende des Texts verlinkt sind.

Wann Konzepter nerven

Die Vorgaben sind ungenau. Der Konzepter hat genau im Kopf, was er haben möchte – gibt es aber nicht weiter. Das passiert besonders häufig, wenn der Konzepter gleichzeitig Projektleiter ist. Zum einen fehlt dann die Person, die auf die Weitergabe der Vorgaben achtet. Zum anderen ist der Konzepter eigentlich besonders in den frühen Phasen der Umsetzung gefragt. Zu dieser Zeit fällt aber auch besonders viel Arbeit in der Projektleitung an.

Echte Inhalte kommen zu spät. Es ist üblich, mit Blindtext und Beispielbildern zu arbeiten. Das hat auch den Vorteil, das man nicht über die Inhalte diskutieren muss, wenn es zunächst um Struktur und Gestaltung geht. Dennoch sollten echte Texte, Bilder und andere Inhalte so früh wie möglich erstellt und weitergegeben werden. Denn oft stellt sich dann heraus, dass die Gestaltung geändert werden muss, weil die Texte doch länger als erwartet sind. Oder dass die Programmierung einen weiteren Content-Typ einbinden muss, von dem bisher noch nie die Rede war.

Eine präzise Angabe der Zielgruppe fehlt. Besonders ärgerlich ist es für Gestalter, wenn der Konzepter seine Arbeit nicht macht. Eine der Hauptaufgaben des Konzepters ist, die Zielgruppe der Website festzulegen. Das ist nicht immer einfach – ein Webshop will natürlich am liebsten an jeden verkaufen. Und der Auftraggeber will sich oft nicht festlegen. Dennoch ist es immer möglich, die Zielgruppen zu priorisieren.

Vorgaben des Auftraggebers werden nicht weitergegeben. Ein klarer Fall von vermeidbarer Doppelarbeit. Unterlagen zur CI, Hausschriften und -Farben fehlen. Der Konzepter sollte so früh wie möglich diese Unterlagen bzw. Informationen vom Auftraggeber einsammeln. Zumal sie ihm auch bei seiner eigenen Arbeit helfen.

Rosinenpicken – Entwürfe werden kombiniert. Eine sichere Methode, Designer zu verärgern, ist das „Rosinenpicken“. So nenne ich es, wenn aus verschiedenen grafischen Entwürfen Dinge kombiniert werden. Die Schriftart aus Entwurf A, die Grundfarben aus Entwurf B und die Bilder aus Entwurf C. Das sieht in den meisten Fällen scheußlich aus – jedes Design ist sorgfältig konstruiert, und wie bei einem Haus kann eine scheinbar kleine Änderung die ganze Konstruktion ins Wanken bringen.

Tipp für Konzepter und Projektleiter: Solche Rosinienpickerei möglichst gleich beim Kunden eindämmen. Erklären Sie ihm, dass der Designer gern neue Vorschläge macht, und nehmen sie auf, was an den einzelnen Entwürfen gefällt und was nicht.

Tipp für Designer: Wenn Sie Rosinenpickerei begegnen, ruhig alle Informationen aufnehmen. Fragen Sie sich dann, was man am jeweiligen Design ändern kann, um den Kunden zufriedenzustellen. Ändern Sie dann, was Sie für gut halten und fühlen Sie sich nicht verpflichtet, alles umzusetzen. Sie sind hier der Boss, Sie können zeigen, wie es gut aussieht. Das funktioniert viel besser, als sich zu streiten.

Unrealistische Versprechungen. Änderungswünsche werden sofort angenommen, ohne dem Kunden zu er­klären, warum der Entwurf bzw. die Programmierung so ist, wie er/sie ist. Die Termine für Änderungen werden ohne Rücksprache und zu knapp ge­setzt. Oder, noch schlimmer: Der Konzepter hat keine Ahnung, wie viel Aufwand die Umsetzung ist und nimmt auch keine Rücksicht darauf.

Persönliche Vorlieben werden durchge­drückt. Der Satz „Das ist nicht benutzerfreundlich.“ ist ein Totschlagargument. Damit kann man als Konzepter jede Diskussion beenden. Das sollte man nicht dazu ausnutzen, seine persönlichen Vorstellungen durchzusetzen. Auch mit „das will der Kunde nicht“ sollte man vorsichtig sein. Die anderen Teammitglieder merken schnell, wenn man keine echten Argumente hat. Diese also immer zumindest im Ansatz vorbringen – ohne sich auf lange Diskussionen einzulassen. Denn letztlich entscheiden Sie als Konzepter tatsächlich. Aber diskutieren Sie auch einmal über alternative Ansätze.

Wann Designer nerven

Vorgaben werden nicht genau gelesen. Das ist immer ärgerlich. Aber es kann auch an den Vorgaben liegen. Wer einfach ein zig Seiten langes Grobkonzept übergibt, muss sich nicht wundern, wenn es nicht vom ganzen Team ganz gelesen wird. Sie als Konzepter kennen das Dokument am besten. Suchen Sie die Teile heraus, die für Designer (und Programmierer) wichtig sind, und übergeben Sie nur diese.

Auch wichtig: Sprechen Sie miteinander. War der Designer nicht mit beim Kunden, berichten Sie ihm schon früh von Ihren Besprechungen. Erzählen Sie ihm alles, was für ihn wichtig ist und geben Sie ihm das Gefühl, am Projekt auch schon in der frühen Phase beteiligt zu sein.

Änderungen werden nur widerwillig durchgeführt. Natürlich ist es schön, wenn jeder gleich das macht, was Sie sagen. Aber manchmal ist es nicht unbedingt gut. Hören Sie die Argumente an, die gegen Änderungen sprechen, die sie vorgeben. Schickes Design geht vor. Das ist sicher einer der Hauptkonfliktpunkte. Usability, Inhalte, Ladegeschwindigkeit, Sicherheit – alles muss bei manchen Designern hinter der Gestaltung zurückstehen. Hat man mit solchen Kollegen zu tun, wird es schwierig.

Das Design ist nicht umsetzbar. Ihre Aufgabe als Konzepter oder als Projektleiter ist, zwischen Designer und Programmierer zu vermitteln. Bevor Sie Gestaltungsvorschläge beim Kunden abgeben, zeigen Sie diese unbedingt immer dem Programmierer, wenn das der Designer nicht von sich aus getan hat.

Desinteresse an der Umsetzung. Leider ist es bei einigen Menschen so, die sich für künstlerische Dinge interessieren, dass sie sich gar nicht für technische Dinge interessieren und dieses Desinteresse kultivieren. Für einen Webdesigner ist das fatal. Denn er macht damit allen Beteiligten mehr Arbeit. Versuchen Sie zu vermitteln, dass die Umsetzung von Anfang an beim Entwurf mitgedacht werden muss.

Fehlende Vorgaben. Es wird zum Beispiel nur ein Photoshop-Dokument übergeben, ohne Dokumentation, ohne Namen für die verschiedenen Ebenen. Keine Farbwerte, keine Schriftarten oder Pixelangaben werden vom Designer kommuniziert. Das ist insbesondere für stark strukturierte Informations-Architekten und Programmierer nicht nachvollziehbar. Sie haben einfach eine ganz andere Arbeitsweise – was sie einfach akzeptieren müssen. Hier hilft nur, genug Zeitpuffer einzuplanen, um die fehlenden Angaben zusammenzusammeln.

Wann Programmierer nerven

Vorgaben werden ignoriert. Das nervt natürlich immer. Vielleicht liegt es aber auch an den Vorgaben? Waren sie klar? Waren sie auch umsetzbar? Wurden sie überhaupt verständlich weitergegeben?

Änderungen werden nur widerwillig durchgeführt. Normalerweise wird der Widerwille immer größer, je öfter Änderungen kommen. Auch wenn jede Änderung für sich vielleicht wenig Arbeit ist – es ist einfach mühsam, immer wieder wegen etwas Kleinkram jede Seite nochmal anzufassen. Also lieber so viele Änderungen wie möglich sammeln und auf einmal weitergeben.

Vorgaben werden anders umgesetzt. Entweder passen die Farben nicht, die Abstände sind falsch oder das Design sieht überall anders aus. Fast immer liegen solche Dinge an fehlenden oder unklaren Vorgaben. Für viele Programmierer ist klar: Gibt es keine numerische Angabe, kommt es nicht darauf an. Oder sie setzen es eben nach eigenem Gefühl um – und das stimmt meist nicht mit dem des Designers überein.

Der Sicherheits-Trumpf. Das ist eines von den Totschlag-Argumenten eines Programmierers: Etwas geht nicht, weil dadurch die Website angreifbar wird/Kundendaten gefährdet sind a. Ä. Etwas platter noch: „Das geht technisch nicht.“ Dagegen ist man meist machtlos. Versuchen Sie zu vermitteln, und bekommen Sie heraus, was denn gehen würde. Oft zeigt sich, dass die eigentlich gewünschte Funktion sehr wohl umzusetzen ist – nur eben nicht so, wie ursprünglich vorgeschlagen.

Tipp für Programmierer: Bieten Sie immer gleich Alternativen an. Sonst sieht es schnell so aus, als hätten Sie nur keine Lust, die Sache umzusetzen.

Wann jeder nervt

Reinreden. Die einfachste Methode, jemanden zu verärgern ist, ihm in seine Aufgaben hineinzureden. Programmierer, die dem Konzepter Vorträge über Usability halten. Designer, die mit dem Konzepter über Texte diskutieren. Konzepter, die dem Programmierer sagen, dass etwas mit einem CSS class selector problemlos umzusetzen sei.

Verzichten Sie einfach darauf. Und überlegen Sie sich, wenn einmal ein Teamkollege komisch reagiert, ob Sie ihm vielleicht in seinen Bereich hineingeredet haben. Wenn andersherum Ihnen jemand hineinredet, bleiben Sie ruhig. Hören Sie sich die Argumente an, aber lassen Sie sich nicht auf Diskussionen ein.

Die goldene Regel

Die Konsequenz aus den Meckerlisten oben ist, dass es wie so oft bei der Teamarbeit vor allem darauf ankommt, den anderen zuzuhören. Alle müssen frühzei­tig eingebunden werden und immer über den Fortgang des Projekts auf dem Laufenden sein.

Achten Sie auf die Bedürfnisse Ihrer Kollegen, und fragen Sie sie selbst, was sie wann brauchen. Sie meinen vielleicht, das selbst zu wissen, aber vielleicht täuschen Sie sich. Und außerdem fühlen sich die anderen Teammitglieder ein­gebunden, wenn sie regelmäßig und frühzeitig nach ihrer Meinung gefragt werden. Reden hilft.

Weiterführende Links

5 Pet Peeves Designers Have With Developers (and How to Avoid Them)
5 Pet Peeves Developers Have With Designers (and How to Avoid Them)