3 approches pour migrer un site vers une ergonomie repensée

Sur le web, les choses vont vite, le concurrents bougent vite, et les sites évoluent constamment. Le risque à chaque nouveau changement de l’ergonomie est de perdre des utilisateurs qui ne s’habitueraient pas à la nouvelle version. Comment alors éviter les pertes quand on refont un site ?

Première approche : le big bang

 

L’approche la plus simple à mettre en oeuvre est tout simplement le big bang. C’est la méthode où l’on passe de l’un à l’autre d’un seul coup. C’est souvent l’approche utilisée, et ce pour plusieurs raisons. En effet, souvent dans le cadre de l’énorme projet qu’est la migration d’un site web, la transition est souvent laissée de coté, voire complètement oubliée. Le risque de la transition n’est tout simplement pas vu car la supériorité de la nouvelle version apparait évidente à l’équipe projet.

Clairement, cette méthode a un avantage clair au niveau de la simplicité de la mise en oeuvre : passage de l’un à l’autre, et voilà.

Par contre, c’est la méthode la plus risquée. Il y a quelques années, Digg a complètement changé en suivant cette méthode. Pas loin de 60% des utilisateurs ont fini par quitter Digg pour un autre aggrégateur. Même histoire pour Gawker, dont la nouvelle version a fait beaucoup de bruit et qui a perdu dans la foulée 40% de ses utilisateurs. En effet, ce type de transition pose avant tout problème pour les sites avec des habitués, le nouveau venus n’ayant pas la nostalgie de l’ancienne version.

Ceci étant dit, cela peut très bien marcher, comme cela s’est fait pour le site TechCrunch US, donc la transition n’a pas posé de gros problème malgré un gros public d’habitués.

Deuxième approche : le big bang optionnel

 

Assez rare, cette approche est très sûre. Elle consiste à donner le choix aux utilisateurs entre utiliser la nouvelle version et l’ancienne. C’est la méthode qu’a suivi Google pour toutes ses applications : gmail, google docs, google analytics… Cela a permis de faire transiter petit à petit le traffic de l’ancienne version de l’application vers la nouvelle.

Ce genre de transition aura tendance à mieux se passer : les premiers utilisateurs à migrer seront aussi les plus ouverts d’esprit. L’utilisation faite par ce groupe de power users permettra de lisser la nouvelle version et d’en faire disparaitre les défauts les plus flagrants.

L’inconvénient principal de cette approche et sa difficulté technique : il doit être techniquement possible pour tous les utilisateurs d’utiliser l’une ou l’autre des deux versions… Pas évident du tout à faire, si les solutions backend sont complètement différentes. Cette méthode est donc à utiliser quand la transition est risquée – et que le budget développement est conséquent

Troisième approche : la migration feature par feature

 

Au lieu d’un passage direct d’une version à l’autre, on y vient doucement, feature par feature. Cette méthode est la plus simple et la plus sûre, car concrètement, ce n’est pas tant une migration qu’une évolution douce du site. C’est ce qu’Amazon a fait depuis le début de son existence…

L’avantage très clair est que comme la transition est longue, il y a peu de risque de donner l’impression à l’utilisateur que « rien ne sera plus comme avant ». L’inconvénient est la durée de la transition, parfois plusieurs années… De plus il sera difficile de faire des changement réellement radicaux, comme un changement de design. Ou en tout cas cela prendra plus de temps…

A faire quand le coeur du site reste le même mais que l’évolution doit se faire continuellement.


 Appili est un service qui propose des tests utilisateurs en ligne à partir de 39,99 € pour un test. Si vous voulez en savoir plus : cliquez ici

Posté le par Yannick d'Appili dans Ergonomie des sites web 2 commentaires