Rechercher
  • Des usages à la conception et autres
  • digressions autour de l'expérience utilisateur.
Rechercher Menu

Evolution des services, savoir s’arrêter ?

Développer une application, c’est bien, la faire évoluer c’est mieux, mais il y a peut-être des fois où il faudrait mieux savoir s’arrêter. Je pars d’un petit constat sur une application iPhone, Se Loger.com, que j’utilise régulièrement depuis plus d’un an maintenant.

La version 1 était simple et fonctionnelle. Les quatre recherches, que j’ai créées, sont toujours les même (Oui, les prix de l’immobilier sont désespérants). Sur l’écran ci-dessous, elles sont parfaitement lisibles. L’application respecte bien le GUI (Guide of User Interface) iPhone.

Seloger.com sur iPhone.

Mais voila, le temps passe et les versions se succèdent ajoutant de nouvelles « fonctions »:

  • L’accès à la dernière recherche.
  • La publicité
  • Le changement de l’aspect des boutons.

On abouti maintenant au résultat suivant :

Application Se Loger.com, version 2

Petit constat :

  • Les onglets en bas sont plus petits, mais mes doigts n’ont pas changé de taille !
  • On s’éloigne du GUI de l’iPhone.
  • La pub recouvre la dernière recherche, la rendant inaccessible. C’est ballot.
  • Seulement deux recherches sont visibles sur les 4.

Comment faire alors ? Simplement comme cela :

Exemple de présentation pour Se loger.com

On garde le même niveau de fonctions, mais l’élimination des termes redondants « recherche » permet de gagner de la place. La dernière recherche est intégrée dans la liste. Le GUI iPhone est respecté et donc la taille de mes doigts !

Savoir s’arrêter ?

On voila les limites des évolutions, même avec une conception affinée, il est difficile d’aller plus loin. Je donnerai quelques pistes pour savoir s’arrêter :

  • Quand les spécifications font plusieurs pages pour décrire une fonction qui se veut simple.
  • Quand les fonctions qui sont utilisées 5 % du temps, gênent l’utilisation des fonctions principales.
  • Quand il faut un chausse-pied pour faire rentrer les fonctions à l’écran, ce qui arrive assez rapidement sur un téléphone.

Je vous laisse compléter la liste !

Auteur :

Lead UX designer en Freelance depuis le dernier millénaire ! J'aide à concevoir des services, des applications en étant centré sur l'utilisateur et ses usages.

7 commentaires

  1. L’utilisation d’un picto pour remplacer le gros bouton fait gagner beaucoup de place… mais le résultat manque de visibilité, surtout comparé à l’ancien bouton vert façon Apple.
    L’absence de libellé peut également poser problème.

    En plus tu as un peu triché : le nombre total d’annonces en ligne n’est plus affiché, ça risque de ne pas plaire à tout le monde, c’est une donnée importante ! La taille du bandeau de pub a été copieusement revue à la baisse (elle faisait la taille d’une recherche mémorisée, elle passe grosso-modo à la moitié), ça aussi ça pourrait être gênant (je suppose qu’il y a des formats de bannières recommandés sur iPhone, un genre d’IAB pour mobile ?)

    On passe toute notre vie à évoluer, à s’améliorer (j’espère !), à apprendre… S’arrêter c’est presque contre nature !
    Vaste sujet…

    PS. Pourquoi les libellés des champs du module de commentaires disparaissent quand on clique dessus ?

    • L’absence de libellé peut également poser problème.

      Oui, ce n’est pas faux, d’un autre coté tu es sur un onglet « recherche » et les codes utilisés sont classiques : la loupe et le plus. Imagine le même écran lors de la première ouverture de l’application, la liste est vide, tu peux donc avoir un petit texte explicatif à la place. Puis il n’y a pas 36 choses à faire, donc l’utilisateur va bien essayer de commencer quelque part et le plus probable est en haut à gauche ! L’absence de libellé peut poser un problème quand tu as un choix complexe à faire ou des icônes ambigüe. (loi de Hick) C’est parfois plus guidant d’avoir une interface très concise, que d’essayer d’avoir une interface très guidante qui devient alors trop littéraire.

      Oui, j’ai triché, c’est très vilain… Le nombre d’annonce est une donnée importante pour le marketing ou pour faire valoir la qualité de la base de données. Sur un mobile ? Pour l’utilisateur ? heu… c’est un peu comme le nombre de résultats dans Google, c’est juste « Beaucoup ».

      Les libellés disparaissent, oui, visiblement ça ne pose pas de problème ! 😉 C’est juste sympa et ça laisse la place d’écrire.

  2. Il faudrait que j’essaie l’appli pour en parler davantage, je n’avais pas pensé à la page initiale vide par exemple.

    Pour l’utilisateur le nombre d’offres publiées peut être une donnée intéressante, par exemple si l’annonceur n’est pas très connu ; dans le cas d’une appli, surtout pour seloger.com, l’importance est clairement moindre. Là c’est le briefeur qu’il faut convaincre…

    Pour les libellés c’est bizarre parce que ça masque une partie du contenu (ici du moins) 🙂
    cf. http://uxui.fr/img/iergo_commentaires.png (champ Adresse de contact)

    • Pour l’utilisateur le nombre d’offres publiées peut être une donnée intéressante, par exemple si l’annonceur n’est pas très connu ; dans le cas d’une appli, surtout pour seloger.com, l’importance est clairement moindre. Là c’est le briefeur qu’il faut convaincre…

      Je pense qu’il faut regarder du coté du parcours de l’utilisateur. Comment tu en viens à télécharger une application d’annonces immobilière ? Dans mon cas, c’est après avoir utilisé le site, donc la notoriété du site était déjà établi.

  3. Il me semble que le problème n’est pas de savoir s’arrêter. Le problème provient du mode d’évolution. Comme tu le sais, l’évolution d’un service se décide autour d’une table à partir de l’imagination des personnes présentes (en agitant les bras souvent) et non en se basant sur l’analyse de l’interaction en contexte réel. Par ailleurs, la nouvelle version n’est pas comparée à l’ancienne de manière sérieuse afin de déterminer si elle apporte quelque chose et surtout s’il n’y a pas régression en terme d’utilisabilité. Il faut dire que c’est le genre de truc risqué : la boîte à Cramé 800 k€ pour la V2 et un test à 20 k€ vient te démontrer que la V1 est bien plus performante ! Autant mettre les 20 K tout de suite dans la V3…

  4. Merci pour ces commentaires. Je vous rassure, on n’a pas payé 800K pour la v2 😉 Par ailleurs, vous parlez de tests utilisateurs (j’espère pas à 20K) et c’est une dimension qui nous préoccupe de plus en plus (nous utilisons beaucoup les commentaires iTunes pour améliorer notre app) mais n’avons pas forcément de retours avec des utilisateurs concernant l’usabilité. C’est d’autant plus important quand notre appli génère plus de 3 millions de visites par mois. ! Je suis à l’écoute de vos suggestions sur ce sujet et sur l’UI en général, si on peut encore l’améliorer, je suis preneur !

    Merci,

    Frédéric

    • Pour les tests utilisateurs, vous pouvez regarder l’article « Test utilisateur, mythe et réalité », mais je vous conseille de vous intéresser à la norme ISO 20282 : Facilité d’emploi des produits quotidiens.

      Pour le prix, dans un test utilisateur classique, il faut prendre en compte le projet, préparer les tests, recruter les utilisateurs avec certains critères, préparer la plateforme de test, faire passer les tests individuellement, recueillir les données et synthétiser l’ensemble. Cela demande facilement 10 à 20 jours de travail d’ou un prix de 10 à 20k€.

Les commentaires sont clos.


Warning: Undefined array key "share-pages" in /home/clients/8d92eb93db207cb7c6158a9c725c2336/web/blocnotes/wp-content/themes/dorayakichild/footer.php on line 77