Où les tests utilisateurs ont-ils lieu dans LeanUX / Agile?
J'essaie de concilier ce que je ressens comme un peu de contradiction dans LeanUX.
- tester, valider et répéter tôt
- réduire la charge de documentation
Est-ce que votre organisation teste l'utilisabilité/l'utilisabilité dans un processus agile? Si c'est le cas, quand et comment?
Dans notre organisation, nous faisons beaucoup de tests à distance non modérés. Cela nécessite la création d'un prototype relativement complexe et partageable (généralement Axure ou Invision, parfois HTML).
Ce n'est pas tout à fait mauvais, car dans le processus de création du prototype, nous faisons beaucoup d'itérations internes et d'ajustements de conception. Cependant, cela semble contraire au point 2 ... car ces prototypes ont tendance à être des documents plutôt volumineux en termes de temps et d'efforts (sans parler de la maintenance s'ils sont également utilisés comme filaires pour les développeurs).
Question: Ces deux points sont-ils contradictoires ou le problème que je les interprète est-il incorrect?
MISE À JOUR:
Une question alternative à laquelle il serait plus judicieux de répondre: effectue-t-on normalement des tests d'utilisabilité non modérés dans un processus Lean UX?
TLDR: Nous posons cette question "Quel est le plus petit incrément de travail qui peut être testé?
Nous allons tester cela en utilisant la solution la plus rapide qui nous fournira des réponses. Ce qui signifie que des produits comme Axure et même Invision sont souvent considérés comme trop longs à utiliser, sauf si nous avons affaire à une solution basée sur une animation/interaction difficile à transmettre aux personnes utilisant une interface utilisateur statique.
Répartition de notre processus
Nous avons construit notre processus à partir des idées du livre Inspiré: Comment créer des produits que les clients adorent .
Il y a 4 phases
- Évaluation des opportunités - Recherche sur le problème perçu par l'utilisateur, décision d'aller/de ne pas aller
- Découverte de produits - Idéation itérative et test de concept
- Exécution du produit - Décrivez les histoires et travaillez avec les développeurs pour la mise en œuvre
- Version - Version progressive (bêta) ou incrémentielle, obtenez des commentaires après la sortie
La majorité des tests ont lieu pendant la phase de découverte du produit. Nous essayons d'opter pour de larges contrôles de course au début. La taille des groupes de test est donc très petite ... 3-5. Nous pouvons commencer par un test rapide avec le personnel interne (support, on-boarding et vendeurs). Ensuite, nous programmons des sessions de partage d'écran à distance avec les utilisateurs. (Nous avons affaire à un logiciel complexe, il est généralement plus facile de détecter les nuisances lorsque vous pouvez entendre l'utilisateur.) Puisque nous sommes là avec l'utilisateur, nous faisons fréquemment une session combinée avec un entretien avec un modèle mental suivi d'un concept de type A/B tests.
Les tests de concept sont aussi peu fidèles que possible. Il s'agit généralement d'un fichier omnigraffle ouvert. J'ai lu la question, j'ai parcouru des pages d'écrans et recueilli leurs commentaires directement sur ledit fichier. Vous gagnez beaucoup de temps si vous n'avez pas besoin d'exporter et de télécharger des images, puis de modifier les éléments dans un outil séparé. (Je ne dis pas que des outils comme Axure et Invision n'ont pas leur place dans notre flux de travail. Ils le font pour des choses avec des interactions d'écran plus complexes. Ils ne sont souvent pas nécessaires.)
L'aspect le plus long de ce processus est probablement le recrutement d'utilisateurs. Nous sommes assez chanceux d'avoir une base d'utilisateurs très active qui est très heureuse d'aider avec les tests. Nous utilisons ensuite un outil comme youcanbook.me pour indiquer les blocs libres à tester et demander à nos utilisateurs de s'inscrire pour les blocs.
Je crois qu'un autre terme pour cela est mêlée à deux pistes si vous voulez plonger plus profondément dans la région.
Mise à jour: à propos de votre question sur les tests non modérés. Nous l'avons essayé dans le passé et nous nous sommes arrêtés. Les tests non modérés nécessitent que vous en sachiez beaucoup plus sur la question à résoudre. Si les questions posées sont complètement fausses, les données de test non modérées seront complètement gaspillées. Avec un test modéré, vous avez beaucoup plus de flexibilité pour vous ajuster à la volée. De l'autre côté avec un modéré, vous devez être là pour exécuter le test, ce qui limite le nombre que vous pouvez faire. Mais, les chiffres ne sont pas nécessaires pour les premiers tests, juste les sentiments intestinaux de l'utilisateur.
La magie avec Lean UX est que vous pouvez tester à chaque fois que vous en avez besoin. Cela signifie que chaque fois que vous avez un doute dans votre processus de développement.
Vous n'avez pas besoin d'organiser des sessions de test utilisateurs longues et complexes avec un prototype complexe complet fait dans Axure. C'est la force UX maigre.
Vous pouvez tester juste une fonctionnalité spécifique, ou l'interface avec un prototype esquissé fait avec des applications simples et gratuites (comme Pop par exemple).
L'application d'Invision fournit également de bons outils comme le Liveshare ou les commentaires en ligne qui peuvent vous aider à faire des tests utilisateur rapides et courts.
Lean UX est une méthode qui a permis l'échec. Vous devez voir vos sprints comme des expériences, de sorte que dans un laboratoire scientifique, vous faites des hypothèses, essayez, testez, échouez ou réussissez, puis vous en faites une.