Les chats et les chiens. Caïn et Abel. Designers et développeurs. Ce ne sont que quelques-uns des grands affrontements historiques.

Les concepteurs et les développeurs semblent souvent provenir de différentes planètes et avoir des cerveaux complètement différents.

Les développeurs veulent qu'un site Web fonctionne correctement, les concepteurs veulent qu'il soit correct.

Bien que ces objectifs se chevauchent beaucoup (et, bien sûr, les stéréotypes ici un peu), les différences résultent souvent des attentes de réussite du concepteur et du développeur.

La gestion des attentes est une question de communication: faire clairement ressortir les points de vue opposés, trouver un terrain d’entente et convenir des objectifs.

Ok, alors peut-être que ce n'est pas si facile, mais il est important que les deux parties essaient au moins de se comprendre .

Dans un effort pour promouvoir la bonne volonté entre les concepteurs et les développeurs, je partagerai quelques anecdotes entre animaux de compagnie que j’ai rencontrées et explorerai les problèmes qui les mènent et leurs solutions.

Peeve # 1: "Pourquoi le développeur ne peut-il pas juste faire ressembler le comp?"

Vous créez un design attrayant et transférez la composition à votre développeur, mais lorsque vous récupérez le site, il ressemble à un patchwork de ce que vous avez conçu.

Problème
Les comps ne sont pas des pages Web; ils ne sont pas un mélange de code HTML, CSS et JavaScript. Photoshop, Fireworks et Illustrator peuvent réaliser de nombreuses tâches impossibles (ou du moins extrêmement peu pratiques) sur le Web, ce qui signifie souvent que les développeurs devront réduire la conception.

Solution
Parlez à votre développeur pendant que vous concevez, pas seulement après. Demandez-leur si un effet que vous utilisez sera facile à réaliser ou si une meilleure alternative existe. De plus, à mesure que vous en apprendrez davantage sur le développement Web, vous serez en mesure de mieux faire la différence entre le moment où votre conception est impraticable et le moment où le développeur se relâche.


Peeve # 2: "Les couleurs sont toutes fausses!"

Vous ne choisissez pas de couleurs arbitrairement, mais les développeurs semblent penser que "la fermeture est assez proche".

Problème
Je ne sais pas si cela est vrai pour tous les développeurs, mais j’ai déjà travaillé avec un développeur qui était daltonien (il était un grand fan de notre gestionnaire de contenu, qui a envoyé tous ses e-mails en rose sur un fond vert citron). Cependant, être daltonien ne l'a pas empêché d'être un développeur de kick-ass.

Solution
Si vous souhaitez que les couleurs soient correctes, épelez toutes les valeurs de couleur sur la page. Ne comptez pas sur votre développeur pour surveiller les valeurs de couleur ou pour échantillonner les couleurs dans Photoshop.

Vous devez également considérer que le problème peut ne pas être avec le développeur, mais avec vous. Les couleurs sont différentes sur Mac et CMJN (si vous activez accidentellement cet espace colorimétrique). Assurez-vous que le mode couleur du document et les épreuves sont définis par défaut sur RVB générique.


Peeve # 3: "Les développeurs savent-ils même ce que signifie l’ espace blanc ?"

Vous avez laissé suffisamment de place autour des éléments pour créer un parcours oculaire fluide et améliorer la lisibilité, mais le développeur regroupe tout, vous disant: "C'est la seule façon dont tout ira bien".

Problème
Une fois, je me suis plaint auprès d'un développeur qu'il ne laissait aucun espace entre la bordure d'un module et son contenu, ce qui rend la lecture difficile pour la plupart des gens. Il a répondu: "Je ne me soucie pas des autres. Je peux le lire. "Bien que la plupart des développeurs ne soient pas si insensibles, ils n'ont pas été formés à l'art de mélanger les espaces positifs et négatifs pour guider le visiteur dans la conception.

Solution
Si vous voulez vraiment que vos conceptions soient aussi précises que possible, ne vous contentez pas de donner au concepteur une image et attendez-vous à ce qu’elles déterminent l’espacement. Spécifiez les largeurs, hauteurs et longueurs exactes dans un document de spécifications de conception. Cela sert de modèle sur lequel vous et le développeur êtes d’accord sur la manière dont les choses doivent être espacées.

Définissez au minimum des règles générales pour les marges et le remplissage. Par exemple, "Tous les modules doivent avoir un minimum de 10 pixels de remplissage entre le contenu et la bordure."


Peeve # 4: "Le développeur ne peut jamais avoir les mêmes designs dans différents navigateurs".

Vous regardez le site dans Firefox et il semble correct, mais lorsque vous passez à Internet Explorer, il tombe en morceaux.

Problème
Vous devez faire preuve de sympathie face à la situation critique des développeurs en matière de cohérence des conceptions entre les navigateurs. Chaque navigateur a ses propres bizarreries d'espacement. Les choses s’améliorent (en particulier avec la mort lente d’Internet Explorer 6), mais il est encore difficile de les faire jouer complètement ensemble.

Solution
J'autorise généralement quelques pixels de marge de manœuvre dans mes conceptions pour tenir compte des problèmes entre navigateurs, mais il est utile de savoir quels sont ces problèmes pendant que vous concevez, afin d'aider le développeur à les éviter.

N'ayez pas peur de signaler les problèmes liés au navigateur au développeur et attendez qu'ils soient corrigés. Mais pour résoudre certains d'entre eux, vous devrez peut-être modifier votre conception.


Peeve # 5: "Cela prendra combien de temps?"

Rien n’est plus déprimant que de graver l’huile à minuit à temps double pour obtenir votre part de projet dans les délais, mais pour récupérer un niveau de développement (Level of Effort) qui ramène la date de sortie du projet à la fin de l’éternité. .

Problème
Dans un épisode classique de Star Trek: The Next Generation , Scotty explique à Geordi La Forge les faits de la vie des ingénieurs: «Vous ne lui avez pas dit [le capitaine Picard] combien de temps cela prendrait-il? Oh, laddie. Vous avez beaucoup à apprendre si vous voulez que les gens vous considèrent comme un faiseur de miracles. "Certains développeurs pensent aux concepteurs de la même manière que Scotty pense aux capitaines de Starfleet.

Solution
Les développeurs savent qu’ils rencontreront des problèmes imprévus et auront donc tendance à grossir leurs estimations. Cela les rend également très bonnes si elles aboutissent beaucoup plus tôt que prévu. Roulez avec le développeur dans un délai raisonnable et maintenez-le. En apprenant à connaître un développeur, vous trouverez votre chance d’être un «faiseur de miracles».


Bonus spécial Peeve: "Les développeurs ne comprennent tout simplement pas les concepteurs."

Ou pire:
"Le développeur pense qu'ils sont un designer!"
C'est déjà assez grave lorsque les développeurs semblent simplement refuser de voir le point de vue du concepteur, mais cette différence d'opinion peut généralement être médiée (généralement par un bon chef de projet). Cependant, lorsque le développeur pense en savoir plus sur le design que le concepteur, les esprits peuvent s’exprimer.

Problème
J'ai eu affaire à plus d’un développeur qui lisait un article par Jakob Nielsen et ensuite voulu me donner des leçons sur les bonnes pratiques de conception en pleine réunion. Cela ne montre pas seulement un manque de respect pour le concepteur mais ralentit le projet au fur et à mesure des débats.

Solution
Travailler avec des développeurs connaissant tout est délicat et la manière de gérer ces situations dépend de la taille de l'ego avec lequel vous faites affaire. En général, je trouve préférable d'écouter simplement ce qu'ils ont à dire et ensuite, s'ils ont un point, reconnaissez-le et passez à autre chose. Évitez de discuter avec eux si possible .

Souvent, leur plainte concerne une "règle" de conception qui a été enfreinte. N'ayez pas peur de reconnaître que vous avez enfreint une règle, c'est-à-dire ce que font les concepteurs novateurs, mais assurez-vous de pouvoir justifier pourquoi vous l'avez brisé .

Chaque fois que je me retrouve dans cette situation, je repense à mes jours de révision dans une école de design, alors que je devais défendre mon travail contre des critiques assez brutales. Ces séances étaient souvent des ecchymoses, mais elles m'ont appris à défendre rapidement mes décisions tout en gardant mon sang-froid.

Cela peut sembler humiliant de devoir constamment justifier vos décisions, mais plus vous montrez la «méthode dans votre folie», plus vous constaterez que vos collègues apprécient et font confiance à votre jugement .



Écrit exclusivement pour WDD par Jason Cranford Teague .

Quels animaux domestiques avez-vous avec les développeurs? Nous aimerions en savoir plus à ce sujet, veuillez partager vos commentaires ci-dessous.