Category : Ergonomie logicielle

in Agile, Ergonomie logicielle

Agile-UX – un sujet sur les lèvres de plusieurs

À Agile 2011, j’ai assisté à plusieurs sessions qui traitaient d’Agile-UX, un sujet qui est de plus en plus présent dans les conversations de la communauté UX. Il y a plusieurs conversations sur le sujet puisqu’il n’y a pas encore de propositions faites qui permettent de bien intégrer les pratiques d’UX à un projet en mode Agile. Parmi les sessions, trois ont été particulièrement révélatrices pour moi. De ces séances je retiens des éléments qui me permettront de progresser dans ma pratique, mais surtout qui pourront aider les praticiens qui sont dans la même situation et qui n’ont pas eu l’opportunité de participer à la conférence;

  • Pour faciliter l’intégration des travaux UX à un projet Agile, il est d’abord utile de mettre en place une stratégie d’intégration. Ceci afin d’apporter la présence et l’expertise UX adéquate au contexte du projet. Que ce soit en faisant d’abord un partage de connaissance entre les développeurs et les spécialistes UX pour que chacun ai des connaissances suffisantes de l’autre domaine pour faciliter les conversations et la conception du travail, en énumérant au début du projet les caractéristiques intrinsèques au logiciel (qualités techniques) et les caractéristiques extrinsèques du logiciel (qualités des interfaces et interactions) ou en nommant un champion UX au sein de l’équipe de développement et un champion technique au sein de l’équipe UX afin de toujours garder en tête les considérations qui relèvent de l’autre domaine.
  • Pour réduire la pression sur le Product Owner de conserver une vision affaire autant qu’un vision utilisateur du logiciel à développer, il a été suggéré de mettre en place une “équipe Product Owner” qui partage les responsabilités de maintenir la direction du logiciel. L’”équipe Product Owner” est composée d’un représentant affaire et un représentant des utilisateurs et ensemble ils collaborent à déterminer l’orientation du logiciel qui sera développé.
  • Enfin, pour faire en sorte que les équipes Scrum développent le bon logiciel et du logiciel utile à chaque itération, les présentateurs proposaient de revoir le concept d’itération et de récit utilisateur (user story). La proposition voulait qu’un projet en mode Scrum oriente la composition du carnet de produit (product backlog) vers une suite d’activités réalisées par un utilisateur pour atteindre ses objectifs, et non plus comme une liste de fonctionnalités à réaliser. Le logiciel développé est ainsi plus cohérent puisque la séquence de récit utilisateur qui seront réalisés reflètera la réalité des utilisateurs.

Les propositions amènent présentement une intégration à différents niveaux entre les pratiques Agile et UX. Cependant, ce sont des pistes qui adressent des difficultés rencontrées par les présentateurs (et même plusieurs participants aux sessions) qui tendent vraiment à former des équipes de projets qui contribuent à réaliser de meilleurs logiciels en prenant en considération autant la réalité des utilisateurs, que celle des différents équipiers présents à la réalisation du projet.

La réflexion sur ces propositions continuera certainement pour moi après la conférence, puisqu’il apparait de plus en plus important d’unir les efforts de tous pour créer le bon logiciel.

in Ergonomie logicielle

Pour acheter cette citrouille, vous devez me fournir un code à 4 chiffres…

Imaginez la situation, vous roulez sur un petit chemin et croisez un marchand de citrouilles. Vous vous arrêtez pour en acheter une belle grosse que vous allez décorer pour l’Halloween. Vous venez pour prendre celle que vous avez choisie et une conversation comme celle-ci débute:

marchand : Vous devez fournir un code de 4 chiffres pour pouvoir acheter cette citrouille…
vous: humm!?! mais pourquoi? Je veux seulement acheter cette citrouille.
marchand : C’est pour que lors de votre prochaine visite, je puisse vous reconnaître et vous vendre une citrouille qui ressemble à celle que vous achetez cette année. Vous savez, c’est de la vente plus personnalisée…
vous: humm!?! mais je passais ici par hasard. Je ne sais pas si je reviendrai par ici l’an prochain pour acheter une citrouille.
marchand : d’accord, alors donnez-moi votre adresse postale. Je pourrai vous faire parvenir des offres spéciales sur des produits connexes à la citrouille que vous achetez aujourd’hui.
vous: hummm!! je voulais seulement acheter cette citrouille. Gardez-la, j’irai au marché près de chez moi, c’est plus simple et je n’ai pas à donner de code de 4 chiffres ou mon adresse.
marchand : mais monsieur, je tentais seulement de vous offrir une meilleure expérience d’achat.
vous: dommage pour vous parce que je ne ferai finalement aucun achat. Merci! Au revoir!

Cette situation semble absurde, mais pourtant plusieurs sites web nous la font vivre régulièrement. Le problème n’est pas de demander aux visiteurs de s’identifier (ou de fournir des informations personnelles) pour faire un achat. C’est plutôt d’empêcher complètement d’effectuer l’achat (ou l’action désirée par l’utilisateur) tant qu’il ne s’est pas identifié.

Je considère que c’est une mauvaise pratique parce que ça nuit au but premier que s’était fixé le visiteur de votre site; faire un achat d’un bien ou produit qu’il désire. Je propose plutôt de laisser le visiteur choisir s’il veut s’identifier (ou se créer un compte utilisateur sur votre site) au moment de faire son achat. Ainsi, les visiteurs réguliers ne seront probablement pas bloqués par l’idée de s’identifier, tandis que les visiteurs occasionnels (ou même unique) pourront quand même procéder à faire leur achat.

Pour quelles raisons avez-vous vraiment besoin des informations personnelles du visiteur ? Est-ce que le gain obtenu en ayant ces informations compense pour les pertes de ventes potentielles ?

Alors, est-ce que votre site facilite ou ralentit la vente de citrouilles ?

in Développement logiciel, Ergonomie logicielle

The next big thing is Usability

Usability is something most teams outside the Apple circle do not care about.

However, luckily enough (or sadly enough, depending on how you see it), developers are keyword-addicts, and some things suddently start looking cool as soon as they are trendy. Nobody cared about the business logic before, but now that  Domain Driven Design is considered the new, cool thing, some developers start putting their effort into the domain, instead of the technical details.

Now, it looks like that two of the new, trendy architectural approaches will help us regarding usability, as they are focusing on user interactions :

  • CQRS : User Commands are an important aspect of the architecture, that defines the transaction boundaries of the system
  • Data Context Interaction : DCI is a vision to capture the end user cognitive model of roles and interactions between them.

Will these trends save our software ? ;-)

in Ergonomie logicielle

Usability lessons learned: Who’s driving who?

Tax season. What better way to welcome the wamer weather than filling out tax forms. Forget about the return of birds, the blossoming of trees, driving with the windows down or the reappearance of short skirts. Spring calls for serious work. To make matters worst, this year I could not manage to find out how much interest I payed on my student loans during the past year.

I wasn’t able to do it through my bank’s online service even though I remembered doing so  the previous years. I felt pretty bad about myself, considering I’m a supposed to be an IT specialist and all.

I called the customer support in shame only to be told that my information was indeed available online. I felt even worst. The very nice lady on the phone walked me through these very precise steps :

1- Go into my monthly statements
2- Select the account from which I pay my loans
3- Select the month of December
4- Go to the bottom of my statement

This is where my information was hiding all along ?!? How intuitive, right? You would have figured that one out, right ? You might wonder why someone would decide to hide this info this deep since it makes no sense at all right? Well it does in a certain way. If you look at the 4 steps above and translate them into an SQL query, it does look more natural. It would look something like this :

Select SUM(interests) from Account where date >= 2009 and date <=2010.

Makes more sense now ? This is what happens when software is developed backwards. When the back end drives the front end. Instead of having the natural user interactions dictate the way it should be implemented, we have the implementation dictating the interactions.

Take radios as another example. Just like one of my university teachers used to point out, most users could not care less about radio frequencies. Yet they had to learn about them in order to use a radio properly. Even though it was less natural to use as a result, it was more cost efficient to bind the user directly to the choice of frequency without an abstraction layer.

When designing interfaces, a good practice would be to always ask yourself : Who’s driving who ? Is the implementation driving the interaction or vice versa?

In other words, are you trying to fit the tool to the user or fit the user to the tool ?

For more on this subject, I would invite you to read this article

Nicholas Lemay

in Ergonomie logicielle

Usability lessons learned : The real cost of bad usability.

Confoo 2010

Come join us @Confoo for a Scrum simulation using paper prototyping!

Let’s take a very simple example of a very commonly used software that most people use during their work day : the Web browser.

This serves a good example because a web browser is well known by most people and rather simple to use(or should be). For this example we’ll use Mozilla Firefox and the stats published on their website. For everything else we’ll make the estimates as conservative as can be while still remaining realistic.

According to it’s own website*, FireFox is currently being used by 270 million users. For the sake of keeping this example easy, we’ll make the very conservative estimate that only 10 percent of them use it for long period of times at work. That makes this a total of 27 million users. For these few heavy users, let’s pretend that this browser is very easy to use and that users only waste a grand total of a measly 30 seconds a day figuring out things they want to accomplish compared to if it were optimally designed for them. For the sake of this conservative estimate, let’s pretend the average income of these workers is only 10$ per hour and that they work 5 days a week and only do so for 45 weeks per year.

For our example, we will be using the following formulas

Total time wasted in a year in seconds(182,250,000,000) = time wasted per day per employee(30 seconds) * work day per week per employee(5 days) * weeks worked in a year per employee(45 weeks) * number of employees using FireFox(27,000,000)

Total Wasted time in hours(50,625,000) = Time wasted in seconds(182,250,000,000) / Number of seconds in an hour(3600)

Total cost in a year of wasted time due to bad ergonomics(500,625,000$) = Wasted time in hours(50,625,000) * Hourly rate of employees(10$)

This very conservative example should make it clear to anyone that a very small flaw in the ergonomics of a software that is heavily used by a large number of users can have an enormous productivity cost and produce large wastes of money for employers. A very large part of this waste could be prevented or at the very least diminished by the use of proper software ergonomics/usability practices. In following articles in this series, we will publish means and method to help through proper interface design.

*http://weblogs.mozillazine.org/asa/archives/2009/05/firefox_at_270.html

in Agile, Ergonomie logicielle

Ergonomy lessons learned : Ergonomy sells.

Ergonomy lessons learned: Ergonomy sells.

Ergonomy lessons learned: Ergonomy sells.

This week, the Montreal auto show is being held at the Palais des congrès. For many people, it’s their first peek at many of the cars they will be shopping for during the year.

While listening to the people voicing their opinions while trying out the different cars, it it obvious to the outside eye that a car’s interior design, it’s “ergonomics” could very well be the deal breaker for many potential customer.

If you go to any car show you will be able to see a pattern similar to this one :

1- Subject opens the door and sit down.
2- Subject looks around, commenting on the color, space and general feel the car gives them.
3- Subject starts fiddling around with the controls the seat adjustment, and the ever popular cup holders and i-Pod plugs.
4- Subject gives the exterior another look and either

A- gives the exterior another look

B- Gives the trunk or backseat a look

C- Gives the specs and pricing sheet a look

A small percentage only will go to C. Actually a lot of people won’t even go through with the all steps.

From simply sitting in the car, getting in and out and getting an overall “feel” on the car’s interior design, a lot of people either walked away from the car or stayed to look
further at the car’s spec sheet containing the pricing, the security options, the fuel consumption, etc. Features on which you would expect most rational people to base
their decision to make a 15K$ + investment upon. Yet the cup holders, the I-Pod plugs and the positioning of the defrost buttons all came into play prior to all of these costly
car features.

People will not care how well something is built if it is not appealing to them first and easy to use. Car designers and software designers alike are victim of this reality.
They say you do not judge a book by it’s cover. In Montreal that day, there sure was a lot of people judging a car by it’s interior.

-Nicholas Lemay

in Ergonomie logicielle

PokerStars, tu déçois mes attentes…

Le Texas Hold’em Poker est très à la mode, et je n’ai pas pu résister à la tentation de m’inscrire à PokerStars. J’étais tellement motivé de m’inscrire que j’ai passé par dessus le piège que m’a tendu PokerStars : “* – Optional fields”.

PokerStars registration process with usability problems

Les champs optionnels sont marqués d’un astérisque alors que le standard est plutôt de marquer ainsi les champs obligatoires. En respectant mes habitudes, j’ai d’abord rempli tous les champs marqués d’un astérisque. C’est seulement à l’affichage d’un message d’erreur me demandant d’inscrire une ville que j’ai réalisé qu’ils brisent le standard.

Auriez-vous fait la même erreur dans le même contexte?

in Ergonomie logicielle

Smells d’équipe qui n’intègre pas les pratiques d’utilisabilité;

Durant le développement de logiciels, les équipes peuvent prétendre qu’ils appliquent des bonnes pratiques d’utilisabilité à leur projet. Par contre, il y a des odeurs, des habitudes, qui indiquent le contraire. Je vous énonce ici quelques-unes de ces odeurs que j’ai rencontrées.

Si vous reconnaissez certains comportements de votre équipe, n’ayez pas peur! Vous pouvez éliminer ces odeurs. Par la suite, vous verrez que rapidement vos utilisateurs seront plus satisfaits des logiciels que vous produisez.

Odeurs

  • développer sans feedback des utilisateurs
  • développer basé sur des design d’interfaces faites par des concepteurs graphiques
  • développer une interface-utilisateur orientée développeur/debug
  • rédiger de la documentation d’utilisation exhaustive
  • accepter des excuses…
    • …de la part des designers pour ne pas travailler de facon incrémentale
    • …de la part du PO pour ne pas prendre les utilisateurs en considération
    • …de l’équipe de développement pour négliger les pratiques d’utilisabilité
in Agile, Ergonomie logicielle

Les pratiques d’utilisabilité, c’est Agile ?

Réponse simple, oui!

En tant que tel, il n’y a pas de mécanismes dans les pratiques d’utilisabilité qui ne permettent pas de s’exécuter dans un contexte Agile. Comme ce sont des pratiques, le contexte d’application revient au choix de l’équipe.

Autant les pratiques d’utilisabilité que les méthodes Agiles font appel à des rétroactions fréquentes provenant des utilisateurs. Ceci permet de s’assurer que les interfaces respectent les critères d’utilisabilité, qu’elles permettent aux utilisateurs d’atteindre leurs objectifs et qu’elles répondent bien aux attentes énoncées par le PO. Ensuite, la conception et la validation des interfaces utilisateurs s’effectue de façon itérative et incrémentale. Cette approche contribue à augmenter l’efficacité et l’efficience des utilisateurs puisqu’elle intègre à chaque itération des considérations d’utilisabilité reflétant la réalité des utilisateurs visés par le logiciel.

Pour bien arriver à arrimer ces pratiques, il y a nécessité de faire un peu d’éducation à tous les participants du projet. Ceci afin que chacun voit et comprenne qu’il y a possiblité de travailler de façon itérative et incrémentale, et ce en ayant un rythme soutenu et soutenable.

Pour le PO

  • voir de la valeur dans la conception de maquettes et l’exécution de tests d’utilisabilité
  • associer de la valeur aux éléments d’expérience utilisateur
  • ajouter les facteurs de risques concernant l’utilisabilité à la vision du projet

Pour l’équipe de développement

  • intégrer les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité aux itérations
  • questionner l’utilité du manuel d’utilisation du logiciel. Considérer qu’un manuel exhaustif ne peut pas remplacer une bonne interface utilisable

Pour les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité

  • élaborer un squelette des interfaces-utilisateurs/navigation durant le sprint de démarrage (sprint 0)
  • participer aux sprint plannings/retro pour conscientiser l’équipe aux problèmes qu’il anticipe ou pour évaluer le travail fait
  • travailler de facon itérative et incrémentale
  • intégrer l’équipe de développement à chaque itération

Bref, ce qu’il faut en comprendre c’est que tous ceux qui contribuent au projet doivent s’y commettre. Nous ne questionnons plus le fait que les développeurs sont des cochons du Scrum. Il faut maintenant voir les concepteurs d’interfaces/d’interactions/spécialiste en utilisabilité aussi comme des cochons qui se commettent au succès du projet.

in Ergonomie logicielle

en réaction à How Test-Driven Development Increases Overall Usability

Hier soir, en lisant des articles sur l’utilisabilité, j’en ai trouvé un qui semblait initialement intéressant. Le titre m’a accroché; How Test-Driven Development Increases Overall Usability. Comme c’était la première fois que je voyais les deux sujets abordés dans un même article je n’ai pas pu m’empêcher de le lire.

Je vous laisse le temps d’aller le lire, revenez-moi après!

Suite à la lecture j’ai comme un sentiment de vide. J’ai l’impression qu’on n’aborde pas le thème d’utilisabilité et que l’article ne m’a pas livré ce qu’il me promettait. L’impression qu’on lance des concepts d’utilisabilité, sans pour autant décrire le lien avec TDD, et ce, seulement pour respecter le titre. Bref, je ne comprends toujours pas comment le TDD peut améliorer l’utilisabilité d’une application. Après la lecture, le comprenez-vous, vous?