mardi 18 septembre 2012

Utilisabilité pour logiciel (et pour un développeur) pt.2

J'ai présenté dans l'article précédent une démarche d'utilisabilité simplifiée pour un logiciel. Dans cet article, je vais vous présenter quelques points spécifiques d'utilisabilité logiciel (pour faire la différence avec les autres types, spécialement l'utilisabilité du web).


Spécifique suivant le plate-forme

Un logiciel va avoir des comportements plus ou moins différents suivant le système d'exploitation. L'office par exemple, n'est pas le même logiciel sous Mac et sous Windows. Chaque plate-forme a son propre guide de style auquel les utilisateurs sont plus ou moins habitués.Si une page web s'affiche différemment suivant les systèmes d'exploitation, c'est que les composants de bases (bouton, champs de texte) sont définis différemment. Sinon le squelette d'une page reste le même suivant le système d'exploitation car à la base, c'est le même code HTML.


Les contrôles restent fixes

Un logiciel a toujours ses contrôles et ses données distingués. Une page web, au contraire, met tout ses contrôles au même niveau avec son contenu. En tournant la molette, tout se déplace ensemble : La barre de navigation, champs de recherche, titre de la page, tout. Bien sur, les composants fixes d'une page existent, mais cela reste très limité (pas au niveau de possibilité technique mais de style)


Utilisation plus ou moins intensif

Un site web existe pour être visité et un logiciel existe pour être utilisé. L'utilisateur a un certain engagement avec un site web mais cela reste relativement faible comparé au logiciel. Vous pouvez dire qu' un logiciel tel que Photoshop reste occasionnellement utilisé par certains type d'utilisateurs, mais à chaque fois, l'utilisation dure plus longtemps qu'une visite d'un site.Bref, l'engagement de l'utilisateur est plus fort sur un logiciel que sur un page web.


L'erreur coûte cher si c'est mal géré

L'erreur est fréquente dans un produit informatique. Dès le développement, c'est déjà impossible de construire une application sans bug ;). Si un erreur est facile à détecter et à corriger, c'est beaucoup plus agréable pour l'utilisateur.Une erreur dans un logiciel est plus grave que dans un site web car il implique beaucoup plus d'enjeux. Imaginez qu'un employé paramètre mal son ERP et n'est pas capable de l'identifier (parce que c'est mal repéré, donc difficile à trouver) . Cela peut impliquer des pertes colossales.


Flexibilité

Ce point est plutôt temporaire et est censé de disparaître dans un futur proche. La flexibilité vient du fait que les interfaces des logiciels sont plus faciles pour faire des choses sophistiquées. Avec le temps, je crois que l'équilibre de facilité sera établie pour l'implémentation de ces deux types d'interfaces.


Le moins de temps possible

Sauf si votre logiciel est extrêmement attractif (un jeu par exemple), l'utilisateur veut en général passer le moins de temps possible pour manipuler votre logiciel. Ils ne font pas attention aux informations autres que ce dont il a besoin.Essayez de faire un design le plus productif possible!

La différence entre utilisabilité web et celui du logiciel reste notable, mais ils se rapprochent avec le temps. Par Exemple, la plupart des logiciels étaient faits avec une barre de menu (ce qui n'est pas très productif à mon avis). La tendance maintenant est de l'éliminer et d'ajouter les éléments de navigation du web.

mardi 4 septembre 2012

Utilisabilité pour logiciel (et pour un développeur) pt.1


Une fois vous avez compris la notion d'utilisabilité, c'est le moment de répondre aux questions suivantes : Pourquoi on doit faire de l'utilisabilité pour les logiciels ? Comment on le fait ? Quelle est la différence avec l’utilisabilité du web ? J’essaierai d’aborder le maximum de choses possibles dans une série de 2 articles.

Pourquoi l’utilisabilité logiciel ?

Supposons que vous avez un logiciel vendu au client. Vous êtes très fier de votre logiciel, qui fait plein de truc que les logiciels de vos concurrents ne font pas. Vous jouez avec votre logiciel 36 fois par jour. Vous présentez votre bébé aux clients et leurs réactions...  PAF!, ils demandent des questions du genre: "Mais ça veut dire quoi ce contrôle ?", "Mais comment je fais ça ? ", etc. Vous pensez peut-être que votre logiciel est hyper bien fait et que c'est juste l'utilisateur qui ne sait pas comment utiliser votre produit : FAUX ! Ce sont vos utilisateurs qui l'utilisent et s'ils n'arrivent pas à l'utiliser, c’est que vous avez RATE votre logiciel.
Essayez de voir la chose avec un autre point de vue: comment vous sentez-vous quand vous installez un logiciel sous Windows en cliquant plusieurs fois sur "Suivant" sans lire les choses ? Comment vous comparez une telle installation avec celle de Google Chrome (celui ou vous avez juste besoin 2-3 simples clics) ?
J'insiste encore une fois qu’une démarche d'utilisabilité est très importante pour la grande majorité des logiciels (je citerai les exceptions plus tard).

Mais comment je fais une démarche d'utilisabilité?

Une "démarche" d'utilisabilité semble être un terme compliqué (et il l'est en plus), mais vous pouvez le faire en toute simplicité avec des méthodes simplifiées (et efficaces). Pour résumer, je vais décrire la démarche d'utilisabilité suivante : (cette démarche est une démarche possible parmi d'autres, vous pouvez très bien créer votre propre démarche):
  • Etude utilisateur: Définir vos utilisateurs cibles et leurs caractéristiques importantes
  • Définir les tâches principales: Qu'est-ce-que votre logiciel fait?
  • Croquis: Faire des dessins simplifiés qui illustrent les grands traits de votre logiciel
  • Wireframe (j'ai du mal à traduire le mot): Un modèle simplifié de votre logiciel qui contient toutes les navigations principales de votre logiciel (enchainement des fenêtres, agencement des composants, etc.) 
  • Prototype: Une maquette qui va rassembler à votre futur logiciel avec des interactions et un jeu de données exemplaires.
  • Test et évaluation à la fin de chaque étape à partir du 3e
Une fois que vous avez votre prototype, vous pouvez coder.
Humm...
Ça a l'air long, n'est-ce pas? Pas tout à fait.
Vous pouvez ajuster cette démarche pour l’adapter à votre logiciel et votre budget (de temps et de coût). L’étude utilisateur peut durer de 30 minutes jusqu'à des jours, tout comme les croquis (vous pouvez dessiner 3 fenêtres en 30 minutes avec un crayon et un papier, n'est-ce-pas?). Vous pouvez aussi couper certaines étapes (prototype par exemple, si vous avez bien fait les étapes précédents)
En général, une démarche d'utilisabilité peut durer d'une semaine jusqu'à quelques mois. Et donc si vous n'avez pas trop de temps, choisissez plutôt une courte démarche. Mais faites-le. Et faites-le au tout début. Car un changement d'interface en cours de développement va coûter beaucoup plus cher qu’un changement en conception (allez, sortez votre gomme et vos crayon ^^)
Rendez-vous au prochain article pour les aspects spécifiques de l’utilisabilité logiciel et la différence avec celui du web.