SUS Scores et doutes
Mon équipe vient de commencer à utiliser le SUS pour comparer nos applications les unes aux autres. Il y a des doutes quant à la relation des questions avec les applications Web et les sites Web. Parfois, les participants à l'étude se moquent des questions ou Je ne sais pas comment y répondre de manière appropriée dans le contexte de l'étude à laquelle ils ont participé.
Quelques questions qui suscitent la confusion:
1. I think that I would like to use this system frequently.
Pour l'assurance automobile, les polices durent 6 mois, est-ce donc souvent une durée relative? Je ne vais pas entrer et obtenir un devis tous les jours, juste au moment où j'en ai besoin.
5. I found the various functions in this system were well integrated.
Comment cela se rapporte-t-il à un site Web qui a une tâche unique (c.-à-d. Obtenir un devis d'assurance automobile)?
10. I needed to learn a lot of things before I could get going with this system.
Cela signifie-t-il qu'ils devaient en apprendre beaucoup sur le système ou sur le produit (assurance automobile)?
Quelles ont été les autres expériences avec le SUS et comment les participants et les parties prenantes perçoivent les résultats?
En tant qu'auteur original de SUS, je vois beaucoup ce genre de requête. Je pense que vous devez faire un compromis ici, basé sur le fait que j'ai développé pour la première fois SUS il y a 25 ans lorsque je travaillais sur un programme d'ingénierie d'utilisation pour le développement de systèmes de bureau intégrés fonctionnant sous sur les VAX.
1) La terminologie peut ne pas sembler être particulièrement pertinente pour une technologie moderne spécifique (sites Web, téléphones mobiles, ce que vous avez) et les gens ont tendance à attribuer cela simplement au type de systèmes qu'elle a été initialement utilisée pour évaluer, et au fait qu'ils diffèrent des types de systèmes et d'applications utilisés aujourd'hui. À certains égards, cela n'a pas d'importance de toute façon, car les éléments individuels ne sont pas censés avoir un sens en eux-mêmes. Ils sont sélectionnés à partir d'un ensemble original et beaucoup plus important d'éléments, sur la base du fait qu'ils étaient les éléments qui, lorsqu'ils étaient présentés avec des exemples extrêmes de systèmes utilisables et inutilisables, étaient les questions qui ont conduit aux réponses les plus extrêmes, à la fois positives et négatives. (Ainsi, en théorie, des exemples de systèmes avec des caractéristiques d'utilisation moins extrêmes devraient conduire à des réponses plus intermédiaires). La somme totale de toutes ces questions conduit à une mesure générale de l'utilisabilité perçue. Vous pouvez donc être en désaccord avec le libellé des éléments individuels, mais ils ne sont pas censés avoir une valeur diagnostique en eux-mêmes ou se rapporter aux caractéristiques spécifiques d'un système particulier qui est destiné à être utilisé dans un but particulier. Si vous souhaitez ce type d'informations, vous devez rédiger un questionnaire qui traite de ces caractéristiques spécifiques. Toutefois.....
2) SUS a 25 ans et parce qu'il a été mis à disposition gratuitement a été récupéré et utilisé dans de nombreuses évaluations de l'utilisabilité. (Cheapskates! Mais je suis content que tant de gens ont l'ont trouvé utile. Par conséquent, il existe une mine d'informations sur son utilisation et un ensemble de données normatives. Il y a eu d'excellentes études sur sa fiabilité et la collecte de données normatives - en particulier Tullis a une excellente papier sur le premier aspect et Bangor et Kortum ont collecté des données sur l'utilisation du SUS sur plus d'une décennie.
Il me semble donc que vous avez le choix. Vous pouvez concevoir votre propre questionnaire, qui peut utiliser une terminologie appropriée à la technologie spécifique que vous évaluez. Il n'aura pas une masse d'expérience et de données provenant d'autres études auxquelles vous pourrez le comparer. Si tout ce que vous faites est de comparer une version d'un système ou d'une application basée sur une technologie particulière avec une version successive, c'est peut-être tout ce dont vous avez besoin. Mais supposons que vous vouliez comparer, disons, une application Web avec une application basée sur une technologie différente? Ensuite, vous commencerez à rencontrer les mêmes types de problèmes que vous percevez comme étant le cas avec SUS.
Je n'ai jamais prétendu SUS être un outil parfait. (Je l'ai fait dire dans le titre de la version publiée qu'il était "rapide et sale"). Mais Je pense que cela a fait ses preuves au fil des ans et les efforts de personnes comme Thomas Tullis et Phil Kortum (qui ont fait tout leur travail indépendamment de moi) ont fourni des preuves supplémentaires que c'est un outil à utiliser.
rgds
John Brooke
En général, SUS semble convenir aux sites Web. Tullis et Stetson l'a comparé à d'autres enquêtes sur l'utilisabilité pour évaluer un intranet d'entreprise et SUS a surpassé les autres.
Il semble que quelques éléments individuels peuvent ne pas s'appliquer à votre travail. Pour vérifier cela systématiquement, créez une matrice de corrélation des réponses de vos éléments et calculez alpha standardisé de Cronbach avec et sans les éléments problématiques. Si l'alpha est plus élevé sans l'élément qu'avec lui, il ne mesure apparemment pas la même construction psychologique sous-jacente que les autres éléments, et vous pouvez être justifié de le supprimer simplement (ou de le réécrire jusqu'à ce que les tests montrent qu'il améliore l'alpha).
Mais avant de le faire, considérez le contexte plus large dans lequel vous utiliserez l'échelle. L'évaluation de base implique que vous ferez des comparaisons avec des scores ultérieurs. Considérez que les éléments problématiques peuvent être parfaitement adaptés à d'autres sites/applications/versions que vous souhaitez comparer et capturer les facettes de la convivialité subjective que vous souhaitez avoir. Par exemple, dans cinq ans, votre application d'assurance comprendra plusieurs fonctions (par exemple, aider l'utilisateur à identifier si ses voitures présentent un risque élevé de vol). Les réponses à l'élément "diverses fonctions" sont peut-être partout, mais ce sont toujours des informations utiles qui valent la peine d'être incluses, de sorte que les scores sont comparables à une future version multifonction.
Personnellement, les éléments que vous avez sélectionnés peuvent sembler drôles, mais si j'étais moi-même utilisateur, je pense que je les interpréterais de manière utile. J'interpréterais "utiliser fréquemment" par rapport aux alternatives (par exemple, obtenir un devis par téléphone). J'interpréterais "bien intégré" comme la facilité avec laquelle je me déplace sur le site sans beaucoup de retours en arrière ou de saisie de données (par exemple, je peux spécifier ma voiture sans avoir à parcourir une multitude de pages). Ne pas avoir à "apprendre beaucoup" signifie que je peux saisir ma contribution et obtenir le devis sans beaucoup de travail de ma part. Oui, cela comprend à la fois l'apprentissage du système et le sujet: cela signifie que je peux comprendre la couleur que vous avez choisie pour vos liens, et vous avez fourni une explication claire sur ce que signifie la "franchise". Non, vous ne saurez pas si cela a été difficile de vous renseigner sur le système ou l'assurance qui a contribué à un faible score, si cela se produit, mais vous ne devriez pas de toute façon rechercher les scores des éléments individuels pour le diagnostic. SUS par conception ne mesure que une construction psychologique, pas plusieurs dimensions psychologiques.
Wow, John Brook apparaît. Cool! Oui, votre outil est toujours très utile et pertinent pour UX!
En ce qui concerne l'enquête, envisagez de lever l'ambiguïté en modifiant le terme "système" afin que l'enquête porte exactement sur le produit/la fonctionnalité/le service qui vous intéresse. En outre, l'intégration peut ne pas s'appliquer lors de l'obtention d'un devis, mais vous pouvez peut-être vous interroger sur l'intégration de cette fonctionnalité dans le système plus vaste.
En ce qui concerne les résultats perçus par les parties prenantes, la "convivialité perçue" est le complément parfait à une batterie de tests plus importante. Par exemple, un test A/B en direct peut comparer le nombre d'erreurs générées lors du paiement entre deux conceptions différentes. usabilitytesting.com peut être quelque chose que vous utilisez pour les prototypes et vous pouvez enregistrer # d'erreurs critiques comme indicateur de performance clé pour les fonctionnalités de développement/conception.
Si vous êtes la seule personne UX dans le personnel et que vous souhaitez proposer une stratégie holistique de test UX, certaines d'entre elles ne seront pas possibles sans aide, alors vous pouvez également les lier au nombre de têtes, aux fournisseurs ou impliquer d'autres services (marketing/recherche) dans le processus.
J'avoue d'emblée que je n'ai jamais utilisé le SUS. Pour la question # 2, cependant, est-ce important? Il est peu probable qu'un utilisateur fasse la distinction entre les deux, et si vous l'utilisez pour établir une référence entre les applications, ce que vous obtenez est une mesure subjective de la courbe d'apprentissage. Dans ce cas, je ne pense pas que vous puissiez séparer le système des informations qu'il présente.
Je suppose que vous observez les séances, et il me semble que pour au moins la moitié des questions de la liste, vous aurez besoin des données d'observation qualitatives pour comprendre les réponses extrêmes.
Même si votre site Web n'a qu'une seule fonction, il a probablement toutes sortes de contenus. Matériel de marketing, sur votre entreprise, plans de prix, conditions de service, etc. Si la seule fonction est toujours facilement trouvée parmi toutes ces choses, elle est bien intégrée. S'il est perdu dans la jungle d'autres contenus, il ne l'est pas. :) Je pense que vos utilisateurs comprendront cette distinction et réagiront de manière appropriée.
M. Brooke, j'ai souvent utilisé le SUS et je le recommande toujours à ma classe des facteurs humains.