Comment vous assurez-vous d'avoir couvert l'ensemble du site dans votre travail?
Je suis un praticien relativement récent, et bien que la qualité de mon travail soit assez bonne, j'ai toujours un gros tirage (à mon avis): je manque toujours quelque chose ou deux lorsque je crée ou corrige un site Web.
Ce que je veux dire, c'est que lorsque je livre le travail requis, je découvre plus tard que j'ai oublié de concevoir une interaction, d'inclure un lien, d'inclure un élément, de corriger l'apparence d'un élément ou même de sauter une page entière enfouie profondément dans le site Web.
Alors, comment vous assurez-vous que vous avez tout couvert dans votre travail?
Tu ne peux pas.
Le mieux que vous puissiez faire est d'avoir un processus solide d'analyse, de conception et de documentation qui implique tous ceux qui doivent être impliqués à la fois dans les affaires, l'équipe de développement et les utilisateurs, passez en revue, revoyez-le, demandez à un pair/collègue de revoir votre travail, puis avoir des processus en place pour réviser la conception pendant les phases de développement, de test et de maintenance lorsque des omissions ou des erreurs sont constatées.
Tout d'abord, je sympathise et je suis d'accord avec les autres réponses. Je voudrais ajouter que c'est l'une des situations où les méthodologies agiles ont un grand avantage à mon avis. Ce n'est peut-être pas tout à fait pertinent pour votre situation si vous travaillez seul, mais dans un processus de cascade traditionnel, il est souvent facile de manquer des choses car les exigences ont tendance à changer avec le temps et les choses sont abandonnées et reprises à mesure que les priorités changent. C'est particulièrement vrai pour un grand site avec beaucoup de contenu ou des fonctionnalités complexes.
Cependant, avec un processus agile, vous travaillez généralement sur une section à la fois ou vous créez des couches. Donc, lorsque vous passez à la prochaine itération, c'est le bon moment pour votre client ou quelqu'un d'autre (peut-être l'équipe UAT dans un environnement de développement plus large) pour examiner et tester le travail déjà terminé avant la sortie du produit dans son ensemble. De cette façon, vous pouvez revenir sur tout ce qui a été manqué ou a besoin de plus de travail plus tard. Vous pouvez diviser le développement dans son ensemble en morceaux gérables.
Ceci est une excellente ressource liée à cela http://www.useit.com/papers/heuristic/heuristic_evaluation.html
En général, l'évaluation heuristique est difficile à faire pour une seule personne car une seule personne ne pourra jamais trouver tous les problèmes de convivialité dans une interface. Heureusement, l'expérience de nombreux projets différents a montré que différentes personnes rencontrent des problèmes d'utilisation différents.
Je suis d'accord avec Nathanael, tu ne peux pas.
Quoi qu'il en soit, il existe quelques conseils qui peuvent vous aider. Demandez à un expert (collègue, ami) de parcourir votre travail. C'est tellement sain que je recommande de le faire à chaque fois. Faites un court test d'utilisabilité. Utilisez la liste de contrôle (vous pouvez créer la vôtre ou une liste existante) pour contrôler la qualité. Vous pouvez également essayer d'effectuer des cas d'utilisation juste pour vous assurer que l'interface fonctionne réellement. Tout cela augmente la probabilité de trouver quelque chose que vous avez manqué.
Je suis d'accord pour dire que l'examen par les pairs est le meilleur. Il est également avantageux que vous expliquiez vos conceptions à d'autres, que vous en discutiez. Même dire ces choses à voix haute est souvent utile pour moi.
Et je recommanderais de vérifier les conceptions sous différents points de vue (utilisateur, développeur, concepteur visuel, etc.).
Cela pourrait vous aider à vous reposer plus facilement si vous reconsidériez l'objectif du travail de conception que nous faisons.
N'oubliez pas que les visuels, les wireframes, les personnages, etc. ne sont pas le but des concepteurs. Avoir un très bon produit est l'objectif. Les premiers ne sont que des aides à la communication pour aider à faire des seconds une réalité.
Avoir une documentation de conception 100% précise n'est pas ce que nous devrions viser. Nous devrions essayer de fournir les bonnes informations afin que toutes les personnes impliquées puissent travailler ensemble pour créer un très bon produit.
Avoir un bon processus avec beaucoup de commentaires, de tests et avec toute l'équipe comprendre les objectifs de conception sera beaucoup plus efficace que huit classeurs de documentation de conception que personne ne lira tous couvrant en détail toutes les interactions et tous les états d'erreur possibles :-)
Donnez une démo
Imaginez qu'un public très intéressé vous pose de très bonnes questions et passez une heure ou deux à répondre à ces questions en faisant la démonstration du système. Je trouve plus de bugs de cette façon que de toute autre manière.
Examen par les pairs
Quelqu'un d'autre pense différemment que vous, clique différemment et regarde un système différemment. Moins vous pouvez en dire à cette personne - votre deuxième paire d'yeux - mieux c'est. Vous ne voulez pas les conduire accidentellement sur la piste à travers le système que vous suivez toujours si vous n'êtes pas obligé de leur expliquer le système.
Changer l'environnement
Installez le site sur un autre serveur. Utilisez un navigateur différent ou une version de navigateur différente. Utilisez un système d'exploitation différent. Supprimez vos cookies, désactivez JavaScript, bloquez les cookies et réessayez.
Utiliser un plan de test
Un bref aperçu de haut niveau vous aide à visiter toutes les fonctionnalités dont vous avez besoin. Trop de détails et vous vous concentrerez sur le test au détriment de la recherche de problèmes. Le maintien d'un test détaillé prend également beaucoup de temps. Trop peu de détails et vous manquerez des zones critiques du système.
Passez en revue votre travail ... encore
J'ai récemment vu une grande vidéo d'entrepreneur où ils ont dit: " La différence entre le bon et le grand est de 10 minutes ." Ce qu'ils ont expliqué signifiait que lorsque vous écrivez votre e-mail complet, ne l'envoyez pas. Prenez un café, promenez-vous dans le bloc, puis relisez votre courrier électronique et essayez votre système une fois de plus du point de vue de la personne à qui vous l'envoyez. Dans le logiciel, cette différence peut être de 2 heures au lieu de 10 minutes, mais vous voyez l'idée.
"Alors, comment vous assurez-vous que vous avez tout couvert dans votre travail?"
Vous adoptez une méthodologie de développement de conception qui tient compte de cette inévitabilité.
Ce problème survient généralement dans une cascade (ce que j'appelle un processus de "ligne d'assemblage") où les choses sont signées avant même qu'une ligne de code ne soit écrite.
Il est impossible de concevoir chaque interaction complètement sur papier. Une grande partie des décisions de conception d'interaction doivent être prises avec du code de travail. Et puisque vous n'avez pas encore de code de travail, il est inévitable que des choses soient manquées.
Idéalement, vous travaillez dans un système plus agile où vous concevez du code au fur et à mesure que vous l'écrivez et que vous et le développement êtes capables de modifier les choses au fur et à mesure.
Les choses vraiment délicates à surveiller sont les messages d'erreur, car ils ne sont souvent déclenchés que par un ensemble particulier d'entrées.
Vous devez souvent simuler le comportement des utilisateurs "non conformes" pour les faire apparaître (ou réaliser qu'ils auraient dû apparaître, et ne l'ont pas ...)
Par exemple, des choses qui font face au format irrégulier des codes postaux britanniques ...