Comment satisfaire vos utilisateurs lors de la publication d'une mise à jour majeure de votre application

Bonne clientèle

Il y a une tension inhérente au développement de produits entre l'amélioration et la stabilité. D'une part, les utilisateurs attendent de nouvelles fonctionnalités, des fonctionnalités et peut-être même un nouveau look; D'un autre côté, les changements peuvent se retourner contre eux lorsque des interfaces familières disparaissent soudainement. Cette tension est la plus forte lorsqu'un produit est modifié de manière dramatique - à tel point qu'il pourrait même être appelé un nouveau produit.

At CasFlotte nous avons appris certaines de ces leçons à la dure, bien qu'à un stade très précoce de notre développement. Au départ, la navigation de notre application se situait dans une rangée d'icônes en haut de la page:

Navigation dans Casefleet

Malgré la valeur esthétique de ce choix, nous nous sommes sentis quelque peu limités par la quantité d'espace disponible, en particulier lorsque nos utilisateurs consultaient l'application sur des écrans plus petits ou des appareils mobiles. Un jour, un de nos développeurs est arrivé pour travailler un lundi matin avec les fruits d'un projet de week-end inopiné: une preuve de concept de changement de mise en page. Le cœur du changement en déplaçant la navigation d'une ligne en haut de l'écran vers une colonne à gauche:

Navigation gauche de Casefleet

Notre équipe a trouvé le design fantastique et, après avoir ajouté quelques touches finales, nous l'avons publié cette semaine-là à nos utilisateurs en espérant qu'ils seraient ravis. Nous avions tort.

Alors qu'une poignée d'utilisateurs a immédiatement adopté le changement, un nombre substantiel n'était pas du tout satisfait et a déclaré avoir des difficultés à se déplacer dans l'application. Leur plus gros reproche, cependant, n'était pas qu'ils n'aimaient pas la nouvelle mise en page, mais qu'ils les avaient surpris.

Leçons apprises: le changement est bien fait

La prochaine fois que nous avons changé notre application, nous avons utilisé un processus bien différent. Notre idée clé était que les utilisateurs aiment être en contrôle de leur destin. Lorsqu'ils paient pour votre application, ils le font pour une raison et ils ne veulent pas que leurs précieuses fonctionnalités leur soient enlevées.

Après avoir terminé notre interface nouvellement conçue, nous ne l'avons pas simplement publiée. Au lieu de cela, nous avons écrit un article de blog à ce sujet et partagé des captures d'écran avec nos utilisateurs.

E-mail de changement de conception de Casefleet

Ensuite, nous avons ajouté un bouton à l'écran d'accueil de notre application avec un grand titre, une copie soigneusement conçue et un gros bouton orange invitant les utilisateurs à essayer la nouvelle version. Nous avons également noté qu'ils pouvaient revenir à la version originale s'ils le souhaitaient (pendant un certain temps en tout cas).

Une fois que les utilisateurs étaient dans la nouvelle version, les étapes nécessaires pour revenir en arrière se trouvaient à quelques clics dans les paramètres de profil de l'utilisateur. Nous ne voulions pas masquer le bouton pour revenir en arrière, mais nous ne pensions pas non plus qu'il serait utile pour les gens de basculer d'avant en arrière à plusieurs reprises, ce qui aurait pu être tentant si le bouton était immédiatement visible. En fait, un seul utilisateur est revenu au cours de la période d'acceptation d'un mois. De plus, au moment où nous avons basculé le commutateur et rendu la nouvelle version obligatoire, presque tous nos utilisateurs les plus actifs avaient basculé et nous avaient donné d'excellents commentaires sur la nouvelle version.

En plus des incitations intégrées à l'application que nous avons fournies pour le basculement, nous avons envoyé plusieurs e-mails informant les utilisateurs de la date exacte à laquelle le changement vers la nouvelle version serait rendu permanent. Personne n'a été pris au dépourvu et personne ne s'est plaint. En fait, la plupart des utilisateurs étaient extrêmement satisfaits du nouveau look.

Des défis intéressants

Néanmoins, il est important de noter que publier une mise à jour de cette manière n'est pas gratuit. Votre équipe de développement devra gérer deux versions distinctes de la même base de code et vous devrez également résoudre des problèmes complexes concernant la manière dont les versions sont envoyées aux utilisateurs finaux. Vos équipes de développement et d'assurance qualité seront épuisées à la fin du processus, mais vous conviendrez probablement que l'investissement en temps et en ressources était intelligent. Sur les marchés logiciels hyper-concurrentiels, vous devez satisfaire les utilisateurs et il n'y a pas de moyen plus rapide de les rendre mécontents que de changer soudainement votre interface.

2 Commentaires

  1. 1

    Generally, when we update new application we make sure that old is still in the active mode until people upgrade it to newer version. Any bad experience will force user to optout from your services. It is very crucial for business to have that sence of awareness before launching a new app.

    In addition, ask people to give feedback. New launch is the time where people love to share their thoughts about the app. If they have something new in mind then they will share with you. It will create new opportunity for your developer to add that feature people suggesting.

    Merci

  2. 2

    When we send emails to our customer regarding major changes to the website. We keep them accessing the old website as well if they want. It makes them comfortable while browsing it. Also, some user might not like your new design so this kind of users can swift to the older version easily.

Que pensez-vous?

Ce site utilise Akismet pour réduire les spams. Découvrez comment sont traitées les données de vos commentaires..