La transition de Noah vers les tests d'utilisabilité mobile

Noé était inquiet. Il était le "type UX" pour le siège social d'un restaurant régional à service rapide (une chaîne de restauration rapide) qui était en train de créer une application mobile pour permettre aux clients de personnaliser leurs repas, de passer des commandes et de gagner des récompenses.

Il avait remarqué que les attentes des utilisateurs augmentaient et qu'ils pardonnaient moins les mauvaises expériences mobiles. C'est pourquoi Noah croyait fermement qu'il était important de tester la convivialité de l'expérience utilisateur mobile compte tenu des attentes plus élevées des utilisateurs, des écrans plus petits et des contraintes des appareils sans fil alimentés par batterie. Mais Noah était inquiet car il n'avait jamais effectué de test d'utilisabilité mobile, même avec des années d'expérience en tests d'utilisabilité traditionnels. Cela, et le fait que la première série de tests n'était qu'à un mois.

Il s'est rapidement rendu compte que les tests d'utilisabilité mobiles présentaient plus de similitudes avec les tests d'utilisabilité de bureau traditionnels que de différences . Les plus grandes différences résidaient dans les tests eux-mêmes ; tout ce qui a précédé le test réel et après le test est resté le même. De nombreuses options étaient disponibles pour effectuer des tests d'utilisabilité, y compris modérés ou non modérés, à distance ou en personne et des combinaisons de ceux-ci. Bien que les tests à distance non modérés lui aient permis de jeter un filet plus large avec beaucoup plus de participants, ils n'ont pas offert d'opportunités de sondage contextuel.

Alors qu'il recherchait les options disponibles, Noah a marqué des services comme UserZoom et UserTesting comme options potentielles pour les futurs besoins de test à distance. Son expérience passée lui avait appris que les tests en personne modérés fournissaient des informations utilisateur riches qui étaient souvent manquées par d'autres méthodes. Cela lui permettrait de se concentrer sur certaines caractéristiques et fonctionnalités avec quelques participants, ainsi que sur les concepts de sonde qu'ils exploraient, ce qui en ferait son approche préférée pour leurs prochaines séries de tests.

Un mois avant le premier test d'utilisabilité prévu, il a commencé à se préparer pour les tests, en commençant par les pièces qu'il connaissait le mieux. Suivons Noah alors qu'il effectue la transition des tests d'utilisabilité de bureau vers le mobile.

Un mois avant

L'équipe de conception et de développement s'est lentement rendue à la réunion d'après-déjeuner que Noah avait prévue, quelques-uns tentés par les bouchées de brownie qu'il avait promises. Il a profité de la réunion pour examiner les fonctionnalités et les caractéristiques qui devaient être testées lors de la première session de test d'utilisabilité. Comme ils étaient actuellement en phase de conception, ils effectueraient des tests d'utilisabilité à l'aide d'un prototype de l'application iOS.

L'équipe venait de terminer des conceptions d'écran approximatives et commençait tout juste à créer un prototype interactif haute fidélité qui permettrait aux utilisateurs d'effectuer des tâches comme s'il s'agissait d'une application ou d'un site en direct. Le responsable de la conception s'est servi de la dernière (et de sa troisième) bouchée de brownie en promettant que le prototype de l'application serait prêt une semaine complète avant le premier test d'utilisabilité. Noah a défini un rappel pour cette date sur son téléphone.

Trois semaines avant

La semaine suivante, Noah a commencé la première étape cruciale de la création d'un plan de test d'utilisabilité qui documentait le quoi, pourquoi, quand, où, qui et comment du test d'utilisabilité. L'expérience passée lui avait appris l'importance de faire approuver les détails du plan par les principales parties prenantes et les membres de l'équipe de projet. Cela garantissait que le test d'utilisabilité testait les bonnes caractéristiques et fonctionnalités, avec le bon public représentatif sur les appareils appropriés, et que les bonnes mesures étaient collectées et rapportées. En plus du plan de test, il a également préparé les autres documents qui seraient nécessaires pour les tests, y compris une non-divulgation, un reçu d'indemnisation et des formulaires de décharge.

Noah savait qu'il était tout aussi important pour un test d'utilisabilité réussi de trouver les bons participants, car une taille unique ne convient pas à tous. Comme par le passé, Noah a utilisé des personnalités de projet pour identifier les profils des participants qu'il utiliserait pour les tests. Il s'est tourné vers son cabinet d'études de marché habituel pour créer un filtre afin de recruter les bons participants à partir de leur panel d'opinion. Puisqu'ils construisaient une application iOS, le filtre comprenait également des questions pour s'assurer que les participants utilisaient des iPhones exécutant iOS 7 ou une version ultérieure, afin de s'assurer qu'ils seraient familiarisés avec les conventions de la plate-forme et le design plat.

Il avait encore besoin d'aide pour déterminer les options de configuration et d'enregistrement des tests. Fan de "Qui veut gagner des millions", Noah a utilisé l'équivalent de la bouée de sauvetage Ask the Audience pour solliciter les commentaires de quelques groupes LinkedIn UX sur les options de configuration pour les tests d'utilisabilité mobiles modérés en personne. Fervent partisan du partage des connaissances, il a également promis de compiler et de partager la sagesse collective avec ces groupes.

Deux semaines avant

Les requêtes de Noah sur LinkedIn et Quora ont lentement commencé à recevoir des réponses, mais de nombreuses réponses provenaient également d'autres personnes à la recherche de réponses. Il a commencé à couper et à collecter des approches utiles dans Evernote au fur et à mesure qu'il était informé des nouvelles réponses.

Noah a envoyé un e-mail à Pat, son contact à l'agence de recrutement, pour une mise à jour du statut et a obtenu une réponse dans l'heure. Ils avaient presque fini de recruter pour ce tour, avec cinq des sept emplacements remplis correspondant aux profils de personnalité, ainsi que trois flotteurs au cas où il y aurait des non-présentations. L'équipe de Pat attendait de recevoir les confirmations de leur panel pour les deux créneaux restants. Elle a promis d'envoyer les résumés des profils des participants d'ici la fin de la semaine. Pleinement conscient que son service de comptabilité était bureaucratique, il a soumis une demande de cartes-cadeaux à utiliser pour rémunérer les participants pour leur temps.

Puisqu'il allait effectuer des tests d'utilisabilité en personne, il devait identifier un emplacement approprié. Noah avait effectué sa part de tests dans des laboratoires d'utilisabilité formels, mais il ne pensait pas que cela était nécessaire pour ces tests. Il a exploré le bureau de l'entreprise pour trouver des pièces qu'il pourrait utiliser - une pour les tests, une autre comme salle d'attente pour les participants et une troisième comme salle de débriefing pour l'équipe. Il a trouvé une pièce calme sans fenêtre au milieu du bâtiment pour le test d'utilisabilité et deux autres avec de belles vues extérieures et les a rapidement réservées pour les tests.

Son objectif le plus important pour la semaine était de terminer l'examen du plan de test par les parties prenantes. Il avait envoyé le plan par e-mail aux parties prenantes du projet, notamment le marketing, l'informatique et la conception créative, deux jours avant leur réunion habituelle du jeudi matin. Il leur avait demandé de venir préparés avec leurs commentaires, en particulier autour des tâches à tester. L'équipe créative avait quelques ajustements pour les tâches et l'informatique n'en avait pas, mais Chad du marketing l'avait passé au peigne fin ; ses commentaires comprenaient l'ajout de quelques tâches supplémentaires et des questions de suivi détaillées pour tout, de la stratégie de marque à l'étiquetage. Noah a expliqué qu'ils ne pouvaient pas accomplir plus de quatre tâches principales dans leur test d'une heure et ont travaillé en tête-à-tête avec Chad le reste de la matinée pour finaliser les tâches du plan de test.

Une fois les tâches approuvées, Noah s'est concentré sur ses options d'enregistrement des sessions de test d'utilisabilité. Il disposait de nombreuses options pour enregistrer l'écran ainsi que les réactions des participants lors de l'utilisation d'un ordinateur, grâce aux webcams intégrées et au logiciel d'enregistrement d'écran. Cependant, l'enregistrement d'une session d'utilisabilité mobile était compliqué car la plupart des façons de capturer des enregistrements similaires pouvaient être gênantes et avoir un impact sur le test d'utilisabilité. C'est là qu'il espérait que sa bouée de sauvetage Ask the Audience l'aiderait; il a organisé la douzaine de réponses et elles ont toutes convergé sur quatre façons d'enregistrer une session d'utilisabilité mobile. Se souvenant de son offre de compiler et de partager ses découvertes avec les autres membres des groupes, Noah a commencé à documenter les options.

Juste au moment où il partageait ses découvertes dans les groupes LinkedIn, le téléphone de Noah sonna pour lui rappeler son rendez-vous du vendredi soir avec sa femme dans une heure - le temps avait filé ! Il a rapidement mis son ordinateur en mode hibernation et est rentré chez lui pour le week-end. Cette semaine a été longue mais fructueuse.

Une semaine avant

Noah avait réfléchi à ses options au cours du week-end et se penchait vers la dernière option - utiliser une application comme UX Recorder pour enregistrer le test, sans aucun équipement supplémentaire. De retour au travail, l'équipe du projet a accepté son choix, mais le directeur UX lui a demandé de le valider avec un spécialiste de l'utilisabilité de leur Meetup UX local. Noah a organisé un déjeuner de travail le lendemain avec la spécialiste, Diane, qui effectuait des tests d'utilisabilité mobile depuis deux ans.

Alors qu'il travaillait sur son arriéré d'e-mails du week-end, il a vu la liste complète des profils des participants de l'agence de recrutement. Il scanna les profils, confirmant mentalement qu'il avait reçu la répartition exacte du profil de personne qu'il recherchait. Cependant, le profil d'un participant ne semblait pas correspondre à sa personnalité, avec des caractéristiques telles que le revenu ne correspondant pas à la fourchette attendue pour cette personnalité. Il a envoyé un courriel à Pat à l'agence pour trouver un remplaçant pour ce participant.

Le lendemain, il a rencontré Diane dans l'un de leurs restaurants, pour ce qui ressemblait à une bouée de sauvetage Ask An Expert . Il était venu préparé avec une liste de sujets dont il voulait discuter et une impression de son plan de test, ainsi que les options de configuration d'enregistrement. Il avait rencontré Diane pour la première fois lors de leur UX Meetup local il y a plus d'un an - elle était un comité d'accueil autoproclamé d'une seule personne et l'a rapidement mis à l'aise dans le groupe d'environ 70 UXers.

Pendant qu'ils faisaient la queue pour passer leurs commandes, Diane a parlé du test d'utilisabilité qu'elle venait de terminer, y compris la gentille grand-mère qui hésitait à accepter une compensation. Alors qu'ils attendaient à leur table pour leurs repas, il a expliqué qu'ils prévoyaient de mener des tests d'utilisabilité modérés en personne à l'aide d'un prototype de leur application iOS, et il espérait ses conseils sur son choix d'enregistrer le test. Elle avait utilisé toutes ces approches dans le passé et après lui avoir posé quelques questions supplémentaires sur le test, elle a validé son choix.

Au cours du repas, il lui a demandé des suggestions sur la prise en compte du contexte mobile (comme l'environnement et les circonstances d'utilisation qui affectent l'interaction entre l'utilisateur et l'interface). Elle a expliqué que dans un environnement de laboratoire, la meilleure option était de simuler ce contexte. Elle a immédiatement rappelé l'une de ses tâches consistant à passer une commande de restauration rapide et à la récupérer, et a déclaré qu'elle allait d'abord s'enquérir de leurs attentes en matière de ramassage de commande. Elle présenterait ensuite le concept de la façon dont ils envisageaient d'utiliser le géorepérage pour commencer à préparer leur commande et essaierait d'obtenir les commentaires des participants sur le concept. Elle a promis de lui envoyer par e-mail quelques indications supplémentaires avant la fin de la journée. Il a remercié Diane pour ses conseils alors qu'ils quittaient le restaurant.

Vers la fin du déjeuner, son téléphone lui avait rappelé que l'équipe de conception avait promis de terminer le prototype d'ici aujourd'hui. De retour au bureau, il se dirigea vers la salle de l'équipe de conception pour découvrir le prototype. Le responsable de la conception a expliqué en s'excusant qu'ils avaient dû repenser certaines de leurs conceptions en fonction de directives de dernière minute du marketing. Il a dit qu'ils visaient à ce que tout soit terminé d'ici le week-end. C'était trop serré pour le confort de Noah, car il effectuait généralement un essai à vide quelques jours avant le test, donnant à l'équipe le temps de faire les ajustements de dernière minute. Il a essayé de se changer les idées en mettant à jour la tâche de placement et de ramassage des commandes pour simuler le contexte en fonction de la suggestion de Diane.

Alors qu'il faisait des mises à jour, il a reçu l'e-mail de Diane avec quelques indications.

Objet : Pointeurs de test mobile

Noah, comme promis pendant le déjeuner, voici quelques conseils à garder à l'esprit lors de la configuration et de la conduite de vos tests la semaine prochaine.

Merci pour le déjeuner et tout le meilleur!

Diane

---

Appareils/Plateformes : Si les participants n'utilisent pas leurs propres appareils, assurez-vous qu'ils testent sur la plate-forme (iOS, Android ou Windows) qu'ils connaissent et utilisent régulièrement. S'ils utiliseront leurs propres appareils, tenez compte de la logistique et du temps nécessaires pour installer l'application, configurer tout accès, etc.

Éblouissement : avec les ordinateurs, vous pouvez ajuster votre écran pour tenir compte de tout problème d'éclairage, mais l'éblouissement devient un problème avec le mobile, lorsque vous utilisez une caméra pour enregistrer des écrans mobiles (les deux premières approches que vous avez décrites) car les utilisateurs ont tendance à déplacer les appareils mobiles. pour une utilisation plus confortable, rendant parfois inutiles certaines parties de l'enregistrement. Si jamais vous utilisez la configuration de la caméra de documents (première approche), utilisez du ruban adhésif pour rappeler aux utilisateurs la zone dans laquelle l'appareil mobile doit rester.

Batterie/Alimentation : Un autre problème uniquement mobile est de s'assurer que les appareils utilisés ont suffisamment de jus pour le test, et que de longs câbles de charge sont facilement disponibles. La première fois que j'ai utilisé UX Recorder sur un appareil personnel pour un essai à vide, à mi-chemin du test, nous avons dû nous arrêter et nous débrouiller pour obtenir un câble de chargeur - l'écran, l'enregistrement vidéo et audio ont vidé la batterie plus rapidement que je ne l'aurais jamais imaginé.

Enfin et surtout:

Notifications/Alertes : Désactivez TOUTES les alertes et notifications sur les appareils de test. Non seulement cela interrompt le test, mais cela peut avoir un impact sur votre enregistrement.

Noah a pris note de les revérifier lors de la simulation, qui devait maintenant être reportée à la veille des tests réels. La semaine prochaine allait être une longue semaine pour lui…

La semaine des tests d'utilisabilité

Lundi matin, de bonne heure, Noah a apporté une Box O'Joe et des beignets pour l'équipe de conception, qui avait travaillé une partie du week-end pour terminer le prototype. Ils ont passé l'heure suivante à parcourir collectivement le prototype et à noter quelques modifications mineures. L'équipe de conception aurait terminé les mises à jour avant le déjeuner, ce qui donnerait suffisamment de temps à Noah avant le test pilote cet après-midi. Il a envoyé un e-mail de rappel à sa collègue, Emma, ​​qui s'était portée volontaire pour le test. Emma n'avait pas été impliquée dans l'application et, à l'exception d'être une fanatique de la marque en tant qu'employée, était une aussi bonne participante au test qu'elle pouvait l'espérer.

Il a commencé ses derniers préparatifs pour les tests en imprimant les documents requis, y compris les non-divulgations, les formulaires de décharge et les reçus d'indemnisation. Il a également acheté des crédits de test pour utiliser UX Recorder pour enregistrer le test pilote. Étant prudent, il avait également deux webcams prêtes avec des supports en guise de sauvegarde. Il a configuré les options d'enregistrement dans l'application, lancé le prototype via le navigateur de l'application et s'est enregistré en cliquant sur une tâche. Jusqu'ici tout va bien!

Noah et Sophie, le preneur de notes assigné pour les sessions, ont atteint la salle réservée aux tests d'utilisabilité 15 minutes avant le test, pour trouver Emma qui les attendait déjà. Alors que Noah s'installait, il expliqua ce qu'ils espéraient accomplir dans l'heure suivante. Cependant, il n'a pas pu afficher le prototype dans l'application d'enregistrement - il s'est rapidement rendu compte que son téléphone n'avait pas de signal cellulaire ou sans fil, probablement à cause de l'emplacement de la pièce au milieu du bâtiment. Il s'excusa et alla essayer les autres salles qu'il avait réservées comme salles d'attente et de débriefing.

Dans la première pièce qu'il a essayée, le prototype s'est chargé sans délai - son téléphone avait un signal cellulaire et Wi-Fi puissant. Il accompagna Emma et Sophie dans la nouvelle salle quelques minutes après l'heure de début initiale. Il a expliqué les règles de base et le processus avant de lancer l'enregistrement dans l'application. Quatre tâches et 70 minutes plus tard, il a arrêté l'enregistrement et a remercié Emma pour son aide. Pendant que l'application exportait l'enregistrement de la session d'une heure, Sophie et lui ont discuté de la session, identifié une tâche qu'ils devaient reformuler pour éviter toute confusion et cherché des domaines où ils pourraient réduire le temps des sessions réelles. C'est pourquoi il a toujours effectué au moins un essai à blanc avant les tests proprement dits. Cela l'a aidé à se familiariser avec les tâches en tant que modérateur, lui a permis de vérifier que les tâches étaient claires pour un étranger et de faire des ajustements de temps si nécessaire.

Le premier jour des tests d'utilisabilité a commencé mardi matin et Noah était de retour dans sa zone de confort en tant que modérateur. Les quatre tests programmés se sont bien déroulés, et Noah et Sophie ont utilisé le temps entre les tests pour débriefer et capturer les points saillants de la session sur le mur du tableau blanc. Le seul hic était que le téléphone a reçu un appel entrant lors de la troisième session ; il a demandé au participant de le rejeter et de continuer le test. Bien qu'il ait désactivé toutes les alertes et notifications comme Diane l'avait suggéré, l'appel a réussi à passer. Après les quatre tests programmés pour la journée, alors que les enregistrements de session étaient exportés, ils ont commencé à identifier les tendances préliminaires à partir des points saillants de la session sur le mur du tableau blanc. Les deux premières ont été rendues sans problème, mais la troisième session semblait corrompue et n'a pas pu être exportée. Heureusement, le dernier rendu sans problème. Il a envoyé un e-mail à l'équipe d'assistance de l'application avec les journaux de la vidéo corrompue, craignant que ce problème ne se reproduise le lendemain.

Le premier participant prévu mercredi était absent, ils ont donc effectué le test avec leur flotteur de secours. Après chaque test ce jour-là, Noah a redémarré l'iPhone dans l'espoir qu'il empêcherait tout autre enregistrement corrompu, car il n'avait pas eu de réponse de l'équipe de support de l'application. Il a poussé un soupir de soulagement lorsque les trois enregistrements de la journée se sont déroulés sans aucun problème. Sophie et lui ont passé le reste de l'après-midi à revoir toutes leurs notes et souvenirs, et à poursuivre leur analyse des tendances. En repensant aux tests, il a également noté qu'aucun des participants n'avait de problème avec le contexte mobile simulé, même s'ils ne pouvaient pas le tester dans le monde réel.

Noah a terminé la semaine par une réunion de débriefing avec l'équipe du projet pour partager les principales conclusions et a proposé d'organiser des sessions supplémentaires la semaine suivante.

La semaine d'après

Au cours du week-end, l'équipe de support de l'application d'enregistrement mobile a envoyé un e-mail à Noah, admettant qu'ils ne pouvaient pas comprendre pourquoi la troisième vidéo était corrompue, mais lui a envoyé des instructions étape par étape pour localiser et partager les clips vidéo bruts de l'iPhone. Ne se sentant pas très optimiste, il a compressé, téléchargé et partagé le fichier de 2 Go avec eux.

Alors qu'ils progressaient bien sur le rapport final du test d'utilisabilité, Noah a programmé un rapport avec les principales parties prenantes du projet et l'équipe du projet pour vendredi après-midi. Noah et Sophie ont passé le reste de la semaine à analyser les données, à mettre à jour les tendances et à documenter les principaux résultats ainsi que la gravité et les recommandations d'amélioration. Bien qu'il existe de nombreux modèles et formats pour rapporter les résultats, Noah aimait utiliser un format PowerPoint qu'il avait peaufiné au fil des ans, ce qui permettait un show-and-tell visuel. Il croyait fermement au pouvoir de courts clips vidéo (ou d'un montage) d'utilisateurs aux prises avec une certaine fonctionnalité pour créer un moment "A-ha" pour ceux qui ne faisaient pas partie des tests. Sophie a recadré les clips vidéo pour soutenir contextuellement quelques observations et recommandations clés.

Chaque jour pendant le déjeuner de cette semaine, Noah a dirigé une session de révision vidéo avec l'équipe du projet, passant en revue l'enregistrement vidéo d'un participant différent chaque jour. Cela a non seulement aidé l'équipe à constater de visu comment les utilisateurs interagissaient avec leur prototype d'application et où ils trébuchaient, mais a également révélé quelques observations et idées que Noah et Sophie n'avaient pas saisies.

La session sur le rapport final du vendredi après-midi a été bien suivie par toutes les parties prenantes clés. Noah a présenté les résultats de haut niveau et Sophie est entrée dans les détails. Ils ont répondu à quelques questions sur les observations et les recommandations qui étaient différentes de ce que le comité directeur avait initialement envisagé pour l'application. Comme Noah l'avait vu maintes et maintes fois, les clips vidéo à l'appui étaient suffisants pour que les parties prenantes s'assoient, prennent note et entament des conversations sur le changement de cap.

Alors qu'il rentrait chez lui pour le week-end, Noah a réfléchi aux six dernières semaines et à son premier test d'utilisabilité mobile - ses préoccupations au départ avaient été exagérées. Sa transition vers les tests d'utilisabilité mobiles avait été relativement facile, car il avait une expérience antérieure des tests d'utilisabilité traditionnels sur les ordinateurs de bureau. La configuration était la plus grande différence entre les deux, et il avait dû s'occuper de certaines nuances liées au mobile, mais ce n'était pas comme apprendre une toute nouvelle compétence.

Au cours des mois qui ont suivi, les tests d'utilisabilité continus de Noah ont aidé l'équipe du projet à affiner l'application au fur et à mesure qu'elle passait d'un prototype à un produit entièrement fonctionnel. Pour le lancement et chaque version majeure qui a suivi, l'application a reçu une majorité de critiques 4 et 5 étoiles.

TL; DR : Chronologie des activités

Un mois avant

• Travailler avec l'équipe de conception pour identifier ce qui peut être construit pour les tests et s'assurer qu'il sera prêt quelques jours avant le premier test

Trois semaines avant

• Identifier les profils des participants aux tests d'utilisabilité en fonction des personas
• Créer un filtre de recrutement
• Sélectionner et recruter des participants

Deux semaines avant

• Examiner le plan de test d'utilisabilité avec les parties prenantes et finaliser les tâches
• Identifier et réserver les salles nécessaires pour les tests
• Finaliser et programmer les participants et les participants flottants en attente
• Organiser des incitations pour les participants

Une semaine avant

• Parcourir les tâches à l'aide du prototype ou de l'application à tester
• Tester la configuration de l'enregistrement
• Effectuez une simulation de l'ensemble du test d'utilisabilité

La semaine des tests d'utilisabilité

• Imprimez tous les documents requis (plan de test, scripts, non-divulgations, formulaires de décharge, reçus de compensation)
• Vérifiez la configuration de la salle de test d'utilisabilité, y compris l'alimentation, la connectivité, l'éblouissement, etc.
• Réaliser des débriefings internes à la fin de chaque session et un bilan en fin de journée
• Identifier et documenter les tendances une fois les tests terminés

La semaine d'après

• Documenter les résultats dans le rapport d'utilisabilité
• Examiner les enregistrements vidéo avec l'équipe de projet
• Identifier et créer des clips vidéo à partir d'enregistrements pour soutenir les principales observations et recommandations
• Rapport sur les conclusions

Ressources et liens

Modèles de planification et configuration de l'enregistrement

• Planification d'un test d'utilisabilité
• Testeur de test d'utilisabilité - Test d'appareils mobiles
• Modèle de plan de test d'utilisabilité
• Un guide pour des tests d'utilisateurs mobiles simples et indolores

Listes de vérification des tests mobiles

• Liste de contrôle détaillée et autres téléchargements de Rocket Surgery Made Easy de Steve Krug
• UserTesting Mobile Usability Testing Checklists (inscription gratuite requise)

Modèles de rapport d'utilisabilité

• Modèle long
• Modèle court
• Exemple de rapport de test d'utilisabilité

Lectures complémentaires sur SmashingMag :

• Prioriser les appareils : test et conception Web réactive
• Où sont les meilleurs laboratoires d'appareils ouverts au monde ?
• Un guide pour des tests d'utilisateurs mobiles simples et indolores