Pourquoi les développeurs sont-ils ignorés par UX?
Je suis un développeur de logiciels amateur qui regarde attentivement l'UX pour mieux concevoir les logiciels en pensant à l'utilisateur. J'apprécie la tactique qu'UX fait pour trois raisons principales:
- L'avantage de l'utilisateur (familiarité, facilité d'utilisation, etc.)
- Rendement financier (une mauvaise convivialité détourne les clients)
- Gain de temps (temps supplémentaire consacré à la conception = moins de temps consacré à l'explication)
Naturellement, après avoir travaillé sur la création de tout ce qui est génial pour d'autres personnes, je suis frappé par la gêne à utiliser certains outils de développement. Ne devraient-ils pas être les premiers à mettre en œuvre de bonnes pratiques UX, ce qui ne peut avoir que des effets positifs sur le logiciel en cours de développement?
Je suis conscient de l'argument de l'efficacité à long terme par rapport à la courbe d'apprentissage facile, mais nous parlons ici de diminuer l'efficacité à long terme, car il y a tellement de choses à retenir qu'il est facile d'oublier et de réapprendre.
Donc, pour résumer, y a-t-il une raison logique, soutenue par la recherche ou pratique derrière la construction d'outils de développement différemment des applications utilisateur final, d'un point de vue UX?
Les lecteurs qui n'aiment pas les longs messages peuvent s'arrêter ici. Le texte ci-dessous est juste pour sauvegarder ce que j'ai dit ci-dessus.
Avant de crier que j'ai commis le péché de l'hypothèse non prise en charge, voici quelques exemples d'outils de développement courants qui devraient aider à sauvegarder mon raisonnement. Et, d'accord, tous les outils ne sont pas mauvais (je trouve personnellement IntelliSense, par exemple, assez optimisé pour l'UX) ... Mais trop sont.
La langue PHP
Ses fonctions intégrées présentent toutes sortes de défauts. La fonction implode (), qui joint un tableau de chaînes à l'aide d'un délimiteur, par exemple:
- est nommé différemment des autres langues (manque de familiarité avec l'utilisateur)
- a un nom non descriptif (imploser n'a aucun lien avec les chaînes du tissu physique ni avec l'idée de tableaux)
- a un modèle de dénomination différent des autres fonctions de manipulation de chaînes dans PHP (incohérence)
L'IDE Eclipse
Certaines choses que je n'ai pas pu mettre en évidence dans la capture d'écran:
- L'ouverture des dialogues est lente et ne répond pas (au moins sur une machine médiocre)
- Changer des choses simples comme les propriétés des éléments nécessite une interaction en 3 étapes par rapport à une étape idéale
- le générateur XML est lourd et ses dialogues sont visuellement lourds
Ne déplacez pas mon fromage
Je pense que c'est un problème classique où les développeurs qui ont créé ces outils n'ont pas pu prévoir comment leurs applications vont être utilisées. Lorsque vous pouvez tout prévoir, vous êtes en mesure de concevoir un excellent UX du premier coup. Mais cela ne se produit tout simplement pas ici. Et puis, au fur et à mesure que des fonctionnalités sont ajoutées, elles ne prennent pas la peine de réorganiser leur application par peur de déranger leurs utilisateurs existants. C'est une peur valable.
À titre d'exemple, je pense à Visual Studio 2013 comme une application très agréable et intuitive même si c'est un géant. Mais mon opinion sur Visual Studio est largement basée sur ma connaissance de celui-ci. C'est cette familiarité qui me rend productif chaque jour. Donc, casser cela en repensant et en réorganisant l'application entière pourrait être applaudi par certains, mais cela me dérangerait.
n compromis
Microsoft a réorganisé Visual Studio au fil des ans pour faire place à de nouvelles fonctionnalités. Mais ils essaient de faire leurs changements relativement petits d'une version à l'autre afin que les gens comme moi n'aient pas à réapprendre à tout faire. Je pense que c'est une bonne approche.
Étant développeur en PHP, Android, C # et travaillant professionnellement avec SharePoint, je ne peux qu'applaudir à cette question. Dans de nombreux langages et IDE en développement, il semble parfois que quelqu'un ait eu une idée et elle a été implémentée sous forme de bouton, d'élément de menu ou de raccourci clavier. Sans y penser, cette fonctionnalité sera réellement utilisée par quelqu'un.
Parfois, on a l'impression que c'est un sport de cacher des fonctionnalités dans un IDE ou un langage de programmation. Cela est particulièrement vrai dans SharePoint où il est ridiculement évident que les développeurs de la pile de code travaillent dans des silos isolés Il a évolué pour le mieux, mais il y a encore beaucoup d'incohérence dans le produit.
Donc que fais-tu? Vous apprenez à vivre avec les défauts du produit/de la langue/de l'IDE que vous utilisez parce que vous le devez, ou vous en développez un nouveau. C'est pourquoi nous avons des milliers de langages de programmation et de frameworks, que les développeurs doivent réapprendre encore et encore. D'une personne n'aime pas la réalité de cette profession - il faut changer d'orientation et de tâches. Vous avez parcouru un long chemin sur votre chemin pour devenir un vrai professionnel UX, mon ami!