Category : Ergonomie logicielle

En tant que développeur, pensez-vous qu’un ergonome peut vous aider à rendre le code plus simple?

J’ai souvent été en contact avec une espèce étrange que nous appelons ergonome Web. Mais je n’avais jamais vraiment compris l’impact qu’ils peuvent avoir non seulement sur l’expérience utilisateur, mais également sur le travail du développeur.

Dans mon mandat actuel, l’interface utilisateur est créée au fur et à mesure. Les premières versions de celle-ci n’avaient pas fait l’objet d’une réflexion ergonomique. Nous avions donc développé le code en ce sens. Ce faisant, nous avions 9 concepts de boutons qui étaient repris dans tout le logiciel.

Continue Reading

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.

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 ?

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 ? ;-)

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 stateme
nt

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