Etant développeur et m'occupant entre autre de la partie interface utilisateur sur des projets professionnels et personnel j'ai souvent été confronté à ce problème.
Penser l'interface avant n'est pas synonyme de réussite, on a beau faire des mockups tant que l'on n'a pas un prototype utilisable on ne peut pas valider l'ergonomie réelle du bouzin.
Modifier une application existante peut tourner au cauchemar:
Si il faut changer le toolkit/framework c'est bonjour au revoir.
Si je dois changer un widget mais que le remplaçant n'a pas les propriété que l'ancien, ça m'éneeerveu.
Si on a besoin d'accéder à des données qui sont enfouies au fin fond de l'application, 𝄽 (<=soupir utf8).
Les exemples ne manquent pas.
Donc parfois la charge de travail et le risque de tout péter peut rebuter le développeur, c'est compréhensible.
L'idée qu'un développeur et un designer partent main dans la main sur un nouveau projet open source impliquerai qu'ils se connaissent suffisamment auparavant pour avoir confiance l'un dans l'autre.
J'ajouterai aussi que la qualité de l'UX est quelque chose de subjectif, il y a facilement un consensus quand le résultat est pourri mais pour juger que le résultat est réussi on sombre dans les préférences personnelle de chacun, les gouts et les couleurs tout ça.
Par dessus il y aurai aussi le complexe du développeur: le designer impose sa vision, il peut s'approprier le crédit du résultat visuel final et le développeur a le sentiment de n'être que l'esclave des désirs du premier.
Au final ce que j'ai constaté dans le libre ou dans l'entreprise, après des dizaines de réunions et de discussions sur ce que l'on devrait faire ou pas, c'est toujours celui qui code en premier en truc utilisable en production qui l'emporte.
# Ce n'est pas facile.
Posté par groumf . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 5.
Etant développeur et m'occupant entre autre de la partie interface utilisateur sur des projets professionnels et personnel j'ai souvent été confronté à ce problème.
Penser l'interface avant n'est pas synonyme de réussite, on a beau faire des mockups tant que l'on n'a pas un prototype utilisable on ne peut pas valider l'ergonomie réelle du bouzin.
Modifier une application existante peut tourner au cauchemar:
Si il faut changer le toolkit/framework c'est bonjour au revoir.
Si je dois changer un widget mais que le remplaçant n'a pas les propriété que l'ancien, ça m'éneeerveu.
Si on a besoin d'accéder à des données qui sont enfouies au fin fond de l'application, 𝄽 (<=soupir utf8).
Les exemples ne manquent pas.
Donc parfois la charge de travail et le risque de tout péter peut rebuter le développeur, c'est compréhensible.
L'idée qu'un développeur et un designer partent main dans la main sur un nouveau projet open source impliquerai qu'ils se connaissent suffisamment auparavant pour avoir confiance l'un dans l'autre.
J'ajouterai aussi que la qualité de l'UX est quelque chose de subjectif, il y a facilement un consensus quand le résultat est pourri mais pour juger que le résultat est réussi on sombre dans les préférences personnelle de chacun, les gouts et les couleurs tout ça.
Par dessus il y aurai aussi le complexe du développeur: le designer impose sa vision, il peut s'approprier le crédit du résultat visuel final et le développeur a le sentiment de n'être que l'esclave des désirs du premier.
Au final ce que j'ai constaté dans le libre ou dans l'entreprise, après des dizaines de réunions et de discussions sur ce que l'on devrait faire ou pas, c'est toujours celui qui code en premier en truc utilisable en production qui l'emporte.