Avons-nous une taxonomie des exigences UX pour les produits logiciels?
Je suis chercheur en UX. Mon objectif de recherche est d'aider les praticiens du génie logiciel à un stade précoce, c'est-à-dire l'ingénierie des exigences, à gérer les exigences UX même si leurs connaissances sur l'UX et l'ID sont faibles. Vous savez que toutes les sociétés de développement n'ont pas accès à des experts en UX et en ergonomie.
Jusqu'à présent, j'ai réalisé qu'un défi pour les praticiens est qu'ils ne savent pas quels types d'exigences UX sont considérés comme pertinents pour divers logiciels. Donc, je vise à développer (ou si c'est déjà là, à réutiliser) une ontologie ou une taxonomie des exigences UX dans mes recherches. L'étape suivante consiste à fournir des outils/méthodes sur la façon de susciter ces exigences et de les documenter/les représenter.
Connaissez-vous une source connexe? Dans quelle liste ou catégorie d'exigences UX tangibles peut-on trouver?
Le résultat de mes recherches va être publié gratuitement pour tout le monde en temps voulu.
La section des exigences de la page de wikipedia sur la conception de l'interface utilisateur est un bon début. Elle se réfère à l'ISO 9241, en particulier à la partie 10 qui a été retirée et remplacée par ISO 9241-110: 2006†
Il y a les principes UX que mozilla utilise comme mots-clés pour baliser les bogues dans bugzilla qui sont basés sur Jakob Nielsen Dix heuristiques d'utilisabilité .
J'ai récemment essayé de mapper les mots clés mozilla aux principes Dialogue/Feel de l'ISO 9241 pour voir comment ils correspondaient:
- Aptitude à la tâche
- ux-efficacité
- ux-implementation-level
- ux-jargon
- Auto-descriptivité
- ux-accessance
- ux-discovery
- ux-visual-hierarchy
- ux-minimalisme
- ux-userfeedback
- ux-tone
- Contrôlabilité
- ux-control
- ux-undo
- ux-interruption
- ux-control
- Conformité aux attentes des utilisateurs
- ux-cohérence
- ux-mode-error (cas particulier de la prévention des erreurs ux)
- ux-natural-mapping
- Tolérance aux erreurs
- ux-error-prevention
- ux-error-recovery
- Aptitude à l'individualisation
- Aptitude à l'apprentissage
Je mettrai à jour les définitions à un moment donné.
Mise à jour : Voir aussi Heuristique d'utilisation psychologique
† ISO 9241-110: 2006 est une page de 22 pages PDF coûtant 108 francs suisses, ~ 110 USD ou 70 GBP. Je serais intéressé à entendre toute personne qui l'a lu pour savoir si elle vaut l'achat.
Je suis également développeur de profession (et j'ai un MSc en génie logiciel d'une université durement connue), mais aujourd'hui je fais de l'UX. Ce qui suit vient du point de vue HCI de l'UX, c'est ce qui m'a été enseigné, c'est l'école à laquelle je me considère comme appartenant.
En général, UX n'est pas loin de l'informatique: ce que les développeurs apprennent à l'ingénierie logicielle comme "conception de logiciels" et ce qu'était UML, c'est essentiellement ce que fait UX aujourd'hui. La conception de logiciels est sortie du courant dominant à la fin des années 90, au début des années 2000, avec le boom Agile (j'étais là, je sais), donc il est difficile de trouver des gens qui - s'entraînent it , mais la plupart d'entre eux en ont entendu parler à l'université.
UX est un amoureux du génie logiciel et de la psychologie
Mettons cela en perspective, pour lequel je vais dessiner un schéma simple:
Je suis sûr qu'il y a beaucoup plus de choses, mais cela suffit pour une illustration rapide.
Le quartier "micro-informatique" n'est pas vide, c'est juste quelque chose qui ne doit être expliqué à aucun développeur frontend dans le monde.
Croyez-le ou non, par exemple, les taxonomies sont également une étude obligatoire dans toutes les universités informatiques, et elles sont utilisées tous les jours dans la programmation orientée objet. Il n'y a donc rien de nouveau là-bas.
Comprendre le développeur: le langage commun
Pour un développeur, je commencerais par des choses familières, comme les organigrammes. J'ai expliqué la relation entre les organigrammes et les soi-disant machines à états finis (encore une fois, une étude requise) dans une autre réponse à Programmers.SE
Pour comprendre ce qu'un développeur a appris, pensez à lire un livre UML, comme celui-ci , (surnommé le "livre iconix").
Quant à l'analyse des cas d'utilisation, qui traite en général de la manière dont un système doit se comporter, le meilleur livre est toujours celui de Cockburn Rédaction de cas d'utilisation efficaces
Les programmeurs aiment catégoriser, et la plupart d'entre eux aiment "lego", Design Patterns sont un bon endroit pour commencer. Les modèles de conception sont originaires de l'architecture, puis sont passés à l'informatique et sont passés de l'informatique à l'UX. De nos jours, les modèles de conception sont encore largement utilisés en informatique, mais pas aussi répandus qu'il y a 10 ans.
Orientation: buts et pourquoi
Il est important pour chaque partie de comprendre l'orientation vers les objectifs : les programmeurs travaillent généralement plus efficacement s'ils comprennent l'objectif que l'utilisateur souhaite avoir. Nous parlons tellement de "il doit y avoir ce bouton et cette ombre et cette transition", qui n'ont pas de sens pour un développeur, si vous ne leur dites pas pourquoi.
Je pense que c'est aussi un problème dans UX parfois, beaucoup de "bibliothèques de modèles" se concentrent sur le facteur de brillance, plutôt que sur les objectifs et les problèmes. Un modèle doit toujours être un modèle de problème et doit toujours contenir l'explication de la raison pour laquelle la solution recommandée fonctionne pour ce problème.
Soutenez vos objectifs déclarés avec des recherches d'utilisateurs ou des articles scientifiques. Peut-être leur donner des démonstrations en direct ou des statistiques de la propre recherche du projet. Sinon, l'objectif ne sera pas authentique et vous ne serez pas respecté par les développeurs.
J'ai essayé de faire mes UX en termes d'objectifs et de problèmes, et de modèles: pour chaque étape, il y a un problème à résoudre.
Voici à quoi ressemble également la programmation éducation éducation: ils vous présentent un problème, puis attendent quelques minutes, puis commencent à avoir une solution à grande échelle, puis ils disent: "ça va, mais = ", puis ils approfondissent les détails jusqu'à ce qu'une solution complète soit trouvée.
Quantifier, quantifier, quantifier
Les programmeurs comprennent les chiffres. Si vous leur dites qu'il est crucial qu'un feedback arrive dans les 1000 ms, ils peuvent écrire un test automatisé pour vérifier si c'est le cas. Les tests automatisés sont en plein essor de nos jours, et c'est quelque chose qu'ils peuvent demander à un ordinateur de tester.
Si vous leur dites qu'il est crucial d'avoir une réponse en 1000 ms, ils travailleront vers cet objectif. Si vous leur dites que quelque chose doit mesurer au moins 1 cm de long à l'écran, ils travailleront vers cet objectif.
Mais il est toujours important de leur donner des raisons. Les développeurs ne sont pas stupides et ils détestent être traités comme tels, en particulier par la communauté UX.
Pour les facteurs humains, fournissez des livres de cuisine
Il est vrai que le programmeur stéréotypé n'est pas bon pour comprendre les gens. Cela vient de la corrélation entre l'affinité de traiter avec des ordinateurs plutôt qu'avec d'autres personnes et de s'inscrire pour travailler en tant que développeur.
Ils ne comprendront pas vraiment, par exemple, que les humains sont mauvais pour se souvenir des choses (se souvenir ou se souvenir), car la plupart d'entre eux sont vraiment bons dans ce domaine (c'est nécessaire pour leur travail).
Mais si vous avez un bon livre de cuisine (10 commandements, listes de contrôle à puces), qu'ils peuvent croiser à la fin de la journée, avec des explications, cela pourrait fonctionner.
C'est ce que font les balises bugzilla souvent citées ici, elles donnent la règle générale aux développeurs. Dire qu'il y a un bug "ux-undo" dit au développeur, "oh oui, il y a une règle de base selon laquelle tout devrait être facile à rétablir".
Un bon livre en est celui de Weinschenk 100 choses
Acceptez que les programmeurs soient occupés et enchantés par la technologie
Les guerres de flamme des programmeurs concernent la technologie: vous pourriez être surpris de savoir à quel point cela n'a pas d'importance à la fin, quelle technologie utilisez-vous, mais combien de leur temps libre (et, ehm, le temps de travail, en fait) va se disputer sur lequel est le meilleur. Ils se disputent même entre les pommes et les oranges, et ils se disputent si c'est deux pommes ou une Apple et une orange.
Ils ont également mis chaque chose brillante qu'ils trouvent sur un site Web, pensant que c'est "ergonomique". Cela est particulièrement vrai pour les interactions brillantes.
Si quelque chose n'est pas bien pris en charge par leur technologie actuelle (comme, un certain widget ne se trouve pas dans la bibliothèque de widgets du système), là, le concepteur UX doit investir du temps et des efforts pour comprendre si la barrière technologique est réelle ou ne pas.
Pour résumer
J'avais trois objectifs avec ce texte:
- Fournir un aperçu général de ce que la plupart des développeurs savent déjà
- Fournir un point de départ général sur la manière de classer une grande taxonomie
Pour avoir une référence que quelqu'un pourra lier plus tard dans les discussions UX-vs-Devs, pas seulement les balises bugzilla bien connues
-
Les mêmes règles de base s'appliquent que pour les sites Web.
Ce sont aussi les mêmes règles de base qui s'appliquent aux "directives d'interface" qui sont publiées pour les systèmes d'exploitation (par exemple les Microsoft & Apple Interface Guidelines).
Fondamentalement, les interfaces doivent être construites autour de l'élément "humain" - et cela reste bien sûr le même, quelle que soit l'interface réelle.
Les concepts de base sont traités dans les 3 premiers chapitres de Apple Human Interface Guidelines . (prend un certain temps pour charger)
Je pense que le défi est qu'il n'y a pas un bon moyen de faire une référence simple pour ce genre de chose. La meilleure façon d'aider pourrait être de leur apprendre à rassembler leurs propres besoins (l'un d'eux apprend à quelqu'un à pêcher et à les nourrir pour toujours). Jakob Nielsen a une grande article sur les utilisateurs interviewés . Combinez cela avec un simple examen de certains sites/applications similaires/concurrents et vous devriez avoir une bonne base pour commencer le travail UI/ID. Il s'agit d'un processus qui ajouterait de la valeur à votre présence (un expert de l'interface utilisateur) mais leur enseignerait tout de même certains principes fondamentaux à utiliser après votre départ.
Question très intéressante.
Je suppose que vous cherchez une réponse qui va au-delà:
- Demandez les données démographiques de l'utilisateur.
- Découvrez le contexte de l'utilisateur. (emplacement, environnement, facteurs socio-économiques, etc.: regardez les modèles de travail dans la conception contextuelle par Holtzblatt et Beyer.)
L'intérêt de la recherche initiale des utilisateurs est de comprendre le domaine et d'essayer de trouver les problèmes/pannes dans le système. Ce n'est qu'après cela que des questions plus spécifiques liées aux exigences pourront être posées. Ce que les ingénieurs logiciels obtiennent généralement (ou sont censés obtenir) en termes d'exigences sont en fait des exigences fonctionnelles distillées (en utilisant une sorte d'analyse de données) à partir des données qui arrivent en tant qu'exigences du client/utilisateur.
Comme Andrew l'a dit ci-dessus, il n'y a pas de bon moyen de faire référence à cela. Cela s'explique en partie par le fait que différents projets se concentrent sur des choses différentes. Par exemple: voulez-vous une refonte complète? Ensuite, allez poser des questions systémiques plus fondamentales. Si vous souhaitez simplement changer l'apparence et laisser la logique métier tranquille, les questions à poser seraient plus superficielles.
Une autre raison pour laquelle il est difficile de compiler une référence est que divers projets logiciels se trouvent dans des domaines différents et que les questions à poser varient considérablement en fonction du domaine.
Je suis sûr qu'il existe plus de façons de regrouper les projets logiciels.
Cela dit, il peut être intéressant de regrouper différents types de projets, puis de poser des questions fondamentales qui seraient pertinentes.