Comme pour toute décision de design, la réponse à la question « les designers UX devraient-ils apprendre à coder ? » est : « Ça dépend ». Lorsque vous travaillez avec des produits digitaux, il se peut que vous n’ayez pas toujours besoin d’écrire des lignes de code, mais c’est un avantage supplémentaire de savoir comment créer le produit que vous concevez.
Dans les premiers jours du design web, les graphistes, qui avaient auparavant travaillé dans l’imprimé, ont appris à écrire du code pour devenir webdesigner. Le code à l’époque était les premières versions de HTML et CSS.
Beaucoup de choses ont changé depuis – Internet et les technologies digitaux ont évolué et sont plus puissantes. Après qu’Apple ait lancé le premier iPhone et introduit l’écosystème App Store en 2007, les entreprises et les start-ups ont commencé à offrir des expériences interactives riches à leurs clients via des applications web et mobiles. Cela a conduit à la nécessité d’une approche plus holistique de l’expérience de l’utilisateur.
Les premiers designers UX avaient tendance à avoir une formation en design graphique et web. Cet héritage de graphistes devenus web devenus UX a donné lieu à un très large éventail d’attentes de la part des designers UX. Les designers devaient générer des idées, créer des illustrations et aider à construire les produits.
Le design de l’expérience utilisateur (UX) rassemble plusieurs disciplines – de design industriel et l’interaction homme-machine, en passant par l’ethnographie et la psychologie, aux systèmes et design visuel. La programmation informatique devrait-elle également faire partie des compétences d’un designer UX ? Examinons les deux arguments : pourquoi vous devriez et pourquoi vous n’avez pas besoin d’apprendre à coder.
Pourquoi devriez-vous apprendre à coder
Comprendre les matériaux du produit
De manière générale, les entreprises et les clients s’attendent à ce que les designers connaissent les matériaux et les processus nécessaires pour donner vie à leurs créations.
Disons qu’un créateur de mode fait un croquis pour une robe. Quel est le matériau utilisé pour créer cette robe ? Quelle est sa texture ? Combien de temps faudra-t-il pour l’assembler ? Aura-t-il besoin, par exemple, d’un équipement spécialisé pour couper ou coudre le matériau ? Le designer connaît généralement les réponses à ces questions, mais n’effectue pas nécessairement l’une des tâches (se procurer du matériel, couper, coudre, teindre, etc.).
De même, un architecte qui crée le plan d’un espace de bureau est conscient de la façon dont ses créations seront construites. Elle n’a pas besoin de mélanger le béton et de poser les briques, mais on s’attend à ce qu’elle sache si, par exemple, le terrain délimité pour le projet sera capable de supporter un bâtiment en béton.
Si nous étendons ces analogies au design UX, les matériaux utilisés pour donner vie aux créations – applications web/mobiles, produits ou services – incluent des composants technologiques. Un designer UX doit donc savoir comment fonctionnent les technologies nécessaires à la construction d’un produit, pour pouvoir le concevoir.
Flux de travail plus rapides
Lorsqu’un designer comprend la technologie, il peut identifier et mettre en œuvre des solutions pour résoudre les défis des clients, sans aller-retour avec l’équipe de développement / technique pour vérifier ce qui est possible et quand elle peut être mise en œuvre. Cela fait gagner du temps à l’équipe et permet de livrer les produits plus rapidement, avec moins d’itérations.
Essentiel pour les organisations Lean
Une organisation lean vise à maximiser la valeur client, en utilisant le moins de ressources possible. L’organisation s’efforce de réduire les coûts, d’augmenter la rentabilité et, en même temps, de créer de meilleures solutions à un rythme plus rapide pour garder une longueur d’avance sur la concurrence.
Les start-ups bootstrap, en revanche, ont moins de ressources au départ – il n’est peut-être pas possible de financer une grande équipe.
Que l’organisation choisisse de réduire ses coûts (avec une méthodologie allégée) ou qu’elle y soit contrainte (par des contraintes de financement), les entreprises préfèrent embaucher des membres d’équipe dotés de compétences multiples.
Pourquoi vous n’avez pas besoin d’apprendre à coder
Extension continue de portée
Nous avons commencé par l’argument selon lequel les designers doivent connaître les matériaux des produits que nous concevons. Cependant, le code n’est pas le seul élément d’un produit digital. Le designer UX prend en compte l’ensemble du parcours du client final. Cela comprend tout, du message de la marque qui attire les clients, au site web sur lequel le client effectue des achats, en passant par la langue des conditions d’utilisation. Il comprend la microcopie sur l’interface du produit, la politique sur les données personnelles et les réponses de tout responsable du service client qui gère les requêtes du client.
Si nous devions inclure tous les matériaux et processus nécessaires pour offrir une excellente expérience utilisateur, cela inclurait également une foule d’autres fonctions commerciales. Où tracer la ligne ? En termes techniques, nous appellerions cela le extension continue de portée – lorsque la portée du travail s’élargit continuellement.
Vision du tunnel
Les designers qui connaissent bien la programmation peuvent se limiter en termes de solutions. Si nous sommes conscients de la technologie disponible et de ses contraintes, cela influence notre réflexion. Nous pouvons être rattrapés par des détails techniques et ne pas pouvoir penser librement. Cela va à l’encontre de tout l’objectif du design centré sur l’utilisateur, où l’objectif est de penser d’abord aux personnes et non à la technologie.
Mauvaise utilisation des ressources
L’un des défis pour les designers UX (et même les développeurs) est que le monde de la technologie continue d’évoluer, avec de nouveaux langages et frameworks développés à un rythme rapide. Nous pouvons apprendre un langage, seulement pour découvrir qu’il est devenu obsolète en quelques mois. Il est plus rapide et plus facile pour un développeur de logiciels, qui travaille principalement avec du code, de s’adapter et de se familiariser avec les nouvelles technologies. La designer peut consacrer son temps à des activités liées au design (comprendre les utilisateurs et leurs défis et identifier des solutions) sans se soucier des dernières technologies.
À mesure que la technologie continue d’évoluer, il est également probable que des outils low-code ou glisser-déposer soient disponibles. Dans un tel scénario, les designers peuvent simplement utiliser ces outils et n’ont pas besoin de lire ou d’écrire de code.
La question de savoir s’il faut apprendre à coder n’est donc pas pertinente. Il est plus important de comprendre les différentes pièces mobiles au sein de la solution.
Tout comme pour les langages humains, notre capacité à lire un langage informatique peut être différente de notre capacité à l’écrire. La capacité de comprendre comment un langage ou une technologie particulière est utilisée pour créer un produit est différente de notre capacité à l’implémenter.
L’acte d’équilibrage : I-Persona vs T-Persona
Un I-persona ou une personne en forme de I est celle qui a une connaissance approfondie dans un domaine. Par exemple, dans le cadre d’une application mobile, un designer peut être en mesure de faire de la recherche d’utilisateurs, créer des flux d’utilisateurs, dessiner des wireframes, créer les interfaces utilisateur et créez des illustrations. Cette profondeur verticale ressemble à la lettre « I ».
Un T-persona est celui qui a un niveau d’expertise similaire à celui du I-persona, mais qui a également une compréhension générale d’autres domaines. La vaste connaissance des autres domaines devient la ligne horizontale au-dessus du « I », ressemblant ainsi à la lettre « T ».
Un I-persona est celui qui possède une connaissance approfondie de son domaine. Le T-persona possède des connaissances approfondies dans un domaine, ainsi que de vastes connaissances dans tous les domaines.
Dans une équipe où il y a plus de T-personas, la communication au sein de l’équipe devient plus facile. Il en résulte de meilleurs produits, qui peuvent être expédiés plus rapidement, avec moins d’itérations. Dans une interview avec The Chief Executive Group, Tim Brown, CEO d’IDEO, a expliqué pourquoi l’entreprise croit en l’embauche de personnes en forme de T :
La plupart des entreprises comptent de nombreuses personnes aux compétences différentes. Le problème, c’est que lorsque vous réunissez des gens pour travailler sur le même problème, si tout ce qu’ils ont, ce sont ces compétences individuelles – si elles sont en forme de I – il leur est très difficile de collaborer. Ce qui a tendance à arriver, c’est que chaque discipline individuelle représente son propre point de vue. Cela devient essentiellement une négociation à la table pour savoir le point de vue de qui l’emporte, et c’est à ce moment-là que vous obtenez des compromis gris où le mieux que vous pouvez réaliser est le plus petit dénominateur commun entre tous les points de vue. Les résultats ne sont jamais spectaculaires mais au mieux moyens.
– Tim Brown, CEO, IDEO
Prenons un exemple hypothétique d’une entreprise où tout le monde est un I-persona. Un designer propose que la navigation de l’application puisse être restructurée pour une meilleure utilisabilité. Le développeur précise que l’architecture actuelle de l’application ne prend pas en charge cette nouvelle navigation. Cela vaudrait-il la peine de reconstruire l’ensemble de l’application dans l’intérêt de la nouvelle navigation ? Ou le designer devrait-il réfléchir à des solutions alternatives ? Le développeur peut suggérer une solution technique alternative, que le designer peut ne pas comprendre complètement. Dans n’importe lequel de ces scénarios, toute l’équipe perd du temps en propositions, arguments et itérations. Si le designer pouvait comprendre les défis techniques, il serait mieux placé pour suggérer une alternative. Cela vaut également pour d’autres aspects du parcours de l’utilisateur.
Dans une organisation axée sur le design, les équipes interdisciplinaires travaillent en étroite collaboration les unes avec les autres. Chaque membre de l’équipe apporte son expertise. Il peut ne pas être possible pour tous les membres de l’équipe d’être aussi compétents en design, en business et en technologie. Une compréhension générale de l’expertise de chacun contribue à améliorer la communication au sein de l’équipe et accélère la vitesse à laquelle les produits sont construits.
Assembler les pièces du puzzle
Nous nous sommes concentrés sur l’importance de l’étendue des connaissances des designers – que ce soit sur les composants technologiques ou d’autres aspects du parcours de l’utilisateur. Il en va de même pour les autres membres d’une équipe dirigée par le design. Une connaissance générale des technologies permet au propriétaire d’entreprise de comprendre les contraintes et les possibilités. De même, la connaissance du processus de design et des méthodologies utilisées est essentielle pour tous les membres de l’équipe, pas seulement pour les designers. En fin de compte, c’est le parcours de l’utilisateur final qui compte. Toute l’équipe doit travailler avec cette vision commune afin que toute l’expérience soit meilleure que la somme de toutes les parties.
Ce qu’il faut savoir
Les designers UX sont responsables du parcours de l’utilisateur final. Ce parcours comprend différents points de contact – des conditions légales d’utilisation au modèle de tarification, de la microcopie aux illustrations et images, et du service client au code derrière les produits.
Dans une petite équipe amorcée, les concepteurs peuvent devoir assumer plus de responsabilités; et ainsi, ils peuvent également avoir besoin d’apprendre à construire les produits. Dans les grandes équipes, connaître les tenants et les aboutissants des langages de programmation peut ne pas être nécessaire. Cependant, il est important de savoir comment les différents éléments de la solution s’intègrent et fonctionnent ensemble pour pouvoir communiquer au sein de l’équipe et rendre le processus de développement de produit plus efficace.
Enfin, la responsabilité de comprendre le travail de chacun incombe à chaque membre de l’équipe, pas seulement aux designers.
Références et où en savoir plus
Pour en savoir plus sur les arguments en faveur de l’acquisition d’une expertise dans plus d’un domaine, ainsi que sur des exemples fascinants, consultez cet article :
Ryan Holiday, The Case for Being a Multi-Hyphenate, 2019
https://humanparts.medium.com/
Interview de Tim Brown par Tim Brown, CEO du groupe IDEO Chief Executive : T-Shaped Stars : The Backbone of IDEO’s Collaborative Culture, 2010
https://chiefexecutive.net/
