Dans cet article, nous abordons un sujet souvent controversé : quand une application logicielle est-elle bonne ? Ou, pour le dire autrement : qu'est-ce qui fait un bon logiciel ? Formulé de manière quelque peu désinvolte, on dirait probablement qu'une application "est bonne quand elle est utile et peut bien faire ce pour quoi elle a été faite". Plus formellement, l'application doit présenter un degré élevé de facilité d'utilisation ou de convivialité. Par souci de simplicité, nous utiliserons le terme anglais usability pour parler de ces concepts.

Hmm, qu'est-ce que la convivialité exactement ?

Le terme " utilisabilité " n'est pas toujours clairement défini et est certainement interprété différemment par différentes personnes. Une simple recherche sur Internet donne une variété de définitions pas toujours cohérentes. La convivialité peut bien sûr être appliquée à tout objet fabriqué par l'homme (pas seulement aux logiciels), mais cela ne nous intéresse pas ici. On rencontre souvent le terme d'ergonomie des logiciels. Ce qui est certain, c'est que l'utilisabilité n'est pas mesurable sur une échelle absolue et c'est précisément la raison pour laquelle elle est souvent victime de perceptions subjectives. Cela conduit ensuite à des discussions sur la personne qui a maintenant raison dans son évaluation du logiciel.

Dans cet article, nous essayons d'aller au fond du terme "utilisabilité" et, en particulier, d'examiner de plus près la mesurabilité. Nous allons l'essayer de manière très simple et ne distinguer que les trois aspects suivants en ce qui concerne la convivialité d'une application logicielle :

• Portée fonctionnelle(Que peut faire l'utilisateur avec l'application ?)
• Concept de fonctionnement(Comment l'utilisateur peut-il faire quelque chose ?)
• Délai de réponse(Dans quel délai l'application répond-elle à l'entrée de l'utilisateur ?)

Éclaircissons ces termes ci-dessous et examinons chacun d'entre eux de plus près.

L'éventail des fonctions : que peut faire ma demande ?

Le champ fonctionnel d'une application est souvent surchargé et ne couvre pas vraiment ce dont l'utilisateur a besoin. À quoi sert une candidature si je n'ai pas besoin de 80 % des fonctions proposées pour mon travail ? Ce lest n'est généralement pas seulement quelque part en arrière-plan et m'a coûté cher à l'achat - non, il peut même me gêner dans l'utilisation des 20 % de fonctions vraiment utiles. La rumeur veut que des applications bien connues, comme les produits Office, souffrent de cette maladie. Il n'est pas facile de trouver des statistiques concrètes et corroborées. Et ceux que l'on trouve sont certainement à prendre avec un grain de sel. Cependant, vous pouvez facilement trouver des dizaines de billets de blog sur le web ("Les 50 conseils pour Word", "Les paramètres cachés de Microsoft Office", "10 conseils pratiques pour Word", etc.), ce qui suggère que l'utilisateur type d'Office ne travaille évidemment qu'avec une petite partie des fonctionnalités disponibles et ne connaît pas du tout le reste.

Une bonne application a donc autant de fonctions que possible que l'utilisateur attend et utilise au quotidien. Le terme "exactement ces fonctions" est bien sûr défini de manière quelque peu différente selon l'utilisateur. Mais si nous imaginons une application commerciale utilisée par un grand nombre d'utilisateurs dans la même entreprise ou même dans un secteur d'activité, alors un dénominateur commun peut certainement être trouvé parmi ces utilisateurs. Une telle application commerciale doit offrir les fonctions qui soutiennent de manière optimale les processus commerciaux typiques. Et si le prix est juste, beaucoup d'organisations sont également prêtes à adapter leurs processus à un produit standard pour les quelques écarts par rapport à l'application souhaitée.

Le concept de fonctionnement : comment faire à nouveau... ?

Le concept de fonctionnement d'une application détermine la rapidité avec laquelle un utilisateur peut trouver et utiliser la fonction dont il a besoin pour une tâche. On parle souvent de l'intuition de l'utilisateur ou du fait que "l'application peut être utilisée intuitivement". Bien sûr, le principe de subjectivité s'applique ici aussi : ce qui est intuitif pour une personne est compliqué et incompréhensible pour une autre. Ici, après tout, il existe des possibilités de mesure. La simplicité d'utilisation peut être mesurée et évaluée sur un groupe plus large d'utilisateurs. Les personnes testées se voient simplement confier une tâche à résoudre avec l'application et on mesure la rapidité avec laquelle elles la gèrent réellement. De cette façon, différentes applications construites dans le même but peuvent même être comparées entre elles de manière quantitative et quelque peu objective (car statistiquement). En pratique, les différents produits concurrents doivent simplement faire face au marché. Une opération pilote qui peut être mise en place rapidement et qui est suffisamment longue peut certainement aider.

Un bon concept de fonctionnement est toujours cohérent, c'est-à-dire aussi cohérent que possible dans toutes les fonctions : les mêmes actions sont effectuées de la même manière. Recherche d'objets, réglage des affichages, ouverture et modification d'éléments de données, suppression d'objets, ... Tout fonctionne toujours selon un principe uniforme. C'est précisément en évaluant le concept d'exploitation qu'il devient clair si les développeurs de l'application ont suivi une approche génériquement applicable dès le départ, ou si l'application est simplement devenue un peu plus grande au fil du temps et que les fonctionnalités doivent être appelées différemment encore et encore parce qu'il n'y a tout simplement pas de fil conducteur dans l'application.

Le temps de réponse : combien de temps faut-il encore ?

Enfin et surtout, il y a le temps de réponse. L'application la plus appropriée (ensemble de fonctionnalités !) et la plus intuitive (fonctionnement !) perd énormément de sa valeur et de son acceptation par l'utilisateur si elle est lente. Et il ne faut pas grand chose pour être considéré comme lent. Du moins du point de vue d'utilisateurs souvent très exigeants. Le temps, c'est de l'argent. Et personne n'a envie de passer beaucoup de temps à attendre chaque jour devant l'écran jusqu'à ce que les données attendues apparaissent enfin devant moi. Quelques secondes sont déjà trop longues lorsqu'il s'agit d'une fonction que l'utilisateur appelle à quelques instants d'intervalle. L'inexistence d'une application est souvent la mort dans les ventes. "Heureusement", vous pouvez encore vous dire que "le produit concurrent n'est pas plus rapide non plus". Mais à notre époque, où les nouvelles technologies se remplacent presque chaque année, les largeurs de bande des réseaux et surtout de l'internet sont de plus en plus performantes, et les performances des ordinateurs doublent également tous les deux ans environ.

Comment une application logicielle atteint-elle un niveau élevé de convivialité ?

On parle souvent de conception centrée sur l'utilisateur ou de conception axée sur l'utilisateur. Nous entendons par là l'inclusion du futur utilisateur dans l'ensemble du processus de développement. Idéalement, cela commence par la première description de la future application, c'est-à-dire dans l'ingénierie des exigences : que doit réellement faire l'application (portée fonctionnelle) ? D'après notre expérience, une description purement textuelle de ces exigences est peu utile. En ce qui concerne les formulations en prose, les participants au projet sont rapidement d'accord. Mais le cœur du problème réside dans la conception de l'écran. C'est là que l'utilisateur s'assoit en fait devant l'écran et fait ce pour quoi l'application a été conçue. La meilleure façon de commencer est de faire de simples croquis sur un tableau blanc ou dans un programme de dessin approprié. A la rigueur, PowerPoint fera également l'affaire. Plus tard, ces dessins d'écran doivent être moulés en maquettes cliquables. Ainsi, les utilisateurs peuvent jouer avec eux et se faire une idée de la facilité d'utilisation. Ce n'est que dans une phase ultérieure du projet que la construction d'un prototype peut commencer. C'est là que la performance, c'est-à-dire le temps de réaction de la demande, entre en jeu pour la première fois. Bien entendu, cela ne devient réellement apparent (ou non) que lorsque la structure finale de la quantité (nombre plus important d'utilisateurs, stock de données réaliste, latence réelle du réseau, etc.

Il existe suffisamment de littérature sur le processus de développement d'une application logicielle et l'inclusion des utilisateurs. Nous nous abstenons ici de commencer par une liste de références. Toutefois, nous reviendrons volontiers sur les méthodes et processus de développement possibles et efficaces dans un prochain article. Restez à l'écoute.