Développer une app pour optimiser l’expérience desktop
Tout d’abord un peu de contexte.
LENDOPOLIS est un des 3 services de KissKissBankBank. C’est une plateforme web de crowdlending (ou financement participatif) : des projets d’entreprises sélectionnés sont proposés aux utilisateurs qui prêtent contre un rendement entre 3 et 10,5% par an. Afin d’optimiser le rendement et la sécurité des investissements, les projets sont triés et très peu sont proposés pour financement.
Un nouveau besoin auquel le desktop ne sait pas répondre
Ce tri drastique fait sur les projets reçus est nécessaire à la qualité de notre offre d’investissement. Cependant, il génère 2 failles dans l’expérience utilisateur :
- un phénomène de rareté voire de manque de projets mis en ligne et donc une très forte demande des utilisateurs. Le financement des projets boucle trop rapidement, le projet est souvent entièrement financé en quelques heures, avant même que certains utilisateurs aient pu investir. Il est très frustrant de se rendre compte que l’on arrive toujours trop tard !
- une fréquence des projets irrégulière. Il arrive donc des périodes de plusieurs jours sans activité sur la plateforme. Hors, si un nouvel utilisateur ne peut pas investir à ses premières visites et répète alors une expérience décevante, il ne reviendra plus.
Il nous fallait donc changer le rapport de force entre l’utilisateur et le produit.
Du constat de départ : les prêteurs ratent les prêts, s’est imposé notre prochain projet.
cible : les investisseurs
objectif : prêter vite, au bon moment
outil / support : une app mobile
Avec une app, ce n’est plus l’utilisateur qui est pro-actif et vient consulter le site, mais l’app qui le notifie au moment opportun. L’utilisateur est informé lorsqu’une activité mérite son intérêt. Il n’est donc pas grave que l’utilisateur se rende sur Lendopolis que quelques fois par semaine, tant qu’il ne ressent pas la frustration que rien ne se passe sur la plateforme ou pire, d’avoir raté le coche.
Un écran d’app n’est pas une page web responsive
Construire une expérience sur mobile, cela semble facile ! L’expérience responsive avait déjà été pensée et intégrée sur la plateforme web. Il pourrait donc suffire de reprendre les pages existantes, déjà parfaitement responsive et de les intégrer dans une app.
Evidemment ce n’est pas si simple. Les pages web sont surchargées, alors qu’un écran mobile supporte très peu d’infos si l’on ne veut pas altérer l’expérience.
Pour construire une expérience fluide et naturelle au sein d’une app, il est important de suivre la règle : un seul sujet, une seule action par écran.
Nous avons découpé, trié et ordonné le contenu de nos pages web puis nous nous sommes demandés :
- À quoi sert cette page?
- Que souhaitons nous que l’utilisateur y fasse ?
Et nous avons enfin construit ces étapes pour les intégrer dans une app.
Il vaut mieux passer par 3 écrans clairs et 3 taps plutôt qu’un seul écran surchargé sur lequel l’utilisateur ne comprend pas ce qu’on attend de lui, ne sait pas où cliquer. L’expérience utilisateur n’avait déjà plus rien à voir avec celle sur les pages responsive web de la plateforme.
Une fois les étapes de la navigation re-découpées, et les objectifs de chaque écran définis, s’en est suivi un jeu de ménage et de priorisation de l’information utile à chaque action.
Lorsque l’on développe une app qui touche à l’argent et plus encore à l’épargne de l’utilisateur, la pédagogie et les éléments de réassurance sont primordiaux et ne peuvent être éludés. Nous sommes aussi contraints légalement d’informer l’utilisateur sur les obligations réglementaires et les risques liés à ses investissements.
Une fois ces éléments intégrés sur les maquettes, il fallait être concis et faire comprendre autrement qu’avec des mots l’objectif de chaque écran, et c’est le rôle du design !
Un bon design remplace les explications.
Finalement, en supprimant les mots et explications inutiles et en pensant la page pour un objectif unique, nous avons optimisé l’expérience utilisateur. L’UX web a beaucoup à apprendre du mobile. Pourquoi surcharger des écrans web sous prétexte qu’il y a de la place ?
L’écran mobile contraint à la simplification et ainsi à l’optimisation du parcours.
A chaque fois que l’on commence à construire une page, qu’elle soit web ou mobile, il faudrait toujours se demander : Quand l’utilisateur arrive sur cette page, que va-t-il avoir envie de faire ? Ou va-t-il vouloir cliquer/taper ?
Une fois la maquette finalisée, il est nécessaire de vérifier que les objectifs sont tenus, que l’on ne s’est pas perdu en chemin, et que la page ne contient que le nécessaire.
Savoir limiter le scope
Une fois les maquettes des pages projet et du flow d’investissement finalisées, nous avions rempli l’objectif premier. Le périmètre de l’app à ce stade est-il suffisant ? ou manque-t-il encore des fonctionnalités à l’utilisateur pour pouvoir apprécier l’expérience et revenir ?
Au fur et à mesure de la création des écrans, nous avions constitué sans vraiment nous en rendre compte une liste interminable de besoins, qui à ce moment là semblaient tous absolument nécessaires : des push bien sûr, une inscription, une connexion, des réglages divers et variés, un tableau de bord des investissements, etc.
Mais nous avions aussi bien sûr une obligation calendaire de livraison. Il fallait donc limiter la taille de la livraison et donc le nombre de fonctionnalités présentes dans l’app, et ainsi … prioriser cette liste.
Avec le recul, il semble d’autant plus crucial de se contraindre à une période de développement raisonnable avant la première sortie pour éprouver le produit sur le marché rapidement. Il est ensuite plus aisé de corriger et d’orienter la v2 à la lumière des retours de la communauté.
Sortir l’app sur l’app store et juger de l’appétence des utilisateurs le plus tôt possible permet de choisir la bonne direction pour construire la suite.
Finalement, nous avons limité la v1 à l’expérience d’investissement seule puisque c’est la fonctionnalité première de Lendopolis. Mais nous avons en revanche intégré toutes les options (de consultation et de paiement) existantes sur desktop.
Aucune autre fonctionnalité annexe à l’investissement ne faisait partie de cette première version hormis le formulaire d’inscription. Bien qu’il ne soit pas nécessaire puisque cette app est un complément de la plateforme web et qu’elle ne peut se suffire à elle même, il était aussi important financièrement de pouvoir communiquer sur l’app.
Au delà de répondre à un besoin produit, l’app devient un nouveau canal d’acquisition potentiel.
Pour conclure …
Lorsque l’on construit une app qui vient en parallèle d’une plateforme web, il faut éviter le piège de reconstruire une même plateforme sur un support différent qui répondrait à des besoins identiques.
L’app répond à un besoin différent et construit un nouvel usage du produit.
La prochaine question sera pour nous : que faire des autres grandes fonctionnalités de la plateforme comme le tableau de bord des investissements par exemple intégrant les échéanciers, les statistiques, la répartition de prêts de l’utilisateur, etc. ? Continuons-nous à développer de nouveaux pans de la plateforme au sein de la même app ?
A la différence des plateformes web “couteaux suisses” qui concentrent de nombreux rôles, l’app serait-elle un “scalpel” qui se limite à remplir une unique fonction et répondre à un seul objectif ? Dans notre cas, cela pourrait être une app pour prêter et une autre app pour suivre le tableau de bord de ses investissements.
