Les développeurs "possèdent" le code, alors les concepteurs ne devraient-ils pas "posséder" l'expérience ?

Nous y avons tous été. Vous avez passé des mois à rassembler les besoins de l'entreprise, à élaborer des parcours utilisateur complexes, à créer des éléments d'interface de précision et à les tester sur un échantillon représentatif d'utilisateurs, pour finalement voir un produit final qui ressemble peu à l'expérience souhaitée .

Peut-être auriez-vous dû être plus énergique et insister sur une approche agile, malgré votre conviction que l'organisation n'était pas prête ? Vous auriez peut-être dû faire un meilleur travail avec vos portefeuilles de modèles, en vous assurant que les développeurs utilisaient votre bibliothèque de code modulaire plutôt que de créer cinq variantes différentes d'un carrousel. Ou peut-être auriez-vous même dû vous asseoir à côté de l'équipe de développement tous les jours pour vous assurer que ce que vous avez conçu se réalise réellement.

Lectures complémentaires sur SmashingMag :

• Pourquoi devriez-vous inclure votre développeur dans le processus de conception
• Collaboration d'équipe et réduction des écarts d'efficacité dans la conception réactive
• Concepteurs et développeurs jouant à Nice
• Comment communiquer efficacement avec les développeurs

Au lieu de cela, vous vous retrouvez avec un fouillis d'éléments d'interface utilisateur, avec toute la subtilité supprimée. N'ont-ils pas pu voir que vous avez travaillé pendant des jours pour que les transitions soient parfaites, uniquement pour qu'elles soient insérées dans une bibliothèque d'animations par défaut ? Et d'où diable est venue cette étape supplémentaire de départ. Je parie que le marketing a ajouté cela à la dernière minute. Vous saviez que l'intégration allait être difficile et qu'il faudrait faire des compromis, mais nous sommes censés faciliter la vie des utilisateurs ici, pas l'équipe technique.

Bien sûr, il existe de nombreuses bonnes raisons pour lesquelles le site est ainsi. Différentes équipes avec différents niveaux de compétences travaillant sur différentes parties du projet, un tas de changements de dernière minute raccourcissant le cycle de développement et une multitude de défis techniques. Pourtant, pourquoi l'équipe de développement n'a-t-elle pas pu venir vous demander conseil sur les modifications de l'interface utilisateur ? Vous ne jouez pas avec leur code, alors pourquoi doivent-ils changer vos conceptions ? Surtout quand l'impact commercial peut être énorme ! Vous n'êtes qu'au coin de la rue et vous auriez été heureux de vous aider s'ils avaient simplement demandé.

Bien que l'histoire ci-dessus puisse être fictive, c'est un sentiment que j'entends de tous les coins du monde du design, que ce soit en interne ou en agence. Une expérience soigneusement conçue ruinée par une équipe de développement autoritaire.

Cette expérience me rappelle un reportage que j'ai vu sur une chaîne d'information locale américaine il y a plusieurs années. Une foire de comté organisait une compétition d'endurance où la dernière personne restant avec la main sur une camionnette remportait le prix. Je pense souvent que le design est comme un énorme jeu de "toucher le camion" , l'équipe de développement repartant toujours avec les clés à la fin du concours. Comme le dernier mot d'une dispute, la dernière personne à entrer en contact avec le site détient tout le pouvoir et peut dicter son fonctionnement ou son apparence. Surtout s'ils prétendent que l'expérience cible particulière n'est pas "techniquement possible", ce qui est souvent un raccourci pour "vraiment difficile", "je ne peux pas être dérangé de le faire de cette façon" ou "je pense qu'il y a une meilleure façon de le faire alors je vais tirer la carte de développement ».

Maintenant, je sais que je suis injustement sévère envers les développeurs ici et je ne veux pas l'être. Il existe des technologues incroyablement talentueux qui se soucient vraiment de la convivialité et veulent faire de leur mieux pour l'utilisateur. Cependant, on a souvent l'impression qu'il existe un niveau de respect asymétrique entre les disciplines en raison de la conviction que le design est facile et donc quelque chose sur lequel tout le monde peut avoir une opinion, tandis que le développement est difficile et réservé aux initiés. Ainsi, alors que les concepteurs sont encouragés (parfois attendus) à impliquer tout le monde dans le processus de conception, ils n'ont souvent pas le même luxe.

Pour être honnête, je ne les blâme pas. Après tout, je connais juste assez de développement pour être dangereux, donc vous seriez idiot si vous vouliez mon avis sur la structure de la base de données et les performances du code (autre que je pense en grande partie que la performance est une bonne chose). Là encore, j'en sais assez pour dire quand les développeurs truquent les choses et c'est toujours amusant de leur revenir avec un prototype fonctionnel de quelque chose qu'ils ont dit impossible ou qui prend des mois à mettre en œuvre - mais je m'éloigne du sujet.

Le problème est que je pense que beaucoup de développeurs sont dans la même position à propos du design — ils ne s'en rendent tout simplement pas compte. Ainsi, lorsqu'ils modifient un élément d'interface en se basant sur quelque chose qu'ils avaient entendu lors d'une conférence il y a quelques années, il se peut qu'ils manquent de contexte important. C'est peut-être quelque chose que vous avez déjà testé et ignoré car il fonctionnait mal. Peut-être avez-vous choisi cet élément plutôt qu'un autre pour une raison précise, comme l'accessibilité ? Ou peut-être que les opinions des développeurs étaient tout simplement erronées, en fonction de leur expérience du Web en tant que superutilisateurs plutôt qu'en tant que Jo moyen.

Maintenant, mettons quelque chose au clair ici. Je ne dis pas que les développeurs ne devraient pas s'intéresser à la conception ou participer au processus de conception. Je crois fermement au jumelage interfonctionnel et je pense que certaines des meilleures solutions d'utilisabilité émanent de l'équipe technique . Il y a aussi beaucoup de gens talentueux qui couvrent une multitude de disciplines. Cependant, à un moment donné, l'expérience doit être possédée, et je ne pense pas qu'elle devrait appartenir à la dernière personne à ouvrir le fichier HTML et à "toucher le camion".

Donc, si les bons designers respectent les compétences et l'expérience des grands développeurs, que diriez-vous d'un peu de parité ? Si les concepteurs sont heureux que les développeurs "possèdent le code", pourquoi ne pas montrer un respect similaire et laisser les concepteurs "s'approprier l'expérience" ?

Faire cela est assez simple. Si jamais vous vous retrouvez dans une situation où vous n'êtes pas sûr de la raison pour laquelle quelque chose a été conçu d'une manière particulière et pensez que cela pourrait être mieux fait, ne vous contentez pas de plonger et de commencer à apporter des modifications . De même, si vous rencontrez un obstacle technique et pensez que cela vous faciliterait la vie de concevoir quelque chose d'une manière différente, parlez-en à votre designer. Ils peuvent être tout à fait d'accord avec vos modifications suggérées, ou ils peuvent vouloir s'en aller et réfléchir à d'autres façons de résoudre le même problème.

Après tout, la collaboration va dans les deux sens. Donc, si vous ne voulez pas que les concepteurs commencent à "optimiser" votre code sur le serveur en direct, en dehors de vos processus de contrôle de version, veuillez cesser de faire de même pour leur conception.