Que doit savoir un professionnel UX sur le développement frontal?
Excusez-moi, s'il s'agit d'une question trop floue, je me demandais ce que les gens pensaient du niveau de connaissances en développement frontal qu'un professionnel UX (architecte d'expérience, concepteur d'utilisabilité, concepteur d'expérience - appelez-le comme vous voulez) devrait avoir.
Je suppose que je parle de situations où les deux disciplines sont gérées par des équipes distinctes (l'équipe UX gère les wireframes/conceptions/parcours utilisateur et l'équipe front-end fait le codage).
Pensez-vous que l'équipe UX peut se débrouiller avec un niveau général de connaissances front-end (compréhension de base de HTML/CSS), ou est-il important pour eux de connaître les détails (structure de page sémantique, techniques d'optimisation, impact de JavaScript, dégradation gracieuse/amélioration progressive, accessibilité, etc.)?
Une équipe UX devrait-elle pouvoir imaginer comment ses conceptions/wireframes seront interprétées par l'équipe front-end et quelles balises/technologies sont susceptibles d'être utilisées?
Le fait d'avoir seulement une connaissance limitée du développement frontal fait-il pour une UX plus pauvre?
Les points les plus fins du développement FE sont-ils uniquement la préoccupation des développeurs frontaux, ou cela devrait-il également être une considération pour l'équipe UX?
Comme je l'ai dit, je sais que c'est une question un peu floue, mais je suis simplement curieux de savoir comment les gens perçoivent les compétences respectives des équipes FE et UX, et combien de flou devrait idéalement se trouver entre les deux.
En tant que personne UX qui travaille dans une situation comme celle que vous décrivez (UX crée les spécifications, FE les met en œuvre), je peux dire qu'il est d'une importance vitale que mon équipe sache ce qui est/n'est pas possible lors de la conception d'une interface utilisateur. Si quelque chose est complètement impossible, nous rendons un service à nos parties prenantes en le proposant.
D'un autre côté, étant donné que seuls quelques membres de notre équipe ont une expérience formelle de codage, nous travaillons toujours en tandem avec nos développeurs. Souvent, nous nous assoyons avec l'équipe de développement avant de présenter nos conceptions aux parties prenantes et de discuter des problèmes de codage potentiels.
En particulier, je crois qu'il est d'une importance vitale que les utilisateurs UX aient (au moins) une compréhension théorique des "choses liées à FE", y compris la structure de page sémantique, les techniques d'optimisation, l'impact de JavaScript, la dégradation gracieuse/l'amélioration progressive, l'accessibilité, etc. Bien sûr, il y a toujours le point de vue de Jared Spool; que à l'avenir, tous les UX seront capables de coder (un point de vue avec lequel je ne suis pas nécessairement d'accord).
Réponse courte: "ça dépend".
Je lutte avec cette question depuis environ 2 ans. Quelques réflexions:
Si vous apprenez à coder, vous passerez beaucoup plus de temps à coder et beaucoup moins de temps à concevoir. Les muscles que vous n'utilisez pas s'atrophieront et ceux que vous utiliserez se développeront à l'exclusion des autres.
UX est un métier et doit être associé à autre chose, comme la conception visuelle, la conception matérielle, le prototypage ou (comme vous l'avez demandé) la possibilité de faire une partie du travail de mise en œuvre.
La plupart des employeurs (et des équipes) souhaitent avoir quelqu'un qui peut "faire les deux", mais c'est rarement le cas; vous faites habituellement l'un ou l'autre, et d'après mon expérience, ce sera surtout du codage.
Si vous apprenez à coder, vous aurez le fardeau d'un codeur. Autrement dit, vous remarquerez que vous commencerez à concevoir pour ce que vous savez que vous pouvez développer.
Il y a des postes ouverts pour ceux qui sont simplement de grands designers, mais ces postes sont rares et très recherchés. Adaptive Path, IDEO, etc. embauchent des concepteurs UX purs.
Alors "devriez" vous? Je ne te connais pas. Si vous êtes un designer stellaire, c'est-à-dire des compétences époustouflantes en croquis et en conception visuelle, continuez à le faire. Si vous êtes quelqu'un qui veut travailler pour rendre un produit réel, le codage est peut-être une bonne compétence.
Je me considère comme une personne UX avec des compétences techniques. Après 3 ans de travail en architecture de solutions, je suis retourné à l'école pour obtenir mon diplôme HCI, puis j'ai travaillé comme designer UX. Je trouve que ma formation technique me donne plus d'un avantage dans les rôles de leadership qu'un simple concepteur, mais mes créations sont moins créatives et innovantes que celles qui ont la possibilité de se concentrer uniquement sur le design.
Mon conseil? Faites ce que vous trouvez intéressant aux côtés du travail UX pur. Cela peut inclure des travaux de conception visuelle ou de développement.
C'est quelque chose qui me bouleverse. Votre question et presque toutes les réponses semblent fonctionner jusqu'à présent sous l'hypothèse que les utilisateurs UX conçoivent des produits pour le Web. Par conséquent, ils "doivent avoir des connaissances de base en HTML, CSS et Javascript".
Pourquoi donc? Qu'en est-il de tous ceux qui conçoivent pour les ordinateurs de bureau et les plates-formes mobiles et diverses - des kiosques aux photocopieuses, aux téléviseurs et aux écrans d'avion? Ont-ils besoin d'avoir une connaissance de base de C, Java, .NET ou autre?
Est-ce que cela fait d'eux une pire personne UX s'ils ne le font pas? Et gardez à l'esprit que nous parlons de la grande majorité des utilisateurs UX travaillant à tous ces éléments et d'innombrables autres. Donc, ce n'est pas un pourcentage de l'industrie aussi négligeable que les gens semblent le croire - en fait, je pense que c'est au moins 50% de celui-ci (regardez le lien encore :)).
Pour rendre cette réponse pas complètement inutile (oui, cela aurait dû être un commentaire) - il est extrêmement utile si les concepteurs UX comprennent comment fonctionne la programmation , de sorte que la plate-forme n'est pas une boîte mystère noire pour eux, et ils peuvent communiquer efficacement avec les techniciens. Mais au-delà, c'est vraiment juste une compétence qui est très agréable à avoir, mais en aucun cas nécessaire.
Les compétences en développement sont évidemment importantes - plus pour les petites équipes que pour les grandes équipes. Ces compétences doivent être couvertes au sein de l'équipe de conception d'une manière ou d'une autre.
Plus important encore, les professionnels de l'expérience utilisateur devraient être extrêmement proches de, ou faire eux-mêmes, le soutien direct aux utilisateurs . Entendre les points douloureux directement des clients ou des utilisateurs devrait avoir une influence directe sur le travail de conception UX en cours, en affinant le produit pour résoudre ces problèmes.
Voici le point de vue de 37signal à ce sujet dans leur premier livre
Une équipe UX qui ne peut pas construire ses recommandations UX est une équipe UX plutôt inutile.
Les membres UX individuels ne doivent pas nécessairement être des codeurs frontaux, mais les compétences doivent exister au sein de l'équipe dans son ensemble. J'ai constaté que les équipes UX qui ne gèrent aucune partie de la production frontale ont tendance à:
- concevoir des interfaces qui ne tirent pas parti des fonctionnalités à jour des navigateurs
- concevoir des interfaces qui ne fonctionnent tout simplement pas à l'écran (en omettant généralement les étapes clés)
- concevoir des interfaces atypiques et/ou réinventer la roue
- ne réfléchissez pas pleinement à chaque point d'interaction
- ne pas concevoir pour les imprévus
J'ajouterai qu'une organisation qui divise son équipe UX de son équipe de développement FE est configurée pour échouer dans le domaine de l'expérience utilisateur. J'ai travaillé dans les deux situations et les situations où l'équipe UX n'a aucune responsabilité de développement, il y a d'énormes quantités d'inefficacités tout au long du projet car il y a tellement de va-et-vient entre les différents départements sans aucune véritable conception itérative.
Une analogie est un architecte qui n'a aucune expérience pratique de la construction. Ces architectes existent, et certains sont assez célèbres, mais pour la plupart des architectes, pour être bons dans ce qu'ils font, ils doivent concevoir des structures qui peuvent être construites en termes d'ingénierie, de budgets et de délais.
Une équipe UX sans compétences en développement frontal est comme un peintre sans compétences en pinceau. ;)
Je pense que pour un concepteur UX, il est important de comprendre les bases du développement frontend. Vous devez savoir ce qu'est HTML, CSS et JS, comment il est interprété par le navigateur et comment le Web fonctionne en général. Mais je ne pense pas qu'il soit nécessaire d'avoir une connaissance approfondie de toutes les possibilités. Cela dit, il est essentiel que les concepteurs UX, les développeurs frontend et les graphistes travaillent en étroite collaboration.
Réflexions supplémentaires: Je ne pense pas que ce soit généralement une bonne idée lorsqu'une personne est responsable de deux disciplines différentes (codage et conception UX) car il n'y a pas beaucoup de gens qui peuvent être très bons dans deux choses (vous devez généralement vous concentrer pour devenir le meilleur). Et il y a le danger qu'une personne UX qui code la page lui-même ne crée que des choses qu'il sait coder.
Je suis conscient que ce n'est probablement pas une opinion très populaire, mais je pense que les spécialistes travaillant en étroite collaboration sont ce qui produit des solutions de pointe et repousse les limites de ce qui est possible. Rappelez-vous l'époque où nous étions appelés Webdesigners? La programmation, le frontend, la conception, la gestion de projet, etc. ont été réalisés par une seule personne. C'était amusant? Sûr! At-il produit de bons résultats? Rarement.
Dans le développement frontend de mon entreprise et la conception UX et UI, il y a une seule équipe (2 codeurs, 2 graphistes, 1 architecte UX) et je pense que c'est ainsi.
Je ne suis pas sûr qu'un professionnel UX qui connaisse le développement front-end ferait une UX meilleure ou moins bonne en soi, après tout, la personne UX devrait être consciente des progrès tout au long du cycle de vie et la régner là où elle s'égare. Si nous faisions notre travail et le transmettions au groupe suivant sans même un autre regard, vous vous retrouveriez avec le scénario classique swing d'arbre .
Ce qui m'amène au point que je veux faire valoir, c'est qu'avoir une connaissance du domaine des développeurs frontaux, être familier avec leurs compétences, leurs outils et leur langage et terminologie ne fera qu'aider grandement le communication d'idées à plusieurs niveaux entre les groupes, que ce soit dans le cadre d'un cahier des charges formel - ou simplement dans un salon de discussion.
Et cela vaut pour tous les groupes impliqués dans la production d'un produit - conception graphique, marketing, image de marque, développement front-end, gestionnaires de contenu, rédacteurs techniques et salle de conférence - toutes les parties prenantes. Le domaine UX est large et comprendre tous ces rôles, être familier avec leur monde et sympathiser avec eux permet au professionnel UX de communiquer beaucoup mieux, à la fois pour comprendre les besoins des autres groupes et pour transmettre leurs propres idées, conceptions et raisonnements .
Cela rend donc le processus plus efficace, et peut-être un peu plus convivial, si d'autres groupes respectent le fait qu'ils se comprennent mutuellement. C'est un peu comme nous les Britanniques qui partent à l'étranger et qui sont un peu plus acceptés par les Français pour au moins essayer de parler un peu leur langue.
Je ne suis pas sûr que la connaissance du frontal soit un problème car l'expérience utilisateur est tellement plus sur les utilisateurs, que c'est un état d'esprit tout à fait différent , loin de s'inquiéter des capacités des outils du développeur ou des limites techniques de l'environnement de développement.
Le résultat final (l'expérience utilisateur) s'améliore-t-il en conséquence? Je ne suis pas sûr que ce soit le cas. Est-ce que l'efficacité du processus du concept à l'achèvement est améliorée - définitivement .
La communication est importante.
La spécialisation est le fondement de notre économie moderne. Au temps jadis, un artiste devait mélanger ses propres peintures. Maintenant, ils peuvent les acheter dans le magasin dans n'importe quelle teinte (veuillez noter que je ne suis pas un artiste). Je pense que cette division est analogue - les développeurs front-end sont les mélangeurs de peinture pour le professionnel UX. Néanmoins, une bonne compréhension de vos outils est essentielle à tout professionnel.
Les professionnels de l'expérience utilisateur devraient développer une solide connaissance pratique des choses faciles et des choses difficiles à faire dans le cadre de leur choix. HTML/CSS, API MS Windows, Flash, peut-être même la console sont couramment utilisés. Parfois, un cadre est développé spécifiquement pour l'application, comme dans les jeux vidéo. Il est essentiel de savoir ce qui peut être accompli avec le cadre. À mesure que la compréhension du cadre grandit, la facilité de mise en œuvre augmente également.
Sur la question de la programmation à usage général en particulier; c'est une compétence précieuse - mais pas essentielle pour un professionnel UX. Étant donné que les champs se chevauchent encore quelque peu, ils ont aujourd'hui une plus grande importance qu'ils ne le seront à l'avenir, mais je ne pense pas que cela deviendra redondant de si tôt.
Du point de vue des utilisateurs, je peux voir que ce serait un avantage d'avoir un concepteur UX qui n'est pas un développeur frontal. De cette façon, lors de la conception d'une interface utilisateur, ils ne sont pas du tout influencés par les détails techniques. Si cette personne doit finalement coder la solution elle-même, chaque décision de conception impliquera d'équilibrer les besoins des utilisateurs avec la difficulté de la construction (et aussi avec les choses intéressantes qu'ils ont récemment vues qu'ils aimeraient essayer de construire: )).
Je parle d'expérience car je suis à la fois concepteur UX et développeur front-end.
Je pense qu'ils devraient avoir une solide compréhension des bases, tout comme un développeur front-end devrait avoir une solide compréhension des bases de l'UX.
Cela ne veut pas dire qu'il est nécessaire pour eux de pouvoir s'asseoir et coder toute l'interface, mais ils devraient pouvoir converser avec les développeurs dans leur propre langage (et vice-versa), et éventuellement jumeler un programme avec un développeur qui a du mal à faire fonctionner quelque chose comme prévu.
Techniquement, l'UX est une forme de conception. Dans le logiciel frontal, vous pouvez avoir plusieurs spécialisations: concepteur, développeur et architecte. UX se situe généralement dans la catégorie "concepteur" en mettant l'accent sur les dessins conceptuels, les diagrammes de flux de travail et d'autres créations "de haut niveau".
Les architectes et les développeurs en tirent parti, ainsi que d'autres actifs de conception, pour produire l'application.
Le développement de logiciels est largement dicté par les environnements. En d'autres termes, vous ne pouvez concevoir que ce dont le navigateur ou l'appareil est capable. Il est EXTRÊMEMENT utile si le concepteur UX est familier avec les contraintes techniques de CSS3, par exemple, donc d'une part il poussera pour des trucs sympas que CSS3 peut faire, mais d'autre part est conscient et travaillera autour de choses qui CSS3 ne peut pas.
D'après mon expérience, les meilleurs designers peuvent coder leurs designs, et vice-versa: les meilleurs codeurs ont un sens incroyable du design.
Bien qu'il soit possible d'avoir des personnes UX qui ne peuvent pas faire un coup de code, je m'y opposerais. Cherchez des gens qui peuvent construire ce dont ils rêvent - ou au moins savoir comment le construire.
Il y a deux angles:
- Si vous travaillez pour une organisation où vous devez porter plusieurs chapeaux, la capacité de coder tout en s'engageant dans des tâches UX standard peut en effet être pertinente.
- Étant un pratiquant à temps plein de l'UX depuis 2005, je n'ai jamais été obligé ou demandé de coder. Les sociétés étaient toutes bien structurées et bien établies dans leurs catégories d'activités respectives. Il y avait toujours des gens sur place qui avaient la responsabilité de coder, donc ce n'était jamais un sujet de préoccupation pour moi. En outre, ces mêmes personnes fournissent des informations sur les contraintes associées au code. Il n'était pas nécessaire pour moi de posséder une telle connaissance de première main.
En bref, étant donné que la véritable UX comprend une ou plusieurs méthodes, disciplines et livrables provenant de l'utilisabilité et de l'heuristique, de l'architecture de l'information, de la conception d'interaction et d'interface et/ou de la recherche UX, une personne vraiment engagée dans l'UX n'aura pas le temps de code. Encore une fois, travailler dans une entreprise telle qu'une start-up peut vous obliger à vous salir les mains. Le codage n'est cependant pas un élément central principal associé à une véritable pratique UX.
Tout dépend du contexte de l'organisation, du type et du cycle du projet, ainsi que d'autres facteurs.
À mon avis: Oui, les concepteurs qui ne savent pas coder diront que cette connaissance n'est pas nécessaire, tandis que le marché se vérifiera.
Les technologies, les cadres et les bibliothèques se développent si rapidement que la frontière entre la conception et le codage disparaît.
Cependant, si nous séparons les domaines de la conception et de la programmation frontale, nous pouvons voir les composants détaillés (animations dans l'interface utilisateur ou tests unitaires dans le frontend).
Ainsi, dans ce contexte, beaucoup dépend des besoins et des portées actuelles que le projet prend en charge ou devrait prendre en charge.
Une connaissance élémentaire du front-end est nécessaire, j'irais plus loin et donnerais aux concepteurs l'accès aux référentiels sur git, car la conception prend beaucoup moins de temps que le codage.
Le projet mensuel peut être mis en œuvre jusqu'à six mois (selon la complexité)
Ainsi, lorsque le système est déjà conçu et prêt pour la programmation, le concepteur pourrait à ce moment prendre en charge un véritable support de programmation (même en termes d'esthétique, sans parler de la communication avec l'API) au lieu de générer des clichés inutiles sur les portails de dribble.
Cela dépend beaucoup du cycle de vie du produit (je veux dire, lorsque le projet est déjà mature, la tâche de l'UX est de vérifier/tester les hypothèses avec les utilisateurs, donc dans cette phase, lorsque le système fonctionne déjà, la programmation ou la création d'architectures n'est pas plus longtemps que nécessaire comme au début.