Nous partageons régulièrement des astuces avancées de création d’appli pour les mettre à la portée de tous. Vous en connaissez peut-être certaines … d’autres devraient-vous surprendre.
La création d’une application mobile est devenu un enjeu stratégique pour beaucoup d’entrepreneurs.
C’est donc primordial de concevoir une appli d’excellente qualité. Qui réponde aux attentes des utilisateurs finaux. Tout ça en se démarquant.
Ce n’est pas toujours simple.
Pour vous aider à lever les zones d’ombre, chez Sirup lab, nous partageons avec vous notre méthode.
Celle que nous mettons en pratique avec nos clients. C’est-à-dire les bonnes astuces qui fonctionnent.
Nous espérons qu’elles vous feront gagner du temps. Et surtout, qu’elles vous aideront à prendre la bonne direction.
Que ce soit sur iOS ou Android, créer une application mobile passe toujours par 3 étapes :
Dans un 1er article, nous abordons la phase de recherche. C’est l’étape indispensable pour prioriser et documenter vos idées. Elle permet aussi d’obtenir une estimation précise du coût de votre produit.
Dans un 2ème article, nous vous parlons de la phase de conception. Elle sert à définir et choisir la meilleure solution. C’est aussi à ce stade qu’on peut tester et améliorer son prototype.
Et la dernière étape, c’est celle de la réalisation de l’application.
Dans ce dernier article, nous partageons avec vous les bonnes astuces associées. Comme pour les phases précédentes, il y en a 3.
Lorsque cette phase commence, vous avez déjà un prototype fonctionnel.
Vous l’avez testé auprès de vos utilisateurs finaux. Et son utilisabilité est vérifiée.
L’objectif ici : limiter les retards et respecter le budget. Mais aussi éviter un décalage trop important entre votre prototype et l’appli finale.
La clé de cette dernière étape peut se résumer en 2 mots : avancer progressivement.
À ce stade, vous avez déjà une conception validée et estimée.
La difficulté c’est de créer deux applications en même temps : une pour iOS et une pour Android. Les 2 équipes en charge des projets peuvent être bloquées sur le même problème.
Tester deux applications peut aussi prendre beaucoup de temps.
La question qui se pose c’est : comment créer les applications sur iOS et Android le plus rapidement possible et le moins cher possible ?
Plusieurs possibilités s’offrent à vous.
Pour être plus efficace, c’est intéressant de valider et d’affiner son produit sur une seule application. Et donc de prioriser l’une d’entre elles.
Il y a 3 manières de prioriser.
La première option, c’est de commencer par l’application la moins chère.
Pour bêta-tester, corriger et affiner. La deuxième application bénéficiera des améliorations de la première.
La seconde option, c’est de prioriser celle qui peut générer le plus de revenus. C’est donc souvent sous iOS.
Et la dernière, c’est de commencer par celle qui aura le plus d’audience.
Quelque soit l’option choisie, une fois la première appli prête, vous pourrez la passer en bêta-test. Avec les retours des utilisateurs, elle sera corrigée et affinée.
Elle pourra ensuite être mise à jour et servir à la deuxième application. La seconde aura donc besoin de moins de corrections. Voire même, avec un peu de chance, d’aucune correction.
Son développement sera plus rapide. Il pourra d’ailleurs être lancé quand les deux applications seront prêtes.
Pour planifier l’ensemble de ce travail, vous pouvez utiliser un outil comme Gitlab. Il permet de créer les différentes tâches de développement, de suivre leur évolution et de répertorier les bugs. C’est aussi très utile pour optimiser la collaboration entre les développeurs.
Il s’agit ici de monter les deux applications à partir d’un seul et même code. Plusieurs technologies permettent de le faire.
React Native est l’une d’entre elles.
La technologie est très solide. Que ce soit en terme de performance (rapidité d’affichage, fluidité) ou de stabilité.
Elle a aussi l’avantage d’évoluer régulièrement et de ne pas stagner. Elle est d’ailleurs utilisée par de grands acteurs comme Uber ou Airbnb.
Elle permet de créer des applis de haute qualité. Avec des interfaces utilisateurs simples et efficaces.
Par contre, l’animation et les transitions sont moins poussées que sur une application dite native, c’est-à-dire développée spécifiquement pour iOS ou Android.
Et donc l’expérience utilisateur et les interactions sont plus limitées.
Chez Sirup lab, nous l’utilisons principalement pour des startups early stage. Sur la création d’une première application mobile.
Notamment parce que ça permet de réduire les coûts et d’être plus rapide. Sans pour autant mettre de côté la qualité.
Nous vous conseillons de construire votre produit étape par étape. Principalement pour garder le contrôle sur les coûts.
À ce stade, il s’agit de déouper le design en séquences. Concrètement, c’est segmenter le parcours utilisateur en plusieurs petites trajectoires.
Les séquences reprennent les user stories identifiées dès la phase de recherche.
L’idée c’est de prioriser les séquences qui sont essentielles pour les utilisateurs. Car si le développement de l’application s’arrête (par exemple pour des questions de budget), le produit est fonctionnel.
Ça permet de donner du sens à chaque étape du développement. Et de tester et valider en continu.
C’est aussi rassurant de se dire qu’à tout moment, le produit est prêt.
Pour chaque séquence, on prend la partie du design correspondante. Et on l’adapte pour qu’elle soit entièrement autonome.
Si on prend l’exemple de Netflix, la séquence prioritaire c’est de visionner un film. Si on peut faire ça, l’application est fonctionnelle.
Il faut donc pouvoir accéder à une liste de films. Et avoir la possibilité d’en sélectionner un. Si cette séquence est développée, l’outil est prêt.
Tout ce qui concerne le filtrage par catégorie, les suggestions, l’accès à un compte personnel, … sont autant de séquences secondaires. Elles sont ajoutées au fur et à mesure.
Prenons un autre exemple pour que ce soit tout à fait clair.
Chez Sirup lab, nous avons récemment développé une application de rééducation physique pour un client. Il s’agit de proposer aux utilisateurs de suivre un entraînement sportif.
Ici, la séquence prioritaire c’est regarder une vidéo avec un mouvement à faire. Et pouvoir le reproduire.
A contrario, s’identifier à l’aide d’un login et mot de passe n’est pas prioritaire. Car cette séquence ne permet pas à l’application d’être fonctionnelle.
Si la séquence débouche sur une autre action mais que celle-ci n’est pas encore accessible, il faut supprimer cette action.
Pour qu’il n’y ait aucune dépendance à une autre séquence. Et qu’elle puisse fonctionner indépendamment.
Idéalement, chaque séquence est développée de cette façon.
Petit à petit. Les unes après les autres.
À chaque nouvelle séquence ajoutée, il faut s’assurer que les étapes essentielles pour arriver à celle-ci ont été développées.
En parallèle, comme pour le découpage des user stories, il faut s’assurer que les séquences soient de taille homogène. Et qu’il n’y en ait pas une plus dense que l’autre.
L’idée c’est de ne pas trop planifier. Pour rester flexible et pouvoir s’adapter. Grâce à ça, on peut tester continuellement et ajuster le produit pour continuer à faire du sur-mesure.
Par exemple, on peut définir avec exactitude ce qui peut être produit en deux semaines.
Et anticiper sur les deux semaines suivantes.
De cette façon, si l’équipe est en avance, elle peut commencer à travailler sur la suite.
Ça permet d’être plus agile. Et de modifier l’application au fur et à mesure, pendant qu’elle est construite. Éviter de modifier des éléments qui interviennent plus tard, c’est aussi moins de frustration et de perte de temps.
À ce stade, vous avez déjà une première partie de votre appli développée.
De nouvelles difficultés vont sûrement se présenter.
Par exemple, décrire des bugs prend du temps.
Et il y a toujours une ou plusieurs informations manquantes.
Les allers-retours entre l’équipe produit et vous sont fréquents.
Alors comment transmettre les problèmes à l’équipe produit de la façon la plus claire et rapide possible ?
En lien direct avec vous, l’équipe produit se chargera ensuite d’estimer le budget.
Pour pouvoir tester votre produit, demandez que l’équipe produit vous envoie une vidéo avec toutes les étapes à explorer.
C’est important pour ne rien oublier. Par exemple, pour tester correctement, parfois il faut se déconnecter du compte. C’est l’équipe produit qui pourra vous guider sur ces points.
Bien définir ce qui est attendu est primordial. Et ce n’est pas toujours clairement fait.
L’idée, c’est que rien ne manque lorsque vous allez faire votre propre test et que vous compreniez bien comment tester. C’est primordial pour éviter que le test soit invalide.
Autre exemple, il ne faut pas oublier de tester les phases de téléchargement, d’installation, de désinstallation mais aussi de réinstallation de l’application.
Ce sera très utile ensuite pour les ingénieurs.
Au moment du test, faites une capture vidéo de votre écran. Enregistrez toute la session et parlez à voix haute. Ça permet de suivre ce que vous faites. Mentionnez les étapes, les problèmes rencontrés, etc.
Reproduire un problème survenu lors d’un test n’est pas évident. Expliquer ce qui se passe à haute voix est essentiel pour définir toutes les étapes qui permettent systématiquement de reproduire le même problème. Il faut savoir qu’un bug qui n’est pas reproduit à tous les coups ne pourra probablement pas être corrigé.
Des outils comme Reflector (payant) ou AZ recorder (gratuit) - sur Android - offrent un rendu de grande qualité pour un test sur téléphone. On peut aussi citer Genymobile/srccpy, un outil là encore gratuit mais plus technique.
Une fois le test fini, envoyez la vidéo à l’équipe produit pour qu’ils puissent prendre en compte les bugs.
L’objectif ici, c’est de corriger les problèmes mais sans ralentir le développement.
Or, c’est impossible d’estimer le temps qu’il va falloir pour corriger un bug. Parce que ce qui prend le plus de temps, c’est de comprendre ce qu’il se passe.
Il faut donc éviter d’interrompre l’équipe pour qu’ils corrigent des problèmes sans arrêt. Sinon ils n’avancent plus. Et les retards s’accumulent.
En parallèle, il ne faut pas non plus entasser trop de problèmes car cela entraîne aussi beaucoup de retards.
Alors comment faire ?
La meilleure option selon nous, c’est de séparer et hiérarchiser les demandes de correction de la façon suivante :
● les bugs déjà existants et constatés sur le produit
● les améliorations qu’on aimerait faire et auxquelles on pense au fur et à mesure du développement
● les nouvelles fonctionnalités qui viennent en tête petit à petit
Les améliorations et les nouvelles fonctionnalités prennent beaucoup de temps. Il faut donc voir avec l’équipe s’il faut les traiter. Et si oui, à quel moment le faire.
Des outils peuvent vous aider à prioriser. De nouveau Gitlab ou des solutions payantes comme Asana ou Jira.
En ce qui concerne les bugs, il y a ceux qui doivent être résolus tout de suite et ceux qui peuvent attendre que l’application soit disponible sur les stores.
Voici un exemple de priorités que nous utilisons lors du développement d’applications :
À ce stade, l’application a été entièrement débuggée..
Elle est prête à être testée par les utilisateurs finaux.
L’objectif de ces derniers tests est de vérifier que l’application est réellement utile et qu’elle apporte de la valeur.
Concrètement, il s’agit d’observer :
Le 1er point correspond au taux d’activation.
Il mesure la conversion de “visiteurs” en “utilisateurs”.
Il faut donc définir à partir de quand on considère qu’une personne a utilisé l’appli. Et c’est rarement à l’inscription.
Sur Netflix par exemple, ce sera quand l’utilisateur aura regardé un film.
Le second point correspond au taux de rétention.
Il mesure la conversion de “visiteurs” en “visiteurs actifs”, c’est-à-dire les utilisateurs qui reviennent de façon régulière.
La notion de régularité dépend évidemment du type d’application.
Par exemple, sur une application de réservation de billets d’avion, la rétention s’évalue a priori sur plusieurs mois. A contrario, sur Netflix, la rétention est plutôt d’une semaine à l’autre. Et sur une appli de streaming (type Spotify ou Deezer), elle s’observe d’un jour à l’autre.
Mais revenons-en au taux d’activation.
Pour le mesurer, il faut définir les actions dans l’appli qu’on considère comme une utilisation.
Ces actions sont mesurées grâce à un tableau de bord : l’entonnoir de conversion.
Il permet de visualiser les étapes suivies par les utilisateurs pour effectuer une tâche. C’est donc très utile pour voir s’ils réussissent ou s’ils échouent à chacune de ces étapes.
En ce qui concerne le taux de rétention, c’est très différent.
Il évalue la capacité à retenir des utilisateurs, à les fidéliser.
Il faut donc se demander à partir de combien de temps d’inactivité un utilisateur est considéré comme étant “inactif”.
Un second tableau de bord permet de définir la fréquence supposée d’utilisation de l’appli : l’analyse de cohorte.
Grâce à elle, le comportement des utilisateurs peut être observé au fur et à mesure du temps.
Pour mesurer l’activation et/ou la rétention, un outil comme Firebase est parfait. Il en existe d’autres comme Google Analytics, ou Mixpanel. Il faut simplement intégrer ces outils de mesure dans l’application.
Une fois ces deux dashboards en place, il reste à prioriser les améliorations pour augmenter l’utilité du produit.
L’impact de ces améliorations sur les taux d’activation et de rétention peut ensuite être évalué.
Chez Sirup lab, en général on prévoit 15 à 20% du budget initial pour faire évoluer l’appli après l’avoir mise sur les stores.
Pour mesurer la qualité technique de l’appli, des outils de mesure des crashs peuvent aussi être utiles.
Un crash, c’est lorsque l’application se ferme d’un coup. Sans prévenir.
L’impact est instantané car les utilisateurs n’apprécient pas. Cela se termine souvent avec un vote à 1 étoile sur les stores.
Quelques idées d’outils : Crashlytics de Firebase ou Bug snag. Ils permettent d’obtenir des informations sur les problèmes difficiles à reproduire. Ceux qui n’apparaissent pas de façon systématique.
Suite à ces tests et observations, il peut y avoir de nouvelles mises à jour de l’appli à faire.
Dans ce cas, si les utilisateurs sont nombreux, distribuer la mise à jour à un petit panel est une bonne option (1 à 10% des utilisateurs par exemple). Ça permet de rester qualitatif tout en évitant un impact trop important en cas de retours négatifs.
Grâce aux 3 dernières astuces développées dans cet article, vous avez :
On arrive désormais au bout des 3 phases essentielles à la création d’une application mobile.
Dans la phase de recherche, on a vérifié le concept. On s’est assuré que l’idée est utile et qu’elle sera vraiment utilisée.
Avec l’étape de la conception, on a vérifié que la solution est simple d’utilisation et facile à construire.
Enfin, la phase de développement a permis d’avoir plus de contrôle sur le produit. Tout en restant dans les clous, que ce soit en termes de délais ou de coûts.
En vous proposant un article pour chaque étape (recherche, conception et développement), on a partagé un peu de notre expérience avec vous. Nous espérons que ça vous soit utile.
Le bilan qu’on en tire, c’est qu’il ne faut pas hésiter à se faire accompagner par des professionnels.
Si le produit a été réfléchi, s’il est bien fini et simple d’utilisation, les résultats seront au rendez-vous. Voir les utilisateurs finaux s’emparer de son application, c’est une réelle satisfaction.
C’est ce qu’on vous souhaite. Qu’ils l’utilisent et qu’ils se l’approprient.
Et vous, quelles leçons en tirez-vous ? Partagez-les avec nous dans les commentaires ou envoyez-nous un email
Nous envoyons une fois par mois nos nouveaux articles, tutoriaux et notre veille technologique
