![\"open-office-developer\"](\"http:\/\/usersnap.com\/de\/blog\/wp-content\/uploads\/2016\/08\/open-office-developer-1.jpg\")
<\/p>\nEntwickler und Designer haben sehr verschiedene Job-Profile und Perspektiven. Auch wenn sie sich mit dem gleichen Thema besch\u00e4ftigen, betrachtet sie dieses doch grunds\u00e4tzlich aus anderen Blickwinkeln.<\/p>\n
Ein Beispiel: W\u00e4hrend ein Webdesigner sich das gesamte externe Design ansieht und \u00fcberlegt, wie Leute damit interagieren, ist der Job eines Entwicklers ganz anders. Als Webentwicklerin \u00fcberlegt man, wie eine Idee sich umsetzen l\u00e4sst, und wie man Code daf\u00fcr bestm\u00f6glichst einsetzen kann.<\/p>\n
Auch wenn Job-Beschreibungen h\u00e4ufig sehr verschieden sind, arbeiten Entwickler und Designer doch h\u00e4ufig als Team zusammen. Im heutigen Artikel geht es daher darum, wie sich die Kommunikation zwischen Entwicklern und Designern verbessern l\u00e4sst. Los geht\u2019s!<\/p>\n
<\/p>\n
Was w\u00fcrden Sie unternehmen, um die Kommunikation zwischen Entwicklern und Designern zu verbessern? In diesem Artikel geben wir Ihnen ein paar Tipps und Tricks.<\/p>\n
Besonders in gro\u00dfen Unternehmen, besetzen verschiedene Abteilungen h\u00e4ufig unterschiedliche R\u00e4ume. Cubicles, Abtrennungen oder verschiedene Stockwerke k\u00f6nnen schnell zu Kommunikationsproblemen f\u00fchren.<\/p>\n
Ein erster Schritt w\u00e4re daher, r\u00e4umliche Trennungen aufzuheben. Entwickler und Designer-Teams k\u00f6nnen dann auch r\u00e4umlich – zum Beispiel im gleichen Stockwerk – n\u00e4her zusammenr\u00fccken.<\/p>\n
<\/p>\n
Wenn ihr Team bereits r\u00e4umlich zusammen ist, gibt es weitere Aspekte, an denen Sie arbeiten k\u00f6nnen. Stellen Sie sich Ihre Entwickler und Designer als ein gro\u00dfes Team vor. Beide sollten regelm\u00e4\u00dfig miteinander sprechen und sich austauschen. Das hilft, ein Problem noch einmal aus anderen Blickwinkeln zu sehen.<\/p>\n
Entwickler erhalten oft sehr vage Beschreibungen von Designern wie etwa: \u201cDieser Button soll so aussehen wie bei Twitter, aber so funktionieren wie bei LinkedIn\u201d.<\/p>\n
Beschreibungen wie diese machen es schwer, Ideen zu verstehen und f\u00fchren nicht selten zu Misverst\u00e4ndnissen. Das liegt daran, dass jeder seine eigene Vorstellung hat, wie ein Produkt am Ende aussehen soll.<\/p>\n
Es kann daher helfen einen eindeutigen Design-Plan zu erstellen, den ein Designer verantwortet. Dieser soll so spezifisch wie m\u00f6glich sein, sodass Au\u00dfenstehende direkt verstehen, was gemeint ist.<\/p>\n
Ich war in Projekt Meetings, in denen es um Design-Feedback ging, bei denen kein einziger Entwickler anwesend war.<\/p>\n
Wow. Das war ein gro\u00dfer Fehler!<\/p>\n
Entwickler sind eine hervorragende Quelle f\u00fcr Design-Feedback. Sie kennen sich sehr genau mit dem Produkt oder der Website aus und wissen, was aus technischer Sicht m\u00f6glich ist und was nicht. Daher lohnt es sich in jedem Fall beim n\u00e4chsten UX und Design Meeting auch die Entwickler einzuladen. Auch dann, wenn Sie nur neue Ideen \u00fcberlegen.<\/p>\n
Viele Tech-Unternehmen sind auf Entwicklung fokussiert, weshalb es meistens wesentlich mehr Entwickler als Designer gibt. Ein Verh\u00e4ltnis von 1:8 (Designer – Entwickler) ist dabei keine Seltenheit. Wenn das Unternehmen etwas mehr UX orientiert ist, dann sind Verh\u00e4ltnisse wie 1:4 oder 1:2 m\u00f6glich.<\/p>\n
Eine richtige Antwort, wie das richtige Verh\u00e4ltnis auszusehen hat, gibt es dabei nicht. Ich empfehle aber UX genug Aufmerksamkeit zu widmen. Andernfalls erh\u00e4lt man ein System, das so aussieht:<\/p>\n
![\"designer-developer-problems\"](\"http:\/\/usersnap.com\/de\/blog\/wp-content\/uploads\/2016\/08\/designer-developer-problems-1.png\")
<\/p>\n
W\u00e4hrend kleinere Projekte Interaktion zwischen nur einem Entwickler und Designer verlangen, wird es komplizierter je gr\u00f6\u00dfer Projekt und Team sind. Gerade bei gro\u00dfen Teams gilt es sicherzustellen, dass jeder up-to-date ist und Informationen weitergegeben werden.<\/p>\n
Mit einem festgelegten Informationsweg oder Ort, in dem Updates geposted werden, k\u00f6nnen Designer und Entwickler gleicherma\u00dfen an einem Projekt teilnehmen und effektiver arbeiten.<\/p>\n
![\"slack-for-designers-developers\"](\"http:\/\/usersnap.com\/de\/blog\/wp-content\/uploads\/2016\/08\/slack-for-designers-developers-1.png\")
<\/p>\n
Es gibt Designer, die wenig von Code verstehen, genauso wie es Entwickler gibt, die wenig Ahnung von Design haben. Eine gute M\u00f6glichkeit, dass diese Teams gut zusammenarbeiten ist die M\u00f6glichkeit des “Pairings”. Dabei geht es darum, dass jeweils eine Entwicklerin und ein Designerin zusammenarbeiten.<\/p>\n
Das Konzept des pair programming<\/a> kommt aus der agilen Software-Entwicklungs-Welt. In diesem Fall arbeiten zwei Entwickler zusammen an der gleichen Workstation.<\/p>\n Eine Alternative dazu w\u00e4re nun, nicht zwei Entwickler, sondern einen Entwickler und einen Designer zusammen arbeiten zu lassen. Damit k\u00f6nnen UX Probleme direkt diskutiert werden.<\/p>\n Designer brauchen immer Entwickler, um ihre Ideen zu realisieren, und Entwickler brauchen andersrum auch immer Designer. Erst dann kann man tolle Anwendungen oder Websites gestalten.<\/p>\n#8 Eins + Eins = Drei<\/h2>\n
![](\"http:\/\/usersnap.com\/de\/blog\/wp-content\/uploads\/2016\/02\/Bildschirmfoto-2016-02-24-um-14.58.05-e1458129781372.png\")
<\/p>\n