Le blog de Pascal Magnenat

Comment concevoir une application iPhone pour les clients des CFF qui soit plus utilisable que l’application originale? Lors d’un atelier d’ergonomie récent, j’ai proposé aux participants d’expérimenter la conception d’une application alternative en utilisant une approche centrée sur l’usage (user centered design). La démarche nous a conduit loin de la voie empruntée par les CFF.

Comme moi, vous faites peut-être partie des utilisateurs frustrés par l’application iPhone des CFF. De cette frustration sont nées 2 idées:

• réaliser une enquête en ligne sur ce qui me semblait une des faiblesses de l’application: la prévisibilité des commandes (cf. mon papier intitulé “les CFF sur l’iPhone: inutilisable sur toute la ligne?“);
• concevoir une application alternative selon une approche propre à garantir une application ergonomique, adaptée aux usages.

J’ai récemment animé un atelier d’ergonomie dans le cadre du groupe SwissW2 - Merci Sandrine de m’avoir offert cette chouette opportunité! Cet atelier a été organisé 2 fois, avec 2 groupes de participants différents.

L’atelier, intitulé “rendre une application iPhone ou mobile ergonomique”, avait pour ambition de

• donner un aperçu des activités qu’il est recommandé d’intégrer dans le processus de développement pour assurer une bonne expérience utilisateur.
• esquisser les contours de ce que pourrait être une application iPhone conçue selon la méthodologie présentée.

Cet atelier était donc une bonne occasion de construire une application iPhone destinée aux usagers des CFF. Serait-il possible de faire mieux que l’application existante en utilisant une approche centrée sur les usages (user centered design)?

Activité 1 - Identifier les profils des utilisateurs

Avant de se lancer avec enthousiasme dans la conception de l’interface, il est essentiel d’identifier les profils des utilisateurs. Ce travail devrait toujours se faire sur la base de données collectées sur le terrain, même si l’étude de terrain est limitée: on ne peut en effet raisonnablement partir de l’hypothèse que les profils des concepteurs recouvrent les profils des utilisateurs cibles.

Dans le cadre de l’atelier, pour des raisons pratiques, nous avons fait ce que je déconseille au paragraphe précédent! Nous nous sommes fondés sur certains aspects des profils des participants à l’atelier. Nous avons donc pris le risque de ne pas identifier tous les profils pertinents et de concevoir une application qui réponde avant tout aux besoins des participants.

Une collecte de données sur le terrain, par observations et interviews, aurait permis de rassembler des informations précieuses sur les utilisateurs et leurs usages, en particulier:

• leurs connaissances du réseau (savent-ils, par exemple, que pour aller de Lausanne à Berne, ils vont passer par Fribourg?)
• la fréquence d’utilisation d’une même ligne: on peut imaginer que les utilisateurs qui prennent tous les jours le train pour aller de Lausanne à Genève connaissent les horaires par coeur mais est-ce bien vrai? quelles sont les exceptions?
• le type de voyages: même trajet tous les jours, trajets différents mais dont le point de départ est identique, etc.
• les stratégies présidant aux choix des trains: l’horaire de travail, le taux d’occupation des trains, le type de train (sans arrêt, avec wifi, train non pendulaire, etc.), l’heure d’arrivée, etc.

Bien sûr, toutes les caractéristiques des utilisateurs ne sont pas pertinentes dans le contexte du développement de l’application: que les utilisateurs aient des cheveux foncés ou clairs - ou pas du tout comme certains -, qu’ils fassent du vélo d’appartement ou que ce soient des fans du “Dr. House” n’a vraisemblablement pas d’incidence sur les usages qu’ils font du train. Mais, il n’est pas toujours facile d’identifier a priori lesquelles des caractéristiques peuvent avoir de l’impact sur les usages. Ne pas avoir peur de ratisser trop large et de collecter des données qui ne seront pas forcément exploitées par la suite. C’est toujours mieux que le contraire!

Voici la synthèse des profils auxquels nous avons pensé:

• le pendulaire: c’est à la fois le profil qui m’est venu immédiatement à l’esprit en préparant l’atelier et celui qui a également été cité en premier lors des 2 sessions de l’atelier. Est-ce un indice d’un rôle principal? à suivre…
• l’utilisateur qui fait régulièrement les mêmes voyages
• l’utilisateur qui fait régulièrement des voyages d’un jour, en partant du même point de départ (son domicile par exemple)
• l’utilisateur qui fait des voyages dont les points de départ et d’arrivée sont différents

A titre d’exemple, je décris les caractéristiques de 2 des 4 profils identifiés. Ces caractéristiques sont une synthèse de mon analyse et des idées exprimées au cours des 2 ateliers.

Le pendulaire

• Il fait tous les jours (ouvrables) le même voyage: il prend le même train (presque) tous le matins et rentre le soir dans une plage horaire donnée.
• Il connaît les horaires et les voies (presque) par coeur. C’est plus important pour lui d’être informé des situations inhabituelles: perturbations du réseau, changement de voie, retard du train.
• Il profite du voyage pour travailler, lire, écouter de la musique, échanger avec des connaissances (collègues de travail ou autres pendulaires).
• Il se renseigne (parfois) sur les intentions des autres (quel train penses-tu prendre ce soir?) de façon à pouvoir ne pas faire le trajet seul.
• Il peut être important pour lui de ne pas arriver au-delà d’une certaine heure au bureau. Le pendulaire, surtout s’il travaille à temps partiel et/ou qu’il effectue par ailleurs d’autres voyages que les voyages maison-travail avec les CFF, peut être intéressé à déterminer quel est le titre de transport le plus avantageux pour lui.
• Le pendulaire n’achète en principe pas de billet de train
• Le pendulaire effectue des aller-retour
• Le pendulaire ne prépare pas ses voyages

Ce qui est intéressant de noter, c’est l’application des CFF ne répond que partiellement aux caractéristiques du pendulaire:

• Il n’est pas possible d’afficher immédiatement les horaires sans effectuer une requête ou actualiser les résultats d’une requête passée.
• L’application n’a pas de dimension sociale.

L’utilisateur qui fait régulièrement des voyages d’un jour, en partant du même point de départ

• Ce voyageur ne connaît pas (nécessairement) les horaires par coeur.
• Les voyages sont constitués d’aller-retour
• Le voyageur dispose vraisemblablement d’un abonnement (général ou demi-tarif).
• Le voyageur peut être amené à acheter des billets
• Le voyageur peut autant chercher des trains partant à partir d’une certaine heure ou arrivant avant (ou après?) une heure donnée.
• Le voyageur a une bonne connaissance du réseau
• Le voyageur peut vouloir éviter certains types de train pour différentes raisons: temps, sécurité, confort

Activité 2 - Définir les profils retenus pour l’application

Avoir identifié 4 profils d’utilisateurs n’implique pas forcément qu’il faille développer une application qui réponde aux besoins de ces 4 profils. Pourquoi ne pas par exemple imaginer une application destinée spécifiquement aux pendulaires si les besoins de ceux-ci sont très particuliers? L’important, c’est que

• l’application soit vraiment adaptée aux profils pour lesquels elle a été conçue

• l’utilisateur puisse clairement comprendre à quels besoins l’application répond. Si l’application n’était conçue que pour les pendulaires, il ne serait par exemple pas approprié qu’elle se nomme “Horaire CFF”.

Dans le cadre de l’atelier, nous avons retenu les 2 profils décrits en détails ci-dessus: le pendulaire et le voyageur qui fait régulièrement des voyages d’un jour, en partant du même point de départ.

La suite au prochain épisode. N’hésitez pas à me faire part de vos questions si quelque chose n’est pas clair!

Crédit photo: © Photo CFF