Est-il crucial pour un concepteur UX de comprendre les principes et les concepts derrière la programmation orientée objet?
En tant que concepteur et parfois codeur moi-même, j'ai été exposé à l'idée et aux principes derrière la programmation orientée objet, et avoir une connaissance dans ce domaine aide certainement quand il s'agit de conceptualiser des écrans pour les applications logicielles proposées. Les développeurs obtiendraient immédiatement l'essentiel des écrans.
Je suis curieux de savoir si la connaissance d'un concepteur de OOP aurait un grand impact en ce qui concerne la conception de l'expérience utilisateur? Quel genre de scénarios serait-ce un facteur énorme dans l'efficacité d'un Y a-t-il des cas où il se trouve?
Non.
Ce sont deux emplois fondamentalement différents. Sauf dans le scénario où la conception UX est destinée à un produit dont l'objectif principal est OOP développement (par exemple un IDE).
Sinon, bien sûr, il n'y a aucun mal à connaître les "principes" de la POO. De plus, connaître un large éventail de choses différentes (y compris la POO) peut certainement vous aider à penser différemment. Mais il est tout aussi important de comprendre que OOP est juste une de nombreuses approches de programmation, il y en a d'autres (par exemple la programmation fonctionnelle). Mais pour atteindre un niveau où vos compétences sont réellement utiles dans un environnement de production, vous avez besoin de beaucoup de pratique/expérience en tant que programmeur.
D'un autre côté, il y a des designers qui, par leur intérêt personnel, apprennent la programmation et s'y perfectionnent. Mais c'est la même chose qu'un marketeur qui apprend la programmation et se perfectionne.
C'est un fantasme que certains gestionnaires d'embauche et de nombreux recruteurs ont tendance à avoir - qu'ils ont besoin d'embaucher des ingénieurs polyvalents pour tous les emplois. Habituellement, cela reflète un manque de compréhension du rôle pour lequel ils embauchent.
Les seules (rares) situations où cela est utile se trouvent dans des équipes de produits extrêmement petites et des startups barebones. Même dans ce cas, il est beaucoup plus pratique d'avoir un programmeur qui peut faire un travail de conception de base, que l'inverse (concepteur au clair de lune comme programmeur). Il est plus facile de demander à un programmeur de suivre un cours intensif sur la conception et de le faire effectuer un travail de conception de base, mais un cours intensif en programmation ne rendra pas vos compétences réellement utiles pour autre chose que la construction de jouets/prototypes simplistes.
"Les développeurs obtiendraient immédiatement l'essentiel des écrans." Ce n'est pas le travail du designer. Les produits sont conçus de telle sorte que les utilisateurs , et non les développeurs, obtiennent immédiatement l'essentiel des choses. Le client des concepteurs est l'utilisateur et non le développeur.
Comme exemple pratique, considérons Jony Ive, le légendaire designer ux/ui. Il est facile de vérifier qu'il n'est en aucun cas un développeur qualifié. On peut supposer que les cours de diplôme en design industriel sont destinés à préparer les gens à travailler en tant que designers. Il est facile de vérifier si les programmes de certains de ces cours incluent un vrai contenu POO/programmation (ils ne le font pas).
Voici un citation de Don Norman , le gars qui a inventé le terme ux
J'ai inventé le terme parce que je pensais que l'interface humaine et la convivialité étaient extrêmement bonnes. Je voulais couvrir tous les aspects de l'expérience de la personne avec le système, y compris les graphiques de conception industrielle, l'interface, l'interaction physique et le manuel. Depuis lors, le terme s'est largement répandu, à tel point qu'il commence à prendre tout son sens.
Peut-être pas tellement apprendre les principes, mais comprendre les principes de la programmation orientée objet ou l'équivalent aide à certains aspects de la conception UX.
La réponse courte serait NON (c'est-à-dire qu'elle n'est pas cruciale), mais la réponse longue serait OUI car en développant un processus qui vous aide à articuler la relation entre différentes entités au sein d'un processus métier ou d'un workflow, cela vous aide à établir des liens très forts entre les gens, les processus et la technologie.
Il existe des techniques communes à OOP telles que l'utilisation d'UML (Unified Modeling Language) pour documenter les acteurs (c.-à-d. Les utilisateurs), les processus et les couloirs de natation pour comprendre les différents rôles et responsabilités que les gens jouent au sein d'une entreprise. processus qui chevauche également BPMN (Business Process Modeling Notation) qui sont particulièrement utiles pour documenter les détails techniques qui peuvent être traduits en décisions de conception du côté de l'interface utilisateur des choses.
Il existe des concepts dans OOP tels que l'héritage (concernant la définition et l'instanciation des classes) qui peuvent aider à renforcer les idées de modularisation et d'amélioration progressive des actifs de conception pour vos systèmes de conception.
Bien sûr, il existe d'autres approches pour OOP pour vous aider à conceptualiser et documenter les informations et les exigences de manière structurée, mais parce que UML et BPMN sont si répandus dans les cercles d'analystes commerciaux et de développement de logiciels ( et parce que la conception UX n'a pas vraiment sa propre méthodologie standard pour cela), il vaut vraiment la peine d'investir du temps pour au moins comprendre les principes de base.
Je suis développeur web et sacrément bon dans ce que je fais. J'ai une fois demandé à une entreprise d'ingénierie mécanique de reconstruire leur site Web moche qui a été initialement créé par un ingénieur en mécanique à temps partiel. Pour obtenir le poste, j'ai dû passer un test mécanique. La plupart des choses du test dont je n'avais jamais entendu parler auparavant et encore moins savaient comment répondre. (Il a principalement été testé sur l'hydraulique, le pliage de métal, etc.)
La réussite de ce test améliorerait-elle le fonctionnement de leur site Web? Non.
La programmation orientée objet est l'informatique et la compétence des programmeurs et non des concepteurs d'interface utilisateur.
Cette idée aujourd'hui que tout le monde a besoin de connaître la programmation est folle.
En tant que quelqu'un qui travaille en tant que concepteur et qui connaît OOP langues, je pense que certaines des philosophies de OO aident un peu à comprendre la structure, en particulier si vous obtenez dans SCSS et modulariser votre conception pour créer des morceaux de contenu réutilisables. Mais ce n'est pas vraiment OO, mais une meilleure compréhension des variables et des concepts de programmation de base (comme le garder au sec).
Dans l'ensemble, cela dépend de votre rôle en tant que concepteur, mais je pense que les défis auxquels vous êtes confronté dans OOP comme Dependency Inversion et SOLID ne chevauchent pas vraiment vos capacités) pour bien faire UX.
Wow, un fil satisfaisant. Il y a souvent un débat dans la société moderne - un concepteur devrait-il être capable de programmer?
Personnellement, je pense que la connaissance des modèles ou concepts de programmation (POO) est nécessaire pour devenir un designer de haut niveau.
Pourquoi est-ce que je pense que oui?
Vous pouvez modéliser la base de données en coopération avec un développeur principal. (Création de modèles)
Le processus de conception est différent, sachant que l'interface sera programmée, l'attention est accordée à l'ensemble du processus, et pas seulement jusqu'à ce qu'il soit passé pour la mise en œuvre avec le "faire face à vous-même ...
- La coopération avec un développeur front-end est un plaisir quand elle affecte les solutions finales, et vous pouvez lui fournir des exemples d'animations sur Codepen.
- La programmation aide à créer des systèmes évolutifs, en plus de voir qu'une photo n'est qu'une chaîne de bits, selon ce que l'utilisateur fournit, pas une grande photographie esthétique.
Cela dépend de l'ampleur et de la phase du projet, mais il y a toujours un problème de spécialisation.
Cependant, il semble problématique que les entreprises traitent souvent la conception d'interface utilisateur comme un outil de vente - et plus tard, il y a généralement des coûts de mise en œuvre/des scénarios imprévus.
Comme l'a dit Michael, le vrai design commence sur UML + BPMN.
Je ne suis pas d'accord avec les réponses, en particulier avec celui qui a le plus de votes. C'est 2019 à l'extérieur et l'industrie est suffisamment développée pour brouiller les frontières entre les rôles.
En bref, UX Designer + Programmer = UX Engineer
ne description du rôle de Google Jobs:
En tant qu'ingénieur UX, vous associez une esthétique de conception solide à un savoir-faire technique.
Vous travaillerez en partenariat avec des chercheurs et des concepteurs pour définir et proposer de nouvelles fonctionnalités, traduire des concepts en prototypes vivants et respirants, et répéter les interactions, les animations et les détails pour offrir l'expérience parfaite. Les ingénieurs UX collaborent également étroitement avec les chercheurs UX pour tester de nouveaux concepts et aider l'ingénierie.
Parce que l'ingénieur UX est à l'aise avec la mise en œuvre réelle, il a des informations encore plus approfondies sur l'expérience utilisateur et l'interaction utilisateur. Il peaufine les plus petits paramètres qui distinguent la grande expérience de la bonne expérience. Il est également un innovateur car il connaît les contraintes et cherche des moyens de les dépasser. La réponse devrait donc être définitivement OUI, sachant que la programmation a un impact énorme sur votre efficacité, votre produit et votre salaire;)
Pour en savoir plus sur le sujet: Qui est un "ingénieur UX"? Par Alex Ewerlöf
Une chose que j'ajouterais à cette conversation est que les concepteurs UX devraient également comprendre comment une page Web est également balisée. Trop de concepteurs ne réalisent pas que les divs sont des conteneurs, que l'on peut déplacer des conteneurs mais on ne peut pas facilement les séparer. Ce manque de compréhension survient souvent lors de la discussion des requêtes des médias et des points d'arrêt.
Prenons l'exemple d'un site à trois colonnes avec du contenu dans chaque colonne. En supposant que chaque colonne est son propre conteneur, les concepteurs UX DEVRAIENT savoir que l'on ne peut pas séparer le contenu dans chacune des colonnes et le placer ailleurs.
Je ne peux pas vous dire combien de temps et d'énergie sont gaspillés pour des conceptions qui ne peuvent pas fonctionner pour cette seule raison.
D'autres réponses ont essentiellement dit "non, mais il n'y a aucun mal à le savoir". Je voudrais contester cela et suggérer que non seulement les concepteurs UX n'ont pas besoin de connaître les principes OOP, mais ils ne devraient pas faire la conception UX du point de vue d'avoir été fraîchement exposé à OOP principes ou infatués à long terme avec eux. La conception UX n'a rien à voir avec la POO, mais il est facile de faire une mauvaise conception UX sur la façon dont l'ordinateur/le programmeur organise les données plutôt que sur ce qui est significatif pour les utilisateurs du système Cela peut être trouvé dans toutes sortes d'applications de bureau et Web réalisées par des concepteurs UX ou des programmeurs UX inexpérimentés sans expérience en conception UX, où l'interface utilisateur finit par n'être qu'une mince enveloppe autour d'une base de données et il est douloureusement évident que c'est ce que c'est.