Mille et un bogues d'interface utilisateur, ou comment aider un développeur à éviter les erreurs d'interface utilisateur courantes

Il semblerait que tester de nouvelles fonctionnalités soit un processus très créatif et intéressant. Mais que se passe-t-il si les erreurs dans les interfaces se répètent d'une fonctionnalité à l'autre et que la plupart du temps est consacré à détecter de petits problèmes d'interface?



Au cours de mes quatre années chez Badoo, sur plus de mille bugs rencontrés, environ 20% étaient liés à l'interface utilisateur et à l'expérience utilisateur. Un tiers d'entre eux sont insignifiants dans l'échelle du produit, mais nécessitent néanmoins des moyens de traitement, car ils affectent directement la fidélité des utilisateurs. Ces bogues ne peuvent être détectés que manuellement. De plus, ils ne se trouvent souvent que sur certains appareils dans certaines conditions.

Est-il possible d'empêcher ces bogues même au stade de la conception de nouvelles fonctionnalités et d'éviter le traitement de l'interface après le test? Ma réponse est oui!

Dans cet article, à l'aide d'exemples tirés de mon expérience, je vais vous expliquer comment rendre le processus de test moins routinier et arrêter de démarrer les mêmes bogues, montrer les erreurs les plus courantes dans le développement d'interfaces d'applications mobiles sur la plateforme Android et expliquer d'où elles viennent le plus souvent. L'article a été écrit sur la base de mon rapport à la conférence de Heisenbug, la vidéo peut être visionnée ici .

Personne n'aime chercher, et encore plus corriger les erreurs d'interface:



Et combien il est désagréable pour les utilisateurs de travailler avec des applications remplies de petits problèmes d'interface auxquels l'œil s'accroche! Souvent, ces problèmes se répètent de fonctionnalités en fonctionnalités et sont hérités des nouveaux produits et des composants.

Chez Badoo, nous avons également fait face à cette situation. Le processus de développement a été conçu de manière à éviter cela. Cependant, des problèmes d'interface se sont toujours produits périodiquement.



Notre idée devient une nouvelle fonctionnalité, après avoir traversé de nombreuses étapes. De plus, l'un des plus importants dans la recherche et la prévention des problèmes d'interface n'est pas le test au stade du contrôle qualité, comme cela peut sembler, mais un examen. À ce stade, le chef de produit et le concepteur examinent un nouveau prototype d'une fonctionnalité ou de l'ensemble de l'application et évaluent s'ils voulaient l'obtenir et s'ils aiment tout. Il s'agit de l'une des méthodes les plus utiles pour détecter les problèmes d'interface. Assurez-vous de l'inclure dans votre travail: un examen fera gagner beaucoup de temps à tous les participants au processus.

Mais cela ne suffit pas. Malgré le fait que nous ayons une critique, environ 20% de mon temps j'ai passé à décrire des erreurs et des inconvénients mineurs de l'interface. De quels types de problèmes s'agit-il?

Les causes les plus fréquentes de bugs UI / UX


Après avoir analysé les problèmes rencontrés le plus souvent par l'équipe de développement Android au cours des quatre dernières années, j'ai réussi à identifier quatre causes principales de leur apparition:



Allons dans l'ordre et commençons par le problème le plus populaire.

1. Disposition sphérique sous vide


Plus de la moitié des erreurs que nous avons découvertes ont été causées par une situation où la mise en page créée par le concepteur n'a pas répondu au grand nombre de questions que le développeur avait dans le processus de création du prototype.

Regardons un exemple de mon expérience. Dans l'image de gauche est la mise en page du concepteur, dans l'image de droite est la première itération du prototype.



Dans le prototype, nous voyons de très «belles» données, et on ne sait pas quoi faire si le contact de l'utilisateur dans le carnet a un nom long ou pas de photo. Le rendu des maquettes pour toutes les occasions est une tâche longue: pour compléter le tableau, vous devez discuter de tous les goulots d'étranglement, sinon ils ne peuvent apparaître qu'au stade des tests.

2. Sous-estimer l'importance du design


En deuxième place, il y a les situations où le développeur a ignoré la conception et a fait quelque chose à sa manière, sans égard à la mise en page.

Un autre exemple de la vie. La tâche consistait à mettre à jour l'écran de saisie de l'anniversaire de l'utilisateur. À gauche, le design et à droite, le prototype du développeur.



Le composant de sélection de date a déjà été écrit pour d'autres fonctionnalités, et le développeur vient de l'utiliser, tandis que le concepteur a spécialement dessiné un composant complètement nouveau pour faciliter l'inscription de l'utilisateur dans l'application, à savoir entrer la date de naissance.

3. Lacunes dans la documentation


À la troisième place de la popularité se trouvent les lacunes dans la documentation ou les questions au chef de produit. Par exemple, j'ai testé une fonctionnalité avec des conseils pour les nouveaux utilisateurs sur l'objectif des différents éléments d'interface. Dans l'image de gauche se trouve la mise en page de la documentation, et dans l'image de droite ce qui s'est passé en cas de connexion Internet déconnectée.



En cas d'échec de connexion, le cas dit zéro apparaît, c'est-à-dire un écran informant l'utilisateur qu'il n'y a pas de connexion. Il est souvent oublié de lui, et dans ce cas, un indice a continué d'y apparaître, mais cette situation n'était pas reflétée dans la documentation de la nouvelle fonctionnalité.

4. Caractéristiques du système d'exploitation Android et du firmware


La cause la plus rare (mais en même temps régulière) des erreurs dans les interfaces sont les mises à jour du système d'exploitation ou le firmware des fabricants.

Par exemple, dans Android 9, je suis devenu comme le personnage Ghost in the Shell, car après l'apparition des "bangs", les photos des utilisateurs ont commencé à ressembler à ceci:



Et les problèmes n'étaient pas uniquement liés à l'UX. Nous avons également rencontré un cas où des notifications dans l'application ont commencé à apparaître sous cette «frange» dans certains cas.

Lorsque les erreurs UX / UI sont autorisées


Y a-t-il des cas où vous n'avez pas besoin de vous concentrer sur ces erreurs d'interface mineures? Bien sûr, oui: si vous faites du MVP, il existe alors un produit peu viable et votre objectif est de savoir si l'utilisateur aimera l'idée dans son ensemble.

D'accord, dans ce cas, cela n'a aucun sens de passer du temps à éliminer les plus petits bugs: on ne sait pas si cela sera payant. Cependant, personne ne peut garantir que l'utilisateur n'a pas aimé la nouvelle fonctionnalité précisément parce qu'elle a été créée à 80% et non à 100%. Dans ce cas, la criticité des erreurs est déterminée par le chef de produit. L'essentiel est de ne pas oublier tous ces problèmes mineurs et de les éliminer à l'étape suivante, quand il est déjà clair que l'utilisateur a aimé le projet et qu'il est passé de MVP à l'étape de développement ultérieur.

Que faire de tout ça?


Comment se débarrasser des causes d'erreurs d'interface ci-dessus, quelles méthodes utiliser? Passons en revue les méthodes et astuces de base que nous utilisons dans Badoo. Commençons par le plus long.

1. Créez votre propre système de conception


Chez Badoo, nous avons créé notre système de conception Cosmos unique, ce qui a simplifié l'interaction des concepteurs et des développeurs et accéléré considérablement le processus de développement.



En termes simples, le système de conception donne des réponses à toutes les questions sur ce qui peut arriver avec l'un ou l'autre composant de l'interface: quels états il peut avoir, à quoi il ressemble en fonction de la longueur du texte, etc. Dans l'image ci-dessus, cela est montré comme un exemple du composant Button. Lorsqu'il existe un système de conception, vous n'avez pas besoin de dessiner des dispositions détaillées pour les nouvelles fonctionnalités pour toutes les occasions.

Le développement de systèmes de conception est le choix des grandes entreprises avec de nombreux produits et des interfaces complexes sur différentes plates-formes, par exemple Google avec son Material Design. Vous devrez dépenser de l'argent pour développer un tel système, mais à l'avenir, cela aidera à éviter un grand nombre de problèmes.

Que faire s'il n'y a pas de temps pour développer un système de conception ou si vous avez une petite application qui ne nécessite pas l'utilisation de méthodes aussi complexes? Vous pouvez écrire de petites bibliothèques avec des composants ou une brève documentation, c'est-à-dire décrire les principes existant dans l'entreprise dans de simples directives internes ou de l'aide.

En savoir plus sur Cosmos dans la série d'articles de mon collègue Cristiano Rastrelli et les liens à la fin de l'article.

2. Utilisez des outils de test visuel


La popularité des outils de test visuel ne fait que croître, tout comme le nombre de solutions sur le marché. Vous pouvez écouter l'utilisation des tests VRT dans notre entreprise dans le rapport de mon collègue Karl Crawford sur CodeFest. Cependant, nous ne nous sommes pas arrêtés là, car nous voulions non seulement comparer les images, mais aussi stocker les scripts utilisateur. Nous sommes donc allés de l'avant et avons créé notre outil multiplateforme LiveShots.



Les LiveShots peuvent faire bien plus: il nous permet de comparer les interfaces de nos applications non seulement entre les versions, mais aussi entre les plateformes iOS et Android. Il fonctionne sur la base de nos autotests et collecte des scripts utilisateur avec prise en charge de différentes langues, de sorte que même des modifications minimes de l'interface ne passent pas inaperçues. Vous pouvez en savoir plus sur LiveShots à partir d'un rapport de ma collègue Sasha Bayandin.

3. Construisez un bon banc d'essai


Nous passons à des outils et des méthodes plus faciles à mettre en œuvre. Un banc d'essai bien assemblé aide beaucoup à résoudre les problèmes de fragmentation et les fonctionnalités du micrologiciel de divers fabricants d'appareils mobiles. De combien d'appareils mobiles pensez-vous avoir besoin pour tester la qualité et trouver des problèmes liés à la fragmentation? Afin de ne pas passer beaucoup de temps à tester sur différents appareils et en même temps trouver les problèmes les plus courants de vos utilisateurs, cinq à six appareils (par exemple, sur la plateforme Android) suffisent. Vous pouvez en savoir plus sur la façon de choisir des appareils pour un banc de test dans mon article sur Habr .

4. Utilisez des outils auxiliaires


Il existe de nombreuses applications d'aide intéressantes pour tester et résoudre les problèmes dans les interfaces. Les développeurs de systèmes d'exploitation ajoutent régulièrement ces outils directement à la section des paramètres de l'appareil (voir Options pour les développeurs). Parmi les plus utiles, à mon avis, est l'affichage de Afficher les clics sur les robinets et Afficher les bordures des limites de la disposition.



Parmi les applications, je peux recommander l' assistant développeur , qui, comme l'inspecteur de mise en page portable, affiche des informations détaillées sur les éléments d'interface, tels que les tailles et les couleurs de police, et les outils Designer avec la possibilité de prendre des captures d'écran avec des informations détaillées sur le modèle de l'appareil, la résolution d'écran, afin qu'il soit pratique de les appliquer à rapports de bogues ou même un endroit pour stocker.

5. Rencontrez-vous plus souvent


Cela semblerait une méthode évidente. Cependant, de quoi parler lors d'une réunion? À propos des erreurs répétées - car cela indique que les participants au processus ont des opinions différentes sur leurs responsabilités et leurs tâches. Chaque problème que vous avez rencontré plusieurs fois nécessite une analyse obligatoire avec tous les employés impliqués.

Lors de la conférence où j'ai fait une présentation, on m'a posé des questions sur ce qu'il faut faire si personne ne veut prendre la responsabilité de problèmes d'interface mineurs, c'est-à-dire que tous les participants au processus se pointent les uns les autres: le testeur dit que la vérification de l'interface est une tâche concepteur, développeur - que le chef de produit était satisfait de tout quand il lui a montré le prototype, et le concepteur ne comprend pas pourquoi finalement le produit est si différent de la mise en page qu'il a créée. La meilleure solution est de résoudre tous les malentendus, c'est-à-dire de se réunir et de travailler à l'amélioration du processus, de discuter et de clarifier les domaines de responsabilité de tous les participants au développement, et de ne pas perdre de temps à attraper les mêmes erreurs.

6. Dogfood


Une autre méthode simple dont on a déjà beaucoup parlé est la nourriture pour chiens, c'est-à-dire l'utilisation de vos propres produits au sein de l'entreprise. Les représentants de grandes entreprises comme Facebook adorent en parler: bien sûr, lorsque 20 000 employés regardent leur produit eux-mêmes, l'armée de testeurs n'est pas vraiment nécessaire. En fait, la chose la plus importante est que les aliments pour chiens vous aident à mieux connaître votre propre produit et à comprendre les besoins de l'utilisateur. Alors ne le sous-estimez pas.

7. Rédigez une liste de contrôle


Sur la base des problèmes analysés, j'ai compilé une liste de contrôle qui vous aidera à passer rapidement en revue une nouvelle fonctionnalité ou une toute nouvelle application et à gagner du temps sur la récupération des goulots d'étranglement de la mémoire dans les applications mobiles, c'est-à-dire où les erreurs d'interface et les problèmes d'utilisabilité sont les plus courants. Cette liste de contrôle sera particulièrement utile si vous la complétez avec vos spécificités en fonction des bugs les plus courants rencontrés dans votre projet. Prenons-le à part.

Il y aura des exemples assez simples de ma pratique:

image

  • vérifier tous les textes;


Les noms des boutons ne doivent pas être trop longs. Cette règle est vraie pour n'importe quelle langue.

image

  • vérifier s'il existe des indicateurs de progrès;


Même les directives de Google indiquent que si un écran se charge pendant plus de trois secondes, vous devez informer l'utilisateur qu'un téléchargement est en cours, par exemple, en montrant une sorte d'animations. De même, avec d'autres éléments "lourds" - vidéo et photos.

image

  • vérifier ce qui est affiché en l'absence de données (zéro cas);


Il est important qu'en l'absence de données, par exemple, pour un nouvel utilisateur qui n'a pas de messages entrants, au lieu de pages blanches blanches, un texte s'affiche pour expliquer ce qui se passe et comment continuer à travailler avec l'application.

image

  • vérifier les boutons et leur état;


Il est important que les boutons répondent à la pression et il est clair pourquoi ils sont inactifs, le cas échéant.

image

  • nous comparons les retraits et les alignements avec la mise en page;


C'est un moment très douloureux, car il est impossible de prévoir toutes sortes de fragmentation, mais le banc d'essai y aidera beaucoup.

image

  • vérifier s'il y a des espaces réservés en l'absence d'images;


Encore une fois, ne montrez pas à l'utilisateur un écran blanc en l'absence d'images et d'informations, mais expliquez que l'image ou la section est manquante.

image

  • vérifier l'interaction de l'ancienne fonctionnalité avec la nouvelle;


Ici, tout est similaire à l'exemple avec des astuces pour l'utilisateur que j'ai cité ci-dessus.

image

  • travailler hors ligne;


Il est impératif d'informer l'utilisateur de la déconnexion, car dans ce cas il ne suffit pas d'afficher l'indicateur de téléchargement.

image

  • Nous vérifions le comportement des nouvelles interfaces sur les petits appareils;


Pas de commentaire, voir photo.

image

  • vérifiez si les images sont optimisées pour les petits appareils;


Il n'y a pas toujours assez d'espace sur le petit écran, donc toute la mise en page peut aller en raison d'images non optimisées.



  • vérifier l'interaction avec différentes versions du système d'exploitation;


Il serait intéressant de conserver une liste des problèmes survenus dans l'application après la mise à jour du système d'exploitation, afin de ne pas répéter les mêmes erreurs à cause de ces changements.

  • vérifier l'interaction avec différentes versions du firmware;


De même: il serait intéressant de conserver une liste des problèmes survenus dans l'application sur différents appareils et de vérifier le comportement d'une nouvelle fonctionnalité dans des conditions similaires.

  • vérifier l'animation (en particulier sur les petits appareils faibles);


Il est préférable d'abandonner l'animation et de la remplacer par une image statique pour les appareils faibles avec une petite résolution d'écran.

Votre liste de contrôle pourrait donc ressembler à ceci:


À quel moment utilisez-vous cette liste de contrôle et quel est le moyen le plus simple de prévenir les bogues? Lorsqu'une fonctionnalité passe à l'étape de développement et que les premières questions apparaissent, car il est trop tard pour poser des questions à l'étape de test.

Il serait bon de garder cette liste de contrôle à l'esprit au stade du développement - elle aidera les développeurs à prendre en compte toutes les subtilités lors de la conception d'une interface d'application mobile, et permettra également aux testeurs de gagner du temps au stade du contrôle de la qualité.

Conclusions


Résumons les méthodes qui peuvent aider à réduire le nombre de problèmes d'interface dans vos produits:

  • examen du prototype avec le chef de produit et le concepteur pour chaque nouvelle fonctionnalité;
  • l'utilisation de listes de contrôle détaillées basées sur les problèmes les plus courants qui sont pertinents pour votre produit, au stade du développement ou même de la conception de nouvelles fonctionnalités;
  • analyse et discussion des causes des problèmes fréquemment rencontrés lors de la conception de nouvelles fonctionnalités;
  • dogfood - l'utilisation et la bonne connaissance de votre produit;
  • développer votre propre système de conception ou créer un document avec des directives;
  • mise en place d'outils de tests visuels.


Liens utiles



Source: https://habr.com/ru/post/fr479970/


All Articles