Entwickler „besitzen“ den Code, sollten Designer also nicht die Erfahrung „besitzen“?

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ Wir waren alle dort. Sie haben Monate damit verbracht, Geschäftsanforderungen zu sammeln, komplexe Benutzerreisen auszuarbeiten, präzise Schnittstellenelemente zu erstellen und sie an einer repräsentativen Stichprobe von Benutzern zu testen, nur um ein Endprodukt zu sehen, das der gewünschten Erfahrung nur wenig ähnelt.

Das haben wir alle schon durchgemacht. Sie haben Monate damit verbracht, Geschäftsanforderungen zu sammeln, komplexe Benutzerreisen auszuarbeiten, präzise Schnittstellenelemente zu erstellen und sie an einer repräsentativen Stichprobe von Benutzern zu testen, nur um ein Endprodukt zu sehen, das der gewünschten Erfahrung nur wenig ähnelt .

Vielleicht hätten Sie energischer vorgehen und auf einem agilen Ansatz bestehen sollen, obwohl Sie der Meinung waren, dass die Organisation noch nicht bereit war? Vielleicht hätten Sie mit Ihren Musterportfolios besser arbeiten sollen und sicherstellen sollen, dass die Entwickler Ihre modulare Codebibliothek verwenden, anstatt fünf verschiedene Variationen eines Karussells zu erstellen. Oder vielleicht hätten Sie sogar jeden Tag neben dem Entwicklungsteam sitzen und sicherstellen sollen, dass das, was Sie entworfen haben, tatsächlich umgesetzt wird.

Weiterführende Literatur zu SmashingMag:

  • Warum Sie Ihren Entwickler in den Designprozess einbeziehen sollten
  • Zusammenarbeit im Team und Schließen von Effizienzlücken im Responsive Design
  • Designer und Entwickler, die nett spielen
  • So kommunizieren Sie effektiv mit Entwicklern

Stattdessen bleibt Ihnen ein Durcheinander von UI-Elementen, bei denen alle Feinheiten entfernt wurden. Konnten sie nicht sehen, dass Sie tagelang daran gearbeitet haben, die Übergänge genau richtig zu machen, nur damit sie eine Standard-Animationsbibliothek einfügen? Und wo in aller Welt kam dieser zusätzliche Check-out-Schritt her. Ich wette, das Marketing hat das in letzter Minute eingeworfen. Sie wussten, dass die Integration schwierig werden würde und Kompromisse eingegangen werden müssten, aber wir sollten hier den Benutzern das Leben erleichtern , nicht dem Technikteam.

Mehr nach dem Sprung! Lesen Sie unten weiter ↓
Wenn viele Menschen an einem Projekt beteiligt sind, ist es sehr wichtig sicherzustellen, dass sie ein gemeinsames Verständnis des Problems und seiner Lösung haben.
Wenn viele Menschen an einem Projekt beteiligt sind, ist es sehr wichtig sicherzustellen, dass sie ein gemeinsames Verständnis des Problems und seiner Lösung haben. (Bildnachweis: The Next Web)

Natürlich gibt es viele gute Gründe, warum die Seite so ist. Verschiedene Teams mit unterschiedlichen Fähigkeiten, die an verschiedenen Teilen des Projekts arbeiten, eine Reihe von Änderungen in letzter Minute, die den Entwicklungszyklus verkürzen, und eine ganze Reihe technischer Herausforderungen. Warum konnte das Entwicklungsteam nicht kommen und Sie um Rat zu ihren UI-Änderungen bitten? Sie spielen nicht mit ihrem Code herum, also warum müssen sie Ihre Designs ändern? Vor allem, wenn die geschäftlichen Auswirkungen enorm sein könnten! Sie sind nur um die Ecke und hätten gerne geholfen, wenn sie nur gefragt hätten.

Obwohl die obige Geschichte frei erfunden sein mag, ist es eine Meinung, die ich aus allen Ecken der Designwelt höre, ob intern oder auf Agenturseite. Eine sorgfältig ausgearbeitete Erfahrung, die von einem hartnäckigen Entwicklungsteam ruiniert wurde.

Diese Erfahrung erinnert mich an eine Nachricht, die ich vor einigen Jahren auf einem lokalen US-Nachrichtensender gesehen habe. Auf einem Jahrmarkt fand ein Ausdauerwettbewerb statt, bei dem die letzte Person, die ihre Hand auf einem Pickup-Truck hatte, den Preis gewann. Ich denke oft, dass Design wie ein riesiges „Touch the Truck“-Spiel ist , bei dem das Entwicklungsteam am Ende des Wettbewerbs immer mit den Schlüsseln davonkommt. Wie das letzte Wort in einem Streit hat die letzte Person, die mit der Website in Kontakt kommt, die gesamte Macht und kann bestimmen, wie sie funktioniert oder wie sie aussieht. Vor allem dann, wenn sie behaupten, das jeweilige Zielerlebnis sei „technisch nicht möglich“, was oft abgekürzt wird für „wirklich schwierig“, „das macht mir keinen Spaß“ oder „ich glaube, das geht besser“. Also werde ich die Entwicklerkarte ziehen“.

Jetzt weiß ich, dass ich hier unfair hart zu Entwicklern bin und das nicht meine Absicht ist. Es gibt einige erstaunlich talentierte Technologen da draußen, die sich wirklich um Benutzerfreundlichkeit kümmern und das Beste für den Benutzer tun wollen. Allerdings fühlt es sich oft so an, als ob es ein asymmetrisches Maß an Respekt zwischen den Disziplinen gibt, weil man glaubt, dass Design einfach ist und daher jeder eine Meinung haben kann, während Entwicklung schwierig und nur für speziell Eingeweihte ist. Obwohl Designer ermutigt (manchmal erwartet) werden, jeden in den Designprozess einzubeziehen, wird ihnen oft nicht derselbe Luxus gewährt.

Ehrlich gesagt mache ich ihnen keinen Vorwurf. Schließlich kenne ich gerade genug Entwicklung, um gefährlich zu sein, also wären Sie ein Idiot, wenn Sie meine Meinung zu Datenbankstruktur und Codeleistung hören wollten (außer dass ich Leistung größtenteils für eine gute Sache halte). Andererseits weiß ich genug, um zu sagen, wann die Entwickler an Dingen herumfummeln, und es macht immer Spaß, mit einem funktionierenden Prototyp von etwas auf sie zurückzukommen, von dem sie sagten, dass es unmöglich sei oder Monate zur Implementierung brauche – aber ich schweife ab.

Das Problem ist, dass viele Entwickler in Bezug auf Design in der gleichen Position sind – sie erkennen es nur nicht. Wenn sie also ein Oberflächenelement auf der Grundlage von etwas ändern, das sie vor einigen Jahren auf einer Konferenz gehört haben, fehlt ihnen möglicherweise wichtiger Kontext. Vielleicht war dies etwas, das Sie bereits getestet und abgezinst haben, weil es schlecht funktioniert hat. Vielleicht haben Sie dieses Element aus einem bestimmten Grund, z. B. Barrierefreiheit, einem anderen vorgezogen? Oder vielleicht waren die Meinungen der Entwickler einfach falsch, basierend darauf, wie sie das Web als Superuser und nicht als durchschnittliche Jo erleben.

Lassen Sie uns hier etwas klarstellen. Ich sage nicht, dass Entwickler kein Interesse am Design zeigen oder in den Designprozess einfließen sollten. Ich glaube fest an funktionsübergreifendes Pairing und denke, dass einige der besten Usability-Lösungen vom Tech-Team stammen . Es gibt auch viele talentierte Leute da draußen, die eine Vielzahl von Disziplinen abdecken. Irgendwann muss das Erlebnis jedoch Eigentum sein, und ich denke nicht, dass es der letzten Person gehören sollte, die die HTML-Datei öffnet und „den Truck anfasst“.

Wenn also gute Designer das Können und die Erfahrung großer Entwickler respektieren, wie wäre es dann mit ein wenig Parität? Wenn Designer froh sind, dass Entwickler „den Code besitzen“, warum zeigen sie dann nicht ein ähnliches Maß an Respekt und lassen Designer „die Erfahrung besitzen“ ?

Kommunikation ist der Schlüssel, also sei verfügbar.
Jeder hat eine Meinung. Dies ist jedoch kein ausreichender Grund, einfach einzutauchen und Änderungen vorzunehmen. Bildnachweis: Open Source Way

Dies ist ziemlich einfach. Wenn Sie sich jemals in einer Situation befinden, in der Sie sich nicht sicher sind, warum etwas auf eine bestimmte Weise entworfen wurde, und denken, dass es besser gemacht werden könnte, tauchen Sie nicht einfach ein und beginnen Sie, Änderungen vorzunehmen . Wenn Sie auf eine technische Hürde stoßen und denken, dass es Ihr Leben einfacher machen würde, etwas anders zu gestalten, sprechen Sie mit Ihrem Designer. Sie können mit Ihren vorgeschlagenen Änderungen absolut einverstanden sein, oder sie möchten vielleicht weggehen und über andere Möglichkeiten zur Lösung des gleichen Problems nachdenken.

Schließlich geht die Zusammenarbeit in beide Richtungen. Wenn Sie also nicht möchten, dass Designer Ihren Code außerhalb Ihrer Versionskontrollprozesse auf dem Live-Server „optimieren“, hören Sie bitte auf, dasselbe mit ihrem Design zu tun.